DevSecOps Engineer Interview Pack (2026)

Audience: DevSecOps engineer candidates from mid-level to senior. Format: 30 questions total. Breakdown: 10 technical review, 10 theory/method, 10 scenario questions. Use with: Interview Answer Patterns and Tactics, Commit-to-Deploy Security, Runner Isolation and Trust Boundaries, Cloud Environment Security, and Container / Kubernetes / Platform Security.

What good interviewers usually want from a DevSecOps engineer

A strong candidate can:

• secure the path of change from commit to deploy;
• reason about identity, trust boundaries, and blast radius across CI/CD, cloud, and Kubernetes;
• turn security policy into enforceable automation;
• preserve delivery speed while making controls observable and auditable.

Block A — Technical review questions (10)

1. Review this GitLab runner setup

[[runners]]
  executor = "docker"
  [runners.docker]
    privileged = true
    volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]

Strong answer should cover

• Privileged runner plus Docker socket means near-host compromise if a pipeline is abused.
• This destroys trust separation between job and host.
• Safer alternatives: rootless builders, isolated ephemeral runners, Kaniko/BuildKit patterns, workload identity, and environment-scoped credentials.
• Mention that not every runner needs the same trust level.

2. What is wrong with this GitHub Actions deployment job?

deploy:
  if: github.ref == 'refs/heads/main'
  steps:
    - uses: actions/checkout@v4
    - run: kubectl apply -f k8s/
      env:
        KUBECONFIG: ${{ secrets.KUBECONFIG_PROD }}

Strong answer should cover

• Long-lived production kubeconfig in repository secrets is the first problem.
• Missing environment protection, approvals, artifact pinning, and provenance verification.
• The deploy job should consume a reviewed build artifact, not arbitrary workspace state.
• Use OIDC / short-lived credentials, protected environments, and deployment evidence.

3. Review this Kubernetes pod

securityContext:
  runAsUser: 0
containers:
- name: api
  image: myorg/api:latest
  securityContext:
    privileged: true
    allowPrivilegeEscalation: true

Strong answer should cover

• Root, privileged, mutable tag, and privilege escalation are all red flags.
• Add pinned immutable digest, non-root UID, dropped capabilities, read-only root filesystem, seccomp profile, and Pod Security / admission enforcement.
• Explain why latest harms both security and forensics.

4. You see this AWS IAM policy on a CI role. What do you say?

{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"*","Resource":"*"}]}

Strong answer should cover

• This is total privilege with no blast-radius boundary.
• Fix with least privilege, resource scoping, session tags, conditions, and separate roles per pipeline stage or environment.
• Mention why CI roles are especially dangerous: they are automation identities with broad reach and low human friction.

5. Review this Argo CD policy snippet

spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Strong answer should cover

• Automation is fine, but production governance depends on AppProject, source restrictions, sync windows, RBAC, and admission policy.
• Ask what branch, what repo, who can merge, who can override, and whether policy check results are bound to promotion.
• Good DevSecOps candidates never review GitOps in isolation from repo controls.

6. How would you secure a secret currently stored in .gitlab-ci.yml as a variable value?

Strong answer should cover

• Immediate response: rotate it.
• Then move to secret manager or CI-provided external secret integration, scope it to environment, use short-lived auth where possible, and restrict job exposure.
• Add detection and commit-blocking to prevent recurrence.

7. Review this Terraform snippet

resource "aws_s3_bucket" "logs" {
  bucket = "prod-audit-logs"
}

Strong answer should cover

• Missing encryption, versioning, public-access block, lifecycle/retention, and immutable protections if this bucket holds evidence or logs.
• For high-value audit trails, mention Object Lock/WORM where the use case supports it.
• Good answer ties control to purpose, not checkboxing.

8. What is the security issue with curl | bash inside a Dockerfile build stage?

Strong answer should cover

• Unverified remote code execution at build time.
• Build-time compromise can poison artifacts and provenance.
• Prefer pinned packages, verified checksums, trusted registries, or prebuilt internal builder images.

9. Review this Redis config line for a production shared environment

protected-mode no

Strong answer should cover

• Without strict network isolation and auth, this is dangerous.
• Need auth/ACLs, TLS if applicable, protected network path, logging/monitoring, and privileged access controls.
• DevSecOps candidate should connect config review to exposure model.

10. What would you check first if Cosign verification started failing only in production?

Strong answer should cover

• Digest mismatch between promoted artifact and deployed image.
• Wrong trust root, Rekor reachability/policy differences, environment-specific admission config, or build/promotion drift.
• Validate the artifact path end-to-end before blaming the signer.

Block B — Theory and method questions (10)

11. What is the difference between CI/CD security and DevSecOps?

Strong answer should cover

• DevSecOps is the broader operating model across development, security, and operations.
• CI/CD security is the protection of the controlled change path: repo, pipeline, runner, artifact, approval, environment, and evidence.
• Good candidates can articulate why scanning code alone is not enough.

12. What does provenance buy you that SBOM alone does not?

Strong answer should cover

• SBOM tells you what components are present.
• Provenance tells you where, when, and how the artifact was built and by what identity/workflow.
• Together they support trust and incident response; separately they are incomplete.

13. Why do mature teams separate build, test, and deploy identities?

Strong answer should cover

• Different stages need different authority.
• Separation limits blast radius and strengthens evidence integrity.
• It also makes approvals and incident reconstruction clearer.

14. Explain runner trust tiers.

Strong answer should cover

• Untrusted contribution workflows, internal development workflows, release/build-signing workflows, and production deployment workflows should not share the same execution trust.
• Each tier gets different network access, secret exposure, and human approval expectations.

15. What is policy-as-code good at, and where does it fail?

Strong answer should cover

• Good for repeatable structural rules, deployment guardrails, and preflight validation.
• Weak on intent, abuse logic, and contextual exceptions unless the program around it is mature.
• Strong candidates discuss exception governance, auditability, and developer ergonomics.

16. Why is ephemeral infrastructure attractive from a security perspective?

Strong answer should cover

• Shorter persistence of compromise, cleaner rebuild patterns, less configuration drift, easier evidence of desired state.
• But not free: image trust, bootstrap secrets, and hidden state still matter.

17. What is the practical difference between secrets management and identity-based access?

Strong answer should cover

• Secrets management stores and distributes sensitive values safely.
• Identity-based access tries to avoid long-lived shared secrets altogether by issuing short-lived, scoped credentials to authenticated workloads.
• Senior candidates usually prefer identity first, secrets second.

18. Why does GitOps not eliminate release risk?

Strong answer should cover

• It changes the control plane, but repo compromise, policy mistakes, and bad artifacts still ship.
• GitOps must be paired with protected branches, reviewed promotions, trusted images, and admission controls.

19. How do you think about blast radius in cloud and Kubernetes?

Strong answer should cover

• Identity scope, network segmentation, namespace/project boundaries, tenant separation, secret exposure, and deploy permissions.
• Blast radius is not abstract. It is the set of assets reachable after one control fails.

20. What would make you choose Semgrep, Checkov, Kyverno, OPA, or native cloud policy instead of one another?

Strong answer should cover

• They operate at different layers: code, IaC, cluster admission, generic policy engine, or provider-native enforcement.
• Mature candidates map tool to layer, owner, timing, and evidence needs.

Block C — Scenario and reasoning questions (10)

21. A release pipeline fails because security scans timed out. The business wants a manual deploy. What do you do?

Strong answer should cover

• Separate control failure from product failure.
• Check whether the gate is mandatory, what evidence exists from prior stages, and what exposure is changing.
• If manual override is permitted, require named approvers, logged exception, compensating controls, and fast post-release verification.

22. A team says runner isolation is too expensive. How do you answer?

Strong answer should cover

• Price the risk in terms of secrets, artifact trust, and production access, not only CPU cost.
• Offer a tiered model instead of "isolate everything."
• Good candidates show how to spend trust only where needed.

23. You inherited 200 repositories with inconsistent CI security. Where do you start?

Strong answer should cover

• Normalize the highest-risk defaults first: branch protection, CODEOWNERS, environment protection, secret scanning, pinned actions/includes, runner tiers.
• Build reusable pipeline components rather than repo-by-repo drift.
• Track coverage by critical app and environment.

24. A cluster compromise is suspected, but engineering wants to restart workloads immediately. What is your approach?

Strong answer should cover

• Preserve evidence before destroying state, unless safety or service impact makes that impossible.
• Capture timeline, node/pod/process/container/image details, identity use, network indicators, and affected secrets.
• Then contain by isolating nodes/namespaces, revoking credentials, and constraining egress.

25. A team wants direct production deploy rights because "we are on call anyway." What do you say?

Strong answer should cover

• On-call ownership is not the same as unrestricted deploy authority.
• Good design separates emergency response from unreviewed production change.
• Offer approved break-glass workflow with time-bounded access and evidence.

26. How do you respond when an auditor asks for proof that only approved artifacts reach production?

Strong answer should cover

• Show repo controls, build logs, signing/attestation, promotion records, admission or deployment policy, approval history, and runtime inventory.
• A strong answer is evidence-oriented, not slogan-oriented.

27. A platform team wants one shared admin kubeconfig in the CI vault for convenience. How do you redirect the design?

Strong answer should cover

• Shared admin kubeconfig is poor identity hygiene and weak evidence.
• Move to environment-scoped roles, short-lived workload identity or exec plugin patterns, and promotion-specific deploy permissions.
• Keep convenience, but attach it to automation identities with boundaries.

28. How would you explain secure delivery to a startup CTO who only hears "more friction"?

Strong answer should cover

• Translate to recovery speed, lower incident cost, safer delegation, and repeatable releases.
• Emphasize templates and defaults that reduce bespoke work.
• Mature answer avoids lecturing and shows an incremental path.

29. What makes a DevSecOps engineer weak even if they know many tools?

Strong answer should cover

• Tool obsession without trust-boundary reasoning.
• No model for evidence, ownership, or blast radius.
• Unable to explain why a control belongs in repo, pipeline, platform, or runtime.

30. Tell me about a time you intentionally chose a weaker control.

Strong answer should cover

• Pick a case where the perfect control would have broken adoption or reliability.
• Explain assumptions, compensating controls, time-bounded exception, and upgrade plan.
• This demonstrates engineering judgment, not security theatre.

Final prep advice for this role

• Practice reading pipeline, IAM, Docker, Terraform, and Kubernetes YAML quickly.
• Always ask: who can change production, with which identity, through what evidence, and with what rollback path?
• Sound strongest when you connect security to delivery design rather than to isolated scanners.