Guides

DevSecOps Interview Questions and Answers (30, Freshers to Experienced)

By Ravindra Bagale, Cyber Security trainer · LinkedIn · Published: 16 October 2026 · Last updated: 17 October 2026

These are the DevSecOps interview questions asked most often for fresher and mid-level roles, with short answers you can say out loud. Each answer follows the same pattern interviewers like: what it is, where it runs in the pipeline, which tool you used, and one real example. Practise them with a small demo pipeline (Trivy, gitleaks and SonarQube in GitHub Actions), so you can show it as well as tell it.

The pipeline map every answer comes back to

Basics

Q1. What is DevSecOps in one line?

DevSecOps puts security checks into every step of the delivery pipeline, so developers find problems early, while they are cheap to fix, instead of a security team finding them just before release.

Q2. What does "shift left" mean?

Moving security tests earlier ("left") in the timeline, into the IDE, the pull request and the build, instead of only testing in production.

Q3. Name the main scan types in a pipeline.

SAST (your code, e.g. SonarQube, Semgrep), SCA (libraries, e.g. Trivy, Dependency-Check, Snyk), secret scanning (gitleaks), IaC scanning (Checkov, trivy config), container scanning (Trivy, ECR scanning) and DAST (OWASP ZAP against a running staging app).

Q4. SAST vs DAST?

SAST reads source code without running it and finds issues like SQL built from strings. DAST attacks a running test copy from the outside and finds issues like missing security headers. You need both.

Q5. What is SCA and why does it matter?

Software Composition Analysis checks third-party libraries for known CVEs and licence problems. Most of a modern app is libraries. Log4Shell (CVE-2021-44228) was a library problem, not a problem in teams' own code.

Q6. What is an SBOM?

A Software Bill of Materials: a list of every component and version in your software, in a standard format such as CycloneDX or SPDX. It lets you answer "are we affected?" in minutes when a new CVE comes out.

Pipeline and tools

Q7. Where do you put each check in the pipeline?

Pre-commit: secret scanning. Pull request: SAST, SCA and IaC checks. Build: container image scanning and SBOM. Staging: DAST. Production: runtime monitoring, CloudTrail and GuardDuty alerts.

Q8. How do you stop a pipeline from becoming noisy?

Gate only on new HIGH/CRITICAL issues that have a fix, tune false positives with written reasons, and show findings inside the pull request where developers already work.

Q9. How do you handle secrets in CI?

Never in the repo. Use the CI secret store or AWS Secrets Manager, and prefer OIDC federation (for example GitHub Actions to an IAM role) so there are no long-lived keys at all.

Q10. What is OIDC in GitHub Actions to AWS?

GitHub issues a short-lived signed token for each job. AWS IAM trusts GitHub's OIDC provider and exchanges the token for temporary credentials of one role, limited by repository and branch.

Q11. How do you sign container images?

With Sigstore cosign (or AWS Signer), and then verify signatures at deploy time with an admission controller such as Kyverno, so only images built by your pipeline run.

Q12. What is policy as code?

Writing rules as code that a machine checks, such as OPA/Gatekeeper or Kyverno policies that block privileged pods, or Checkov rules that block public S3 buckets in Terraform.

Cloud and containers

Q13. Top 3 Kubernetes security controls?

RBAC with least privilege, Pod Security Standards (no privileged pods, run as non-root), and NetworkPolicies to limit pod-to-pod traffic. Add image scanning and signed images.

Q14. How do you secure a Dockerfile?

Small current base image, multi-stage build, non-root USER, no secrets in layers, a .dockerignore, and pinned versions.

Q15. How do pods get AWS access safely?

With IAM Roles for Service Accounts (IRSA) or EKS Pod Identity, so each pod gets only its own role. Never store access keys in a Secret.

Q16. What do you scan in Terraform?

Public S3 buckets, open security groups (0.0.0.0/0 on 22 or 3389), unencrypted storage, wildcard IAM policies and missing logging, using Checkov, tfsec or trivy config.

Q17. How do you find a leaked AWS key fast?

GitHub secret scanning and AWS both alert on keys pushed publicly. Deactivate the key, check CloudTrail for what it did, rotate, and add gitleaks to pre-commit.

Scenarios

Q18. A critical CVE appears in a base image used by 40 services. What do you do?

Use the SBOMs or registry scans to list affected images, patch the base image once, rebuild all services through the pipeline, re-scan, and track progress on a simple dashboard. Prioritise internet-facing services.

Q19. A developer says the scanner blocks their urgent release. What do you do?

Look at the finding together. If it is real and exploitable, fix or apply a temporary control. If it is a false positive or not reachable, record a time-limited exception with an owner. Never just turn the gate off.

Q20. Your SAST tool reports 2,000 issues on an old project. Where do you start?

Gate on new code only, then fix the old issues by severity and exposure, starting with internet-facing code. Track the number going down each sprint.

Q21. How would you secure the pipeline itself?

Protected branches with reviews, pinned versions of CI actions (by commit SHA), least-privilege runner roles, short-lived credentials, and logs of who changed the pipeline.

Q22. What happened in the SolarWinds attack and what is the lesson?

In 2020 attackers broke into SolarWinds' build system and inserted the SUNBURST backdoor into signed Orion updates sent to about 18,000 customers. The lesson: the build system is production. Protect it, monitor it and verify what it produces.

Q23. What did the Codecov breach (2021) teach?

Attackers changed Codecov's Bash Uploader using a credential leaked through its Docker image build. Customers' CI secrets were exposed. Lessons: verify downloaded scripts with checksums, and give CI jobs only the secrets they need.

Q24. How do you measure DevSecOps success?

Mean time to fix critical issues, percentage of repos with scanning turned on, number of open critical findings over time, and how many issues are caught before production.

A live demo you can show in the interview

A small public repo with this workflow speaks louder than any answer:

name: secure-build
on: [pull_request]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: gitleaks/gitleaks-action@v2
      - run: docker build -t app:${{ github.sha }} .
      - uses: aquasecurity/trivy-action@0.24.0
        with:
          image-ref: app:${{ github.sha }}
          severity: CRITICAL,HIGH
          exit-code: '1'

Open a pull request with a vulnerable base image, show the red check, fix it, and show the green check. That five-minute story answers half of the questions above.

Summary table