DevSecOps Interview Questions and Answers 2026 (60 Questions)

DevSecOps interview questions in 2026 go well past "what is shift-left". Interviewers want to see that you can put the right security check at the right pipeline stage, keep false positives low enough that developers don't route around it, replace long-lived cloud keys with OIDC federation, sign and verify what you ship, and treat model files and prompts as supply-chain artefacts too. This guide collects 60 high-value, commonly asked questions with model answers, tool names used accurately and 12 production scenarios worked through step by step.

If you want the end-to-end pipeline for AI systems as a reference while you prepare, read DevSecOps for enterprise AI alongside this page; the questions below assume you know the DevOps basics and focus on the security layer.

How to use this guide

• Freshers and career switchers: interviewers test the vocabulary and the "why": what SAST, DAST, SCA and secrets scanning each catch, what shift-left means in practice and who owns what in the cloud. Questions 1 to 12 are the base.
• DevOps and cloud engineers moving into DevSecOps: expect supply chain (SBOMs, SLSA, signing), Kubernetes admission control, IaC policy, OIDC federation and secrets management. Questions 13 to 40 carry most of the weight.
• Senior DevSecOps, platform security and AppSec engineers: threat modelling, vulnerability prioritisation, AI/ML pipeline security, metrics, culture and the scenario round. Questions 37 to 60 matter most.
• Tools are named as examples of a category, not as recommendations or a ranking. Interviewers test whether you understand the category and its trade-offs; product names and features change, so check current documentation.

Contents

• DevSecOps fundamentals (Q1 to Q5)
• SAST, DAST, IAST, SCA and secrets scanning (Q6 to Q12)
• Software supply chain security (Q13 to Q18)
• Container and Kubernetes security (Q19 to Q25)
• IaC scanning and policy-as-code (Q26 to Q28)
• Cloud security posture (Q29 to Q30)
• Secrets management (Q31 to Q32)
• CI/CD hardening (Q33 to Q36)
• Threat modelling (Q37 to Q38)
• Vulnerability management and SLAs (Q39 to Q40)
• DevSecOps for AI/ML pipelines (Q41 to Q45)
• Metrics and culture (Q46 to Q48)
• Real-world scenarios (Q49 to Q60)
• Key takeaways
• Interview preparation checklist
• FAQ

DevSecOps fundamentals

1. What is DevSecOps, and how is it different from DevOps?

Answer: DevSecOps is DevOps with security built into every stage of the delivery lifecycle, owned jointly by development, operations and security, and enforced mostly through automation rather than manual review gates. DevOps already automates build, test and deploy; DevSecOps adds security checks to the same pipeline (code scanning, dependency analysis, image scanning, policy checks, signing) and security signals to the same feedback loops (pull request comments, dashboards, on-call alerts).

Aspect	Traditional DevOps	DevSecOps
When security happens	Often a review or pen test before release	Continuously, from the IDE to runtime
Who owns it	Separate security team	Shared; security team builds the guardrails
How it is enforced	Tickets and sign-offs	Pipeline checks, policy-as-code, admission control
Evidence for audit	Collected manually	Produced by the pipeline (logs, SBOMs, attestations)

Interview tip: end with the principle the old version of this answer got right: make the secure path the easiest path. A DevSecOps team that only adds blocking gates is doing DevOps with more friction, not DevSecOps.

2. What does "shift-left" mean, and what is "shift-right"?

Answer: shift-left means moving security checks earlier in the lifecycle, where fixes are cheaper and context is fresh: secrets scanning in a pre-commit hook, SAST and SCA on every pull request, IaC scanning before terraform apply, threat modelling at design time. Shift-right is the complement: security signals from production, such as runtime detection, WAF and API logs, cloud audit trails and bug bounty reports, fed back into the backlog. You need both, because some problems (misconfigured runtime permissions, exploitation attempts, drift) only appear in a running system.

Real-world example: a pre-commit secrets hook turns what would have been a rotation, history rewrite and incident ticket into a two-second warning.

3. Explain the shared responsibility model, both in the cloud and inside the team.

Answer: in the cloud, the provider secures the underlying infrastructure ("security of the cloud") and the customer secures what they put on it ("security in the cloud"): identities, data, network rules, configuration and their own code. The split moves with the service model. On virtual machines you patch the operating system; on managed Kubernetes the provider runs the control plane but you own node images (unless fully managed), workloads, RBAC and network policy; on serverless and SaaS you own mainly identity, data and configuration.

Inside the team, developers own fixing findings in their code, platform engineers own secure defaults (base images, pipeline templates, cluster policy), and the security team owns standards, tooling, tuning and incident response. Write it down as a RACI so no team assumes another is watching.

4. Map the DevSecOps lifecycle stages to security controls and example tools.

Answer: one way to lay it out:

Stage	Security control	Example tools (category examples, not a ranking)
Plan / design	Threat modelling, security requirements	OWASP Threat Dragon, Microsoft Threat Modeling Tool
Code	IDE linting, pre-commit secrets scanning	Gitleaks, TruffleHog, detect-secrets, IDE plugins
Pull request	SAST, SCA, IaC scanning, code review	Semgrep, CodeQL, SonarQube, OWASP Dependency-Check, Snyk, Checkov, Trivy
Build	SBOM, image scanning, signing, provenance	Syft, Trivy, Grype, cosign, GitHub artifact attestations
Test	DAST, API scanning	ZAP, Burp Suite, Nuclei
Deploy	Policy checks, signature verification, admission control	OPA Gatekeeper, Kyverno, Conftest
Run	Runtime detection, CSPM, logging	Falco, Amazon GuardDuty, Microsoft Defender for Cloud, Google Security Command Center

Interview tip: for each stage, say what it catches that earlier stages cannot.

5. What does "security as code" mean in practice?

Answer: it means security rules, configurations and evidence live in version control and go through the same review, testing and deployment as application code. Examples: scanner configuration and suppression files in the repository; admission policies for Kyverno or Gatekeeper in a policy repo deployed by Argo CD; IAM roles defined in Terraform; Conftest or Checkov custom rules with unit tests; pipeline templates that every service inherits. You get reviewability, repeatability and audit evidence for free: git history shows who changed which control and when, and policies get unit tests like any code.

SAST, DAST, IAST, SCA and secrets scanning

6. What does SAST catch, what does it miss, and where should it run?

Answer: Static Application Security Testing analyses source code (or bytecode) without running it, using pattern rules and data-flow (taint) analysis to find issues such as SQL injection, command injection, path traversal, unsafe deserialisation, weak crypto calls and hard-coded credentials. It is fast, runs early and points to the exact line. It misses runtime and configuration issues (a weak TLS setting on the load balancer, a missing security header), business-logic flaws such as broken authorisation between tenants, and anything that depends on how components are wired together in production.

Run a fast, high-confidence rule set on every pull request, scoped to changed code, with results as inline comments. Run the full, deeper analysis on the main branch or nightly. Examples: Semgrep, CodeQL, SonarQube.

Interview tip: say "diff-aware scanning". Interviewers like candidates who know that flagging 400 pre-existing issues on a one-line change is how teams learn to ignore the scanner.

7. What does DAST catch that SAST cannot, and what are its limits?

Answer: Dynamic Application Security Testing attacks a running application from the outside, like an attacker would, without seeing the code. It finds issues visible only at runtime: missing or weak security headers, cookie flags, TLS misconfiguration, reflected XSS and injection that actually reach a sink, exposed admin endpoints, verbose error pages and some authentication weaknesses. Its limits: it needs a deployed environment and test data, it is slower, its coverage depends on how well it can crawl or how complete your API specification is, it reports a URL rather than a line of code, and it rarely finds deep authorisation bugs without authenticated, role-aware test scripts.

Run a short baseline scan against staging after each deployment and a deeper authenticated scan on a schedule. Examples: ZAP (long known as OWASP ZAP), Burp Suite, Nuclei.

8. What is IAST, and when is it worth the effort?

Answer: Interactive Application Security Testing places an agent inside the running application (instrumenting the runtime, for example a Java or .NET agent) and watches real requests flow through the code during functional or automated tests. Because it sees both the HTTP request and the code path, it can confirm that tainted input actually reached a dangerous sink and report the exact line, which tends to mean fewer false positives than SAST and better code context than DAST. The costs: language and framework support is narrower, the agent adds overhead so it belongs in test environments, and coverage is only as good as your test suite. It is worth it for a large, well-tested web application in a supported language where SAST noise has become the bottleneck.

9. What is SCA, and why is it often the highest-value scanner?

Answer: Software Composition Analysis identifies the open-source and third-party components in your application (from manifests, lockfiles and binaries), then matches them against vulnerability databases and licence data. It is often the highest-value scanner because most of the code in a modern service is dependencies, and known vulnerabilities in popular libraries are exactly what attackers scan the internet for. Good SCA also covers transitive dependencies, licence policy (for example, flagging copyleft licences in a product you distribute) and, in some tools, reachability analysis, which tells you whether your code actually calls the vulnerable function.

Examples: OWASP Dependency-Check, Dependabot, Renovate, Trivy, Grype, OSV-Scanner, Snyk, Mend.

10. Compare SAST, DAST, IAST and SCA in one table.

Answer:

Type	Looks at	Typical stage	Strong at	Weak at
SAST	Your source code	IDE, pull request	Injection patterns, exact line numbers, early feedback	Runtime config, logic flaws, false positives
DAST	Running app, black box	Staging, scheduled	Headers, TLS, exposed endpoints, real exploitability	Coverage, speed, pinpointing code
IAST	Running app, instrumented	Test/QA runs	Confirmed findings with code context	Language support, depends on test coverage
SCA	Dependencies and licences	Pull request, build, continuously	Known CVEs in libraries, licence risk	Zero-days, your own code

11. How do you implement secrets scanning, and what do you do when it finds something?

Answer: in layers. First, prevention at the developer's machine with a pre-commit hook (Gitleaks, detect-secrets, TruffleHog). Second, server-side push protection (for example GitHub push protection), because local hooks can be skipped. Third, pull request scans plus a one-time scan of full git history. Fourth, places outside code: CI logs, image layers, Terraform state, wikis.

When a real secret is found, the order matters: revoke or rotate first, then check access logs for use of the credential during its exposure window, then remove it from the code and history, then fix the root cause (move it to a secret manager, add the pattern to push protection). Removing it from git without rotating is the most common wrong answer.

12. How do you handle false positives without making developers ignore the tools?

Answer: treat signal quality as a product metric the security team owns. Practical steps:

• Start with a small, high-confidence rule set in blocking mode and run the rest in report-only mode; promote rules once their precision is proven.
• Scan the diff, not the whole repository, on pull requests; triage the legacy backlog separately.
• Allow suppressions only in code with a reason, an owner and an expiry date (for example an inline comment or an ignore file reviewed by security), never a silent "ignore all".
• Use reachability and exploitability context (Q39) for SCA so unreachable or non-exploitable findings drop in priority.
• Deduplicate across tools in one place, such as DefectDojo or an ASPM platform.
• Track the false-positive rate per rule and retire rules that are mostly noise.

Interview tip: the phrase interviewers want is "precision before coverage".

Software supply chain security

13. What is an SBOM, and what do you actually do with it?

Answer: a Software Bill of Materials is a machine-readable inventory of the components in a piece of software: names, versions, suppliers, hashes and dependency relationships. The two widely used formats are SPDX and CycloneDX. You generate it at build time from the artefact you ship (for example with Syft, Trivy or a build plugin), attach it to the release or image, ideally as a signed attestation, and store it centrally.

The value comes from using it: when a new critical CVE is announced, you query stored SBOMs to answer "which running services contain this library, at which version?" in minutes instead of grepping hundreds of repositories.

Interview tip: generate the SBOM from the built artefact; one from the source repository misses base-image packages.

14. What is SLSA, and what do its Build levels require?

Answer: SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is an OpenSSF framework of incremental requirements for protecting how software is built and where its source comes from. The current specification (version 1.2) has a Build track and a Source track. The Build track levels are:

Level	Name	What it means
Build L0	No SLSA	No SLSA requirements met
Build L1	Provenance exists	The build produces provenance describing how the artefact was built
Build L2	Hosted build platform	Builds run on a hosted platform that signs the provenance, preventing tampering after the build
Build L3	Hardened builds	Builds are isolated from one another and signing secrets are protected from user-defined build steps, defending against tampering during the build

The Source track runs from Source L1 (version controlled) to Source L4 (two-party review of changes to protected branches).

Interview tip: SLSA levels describe build and source integrity, not whether the code is free of vulnerabilities. A Build L3 artefact can still contain a vulnerable library. Saying that clearly shows you understand what provenance is for.

15. How does keyless signing with Sigstore and cosign work?

Answer: Sigstore is an open-source project for signing and verifying software artefacts; cosign is its tool for container images and other OCI artefacts. In keyless mode, the signer (a CI job or a person) authenticates with an OIDC identity, for example a GitHub Actions workload identity. Sigstore's certificate authority, Fulcio, issues a short-lived certificate binding an ephemeral key to that identity; the artefact is signed; and the signature event is recorded in Rekor, a public transparency log. There is no long-lived private key to store, rotate or leak.

CI job --OIDC token--> Fulcio (short-lived cert)
   |                         |
   +-- sign image digest ----+
   |
   +-- record entry -------> Rekor (transparency log)

Deploy: cosign verify --certificate-identity ...
        --certificate-oidc-issuer ...  image@sha256:...

Verification must pin the expected identity (which repository and workflow signed it); without that, it only proves that somebody signed it.

Interview tip: sign and verify by digest, not tag, because tags are mutable, and mention attestations (signed SLSA provenance or SBOMs attached to the image).

16. Why pin dependencies, and how do you pin without freezing?

Answer: pinning makes builds reproducible and stops a compromised or broken new release flowing into your build silently. Pin with lockfiles and hashes (package-lock.json, poetry.lock, pip install --require-hashes, go.sum), base images by digest, GitHub Actions by full commit SHA rather than tag, and Terraform providers through the dependency lock file. The risk of pinning is the opposite problem: you never update, and known CVEs accumulate. The answer is automated update pull requests (Dependabot or Renovate) that run the full test and security pipeline, grouped and scheduled so they are reviewable, with security updates fast-tracked.

Interview tip: point out that a version range such as ^2.1.0 in a manifest is not a pin. The lockfile is the pin, and CI must install from it (npm ci, not npm install).

17. What are dependency confusion and typosquatting, and how do you defend against them?

Answer: dependency confusion happens when a build that uses an internal package name also checks a public registry, and an attacker publishes a public package with the same name and a higher version, which the package manager prefers. Typosquatting is publishing malicious packages with names close to popular ones (a swapped letter, a hyphen). Defences: route all installs through an internal proxy registry (Artifactory, Nexus, a cloud artefact registry) that controls which upstreams are allowed; use scoped or namespaced internal packages and reserve your names on public registries; pin with lockfiles and hashes; and run SCA or package-reputation checks that flag brand-new, low-download or install-script-heavy packages.

18. How do you enforce at deploy time that only trusted, signed images run?

Answer: verify signatures and attestations at admission time in the cluster, not just in CI. A Kyverno verifyImages rule, or the Sigstore policy-controller, or Gatekeeper with an external data provider, checks each pod's images against required signer identities and, optionally, required attestations (for example SLSA provenance from your build workflow, or a vulnerability scan attestation newer than a set age). Combine this with a rule that images come only from your approved registries and are referenced by digest. Start in audit mode, fix the gaps, then enforce.

PR -> build -> scan -> SBOM -> sign + attest -> push
                                                 |
cluster admission: registry ok? signed by CI?  <-+
                   provenance ok? -> admit / deny

Interview tip: mention break-glass: a documented, audited way to deploy an unsigned emergency fix, and an alert whenever it is used.

Container and Kubernetes security

19. How do you secure a container image?

Answer: reduce what is in it, scan what remains, and lock down how it runs.

• Use minimal, maintained base images (distroless, slim or hardened images) pinned by digest, and rebuild regularly to pick up patches.
• Use multi-stage builds so compilers, package managers and test tools don't ship.
• Run as a non-root user, with a read-only root filesystem where possible and no unnecessary Linux capabilities.
• Never bake secrets into layers; use build secrets and runtime injection. Remember that deleting a file in a later layer doesn't remove it from earlier layers.
• Scan the image (Trivy, Grype, Docker Scout, registry-native scanners) and generate an SBOM; sign it (Q15).

20. Is scanning images in CI enough?

Answer: no. CI scanning tells you an image was clean against the vulnerability data available on build day. New CVEs are published continuously against packages already running in production. So you also need continuous scanning of images in the registry and, ideally, of what is actually running in clusters (registry scanning in ECR, ACR or Artifact Registry, or an in-cluster operator such as the Trivy Operator), mapped back to owning teams. Also rebuild images older than a set age; a patched base image fixes many findings with no code change.

21. What is admission control, and how do OPA Gatekeeper and Kyverno differ?

Answer: admission control is the step where the Kubernetes API server, after authentication and authorisation, passes a request to admission controllers that can mutate or reject it before it is stored. Policy engines use validating and mutating admission webhooks to enforce rules such as "no privileged pods", "images only from our registry", "every deployment has resource limits and an owner label".

Aspect	OPA Gatekeeper	Kyverno
Policy language	Rego, wrapped in ConstraintTemplates and Constraints	Kubernetes-native YAML (with CEL support in newer versions)
Strengths	Very expressive; same OPA/Rego skills reused outside Kubernetes	Lower learning curve; built-in mutation, generation and image verification
Typical fit	Teams already using OPA across CI, Terraform and APIs	Platform teams wanting quick, readable cluster policy

Kubernetes also has built-in ValidatingAdmissionPolicy, which uses CEL expressions in-process with no webhook and has been stable since Kubernetes v1.30. It suits simple validation rules; the engines above still add mutation, image verification, reporting and policy libraries.

Interview tip: mention the failure mode: fail closed and an engine outage stops deployments; fail open and policy silently stops applying.

22. What are Pod Security Standards and Pod Security Admission?

Answer: Pod Security Standards define three profiles: privileged (unrestricted), baseline (prevents known privilege escalations, such as host namespaces and privileged containers) and restricted (hardening practices such as running as non-root, dropping capabilities and a RuntimeDefault seccomp profile). Pod Security Admission is the built-in controller that applies them per namespace through labels, in three modes: enforce rejects violating pods, audit records them in the audit log, warn returns a warning to the user. For example, pod-security.kubernetes.io/enforce: restricted. It replaced PodSecurityPolicy, which was removed in Kubernetes v1.25.

23. How do you implement least privilege inside a Kubernetes cluster?

Answer: on four fronts. RBAC: namespace-scoped Roles rather than ClusterRoles, no wildcard verbs or resources, no routine use of cluster-admin, human access through SSO groups with short-lived credentials, regular review with tools like kubectl auth can-i or rbac-tool. Service accounts: one per workload, automountServiceAccountToken: false where the pod doesn't call the API, and cloud access through workload identity (EKS Pod Identity or IRSA, AKS Workload Identity, GKE Workload Identity) rather than node roles or static keys. Network: default-deny NetworkPolicies per namespace, then explicit allows, including egress. Pod settings: the restricted profile from Q22. Add kube-bench for CIS checks.

24. How does runtime detection work in Kubernetes, for example with Falco?

Answer: runtime detection watches what containers actually do, usually via kernel system calls captured with eBPF, and matches behaviour against rules. Falco, a CNCF project, ships rules for events such as a shell spawned in a container, writes to sensitive paths like /etc, unexpected outbound connections, reading service account tokens, or package managers running in a production pod. Alerts go to a SIEM, Slack or an automated response (Falcosidekick, Falco Talon). Cloud services add a complementary layer: Amazon GuardDuty runtime and EKS protection, Microsoft Defender for Containers, Google's container threat detection in Security Command Center.

Interview tip: the hard part is tuning: baseline each workload and suppress known-good activity, or alerts lose credibility.

25. Are Kubernetes Secrets secure?

Answer: only partly. By default, Secret values are base64-encoded, not encrypted, and anyone with get on secrets in a namespace, or who can create a pod there that mounts them, can read them. Hardening steps: enable encryption at rest for etcd with a KMS provider (managed clusters often offer this as a setting), restrict RBAC on secrets tightly, and keep the source of truth in an external secret manager. Common patterns are the External Secrets Operator syncing from AWS Secrets Manager, Azure Key Vault, Google Secret Manager or HashiCorp Vault, or the Secrets Store CSI Driver mounting them as files. For GitOps, never commit plain Secrets; use Sealed Secrets, SOPS or the external-secret pattern.

IaC scanning and policy-as-code

26. How do you secure Terraform and other infrastructure as code?

Answer: scan it before it is applied, control who and what can apply it, and watch for drift.

• Static scanning on every pull request: Checkov, Trivy (which absorbed tfsec's Terraform checks; tfsec's maintainers encourage moving to Trivy), KICS, Terrascan or cloud-vendor tools. They catch public buckets, open security groups, unencrypted storage and missing logging.
• Plan-time policy: evaluate terraform plan JSON with OPA/Conftest, HashiCorp Sentinel (in HCP Terraform and Terraform Enterprise) or OPA policies there, because the plan shows resolved values that static scans of modules can miss.
• Apply control: applies run only from the pipeline, using an OIDC-federated role (Q33), with state stored remotely, encrypted and access-restricted, since state files often contain secrets.
• Secure modules: a reviewed internal module library with secure defaults, so teams get encryption and logging without having to remember them.
• Drift detection: scheduled plans or cloud config rules to spot console changes.

To go deeper on structuring Terraform for these patterns, see Terraform for AI infrastructure.

27. What is policy-as-code, and where does OPA fit?

Answer: policy-as-code expresses rules ("no public storage", "all resources tagged with cost centre", "production deployments need an approved change") as versioned, testable code evaluated automatically, instead of as a wiki page. Open Policy Agent (OPA) is a general-purpose policy engine, a CNCF graduated project, that evaluates policies written in Rego against JSON input. The same engine can check Terraform plans in CI (via Conftest), Kubernetes admission (via Gatekeeper), API authorisation and more, which is why teams like it as one policy language across layers. Alternatives include Kyverno, Sentinel, Cloud Custodian and native cloud policy services. The snippet below is illustrative, in current Rego syntax, and would have opa test unit tests.

package terraform.s3

deny contains msg if {
  r := input.resource_changes[_]
  r.type == "aws_s3_bucket_public_access_block"
  r.change.after.block_public_acls == false
  msg := sprintf("%s allows public ACLs", [r.address])
}

28. How do you automate compliance (SOC 2, ISO 27001, PCI DSS, HIPAA) in a DevSecOps pipeline?

Answer: map each relevant control to an automated check and an automatically produced piece of evidence, then keep that evidence. For example: "changes are peer reviewed" maps to branch protection plus pull request approval records; "production access is restricted" maps to IAM policy checks and access logs; "data encrypted at rest" maps to IaC policies and CSPM findings; "vulnerabilities are remediated in a defined time" maps to scanner results and ticket SLAs; "software integrity" maps to signatures and provenance. Native compliance views (AWS Config conformance packs and Audit Manager, Azure Policy regulatory initiatives, Security Command Center) help. Auditors still decide what is sufficient, so involve the compliance team early and agree evidence formats.

Cloud security posture

29. What is CSPM, and how does it fit with CNAPP and CWPP?

Answer: Cloud Security Posture Management continuously checks cloud accounts against security benchmarks and policies (CIS benchmarks, provider security standards, your own rules) and reports misconfigurations such as public storage, unrestricted security groups, disabled logging, root-account use or over-permissive IAM. CWPP (cloud workload protection) protects the workloads themselves: VMs, containers and serverless functions. CNAPP (cloud-native application protection platform) is the umbrella term for platforms combining CSPM, CWPP, identity analysis (CIEM) and IaC scanning, often with attack-path analysis that links a misconfiguration to an exposed, vulnerable workload with access to sensitive data.

Native options: on AWS, Security Hub CSPM (the original Security Hub was renamed in 2025 when AWS launched a new Security Hub that correlates GuardDuty, Inspector, Macie and CSPM findings), plus AWS Config; on Azure, Microsoft Defender for Cloud (previously Azure Security Center and Azure Defender); on Google Cloud, Security Command Center. Prowler and commercial CNAPPs cover multi-cloud.

See AI for cloud security engineers for how these signals are now triaged with AI help.

30. Detection or prevention: how do you stop cloud misconfigurations at scale?

Answer: layer them. Preventive guardrails at the organisation level block the worst cases outright: AWS Service Control Policies (for example, deny disabling CloudTrail, deny leaving the organisation, restrict regions), Azure Policy with deny effects, Google Cloud Organization Policy constraints, plus account-wide settings such as S3 Block Public Access. Pipeline checks (Q26) catch most issues before apply. Detective controls (CSPM, Config rules) catch console changes and anything that slipped through. Automated remediation (EventBridge with Lambda, Cloud Custodian, Azure Policy remediation tasks) fixes well-understood cases, such as re-enabling encryption, with a notification to the owner. Auto-remediate only safe, reversible changes; ticket the rest.

Secrets management

31. How do you manage secrets across CI/CD and runtime?

Answer: the goal is fewer secrets, shorter-lived secrets and no secrets in code, images or logs. In order of preference:

1. Eliminate the secret with identity federation: OIDC from CI to cloud (Q33), workload identity in Kubernetes, managed identities on Azure, IAM roles for compute.
2. Dynamic secrets where a secret is unavoidable: HashiCorp Vault (or OpenBao) issues short-lived database credentials per job or per pod and revokes them automatically.
3. Centralised static secrets with rotation: AWS Secrets Manager, Azure Key Vault, Google Secret Manager or Vault's key-value store, with automatic rotation, fine-grained access policies and audit logs.

In CI, fetch secrets at runtime, mask them in logs, scope them to environments with approvals, and never expose them to workflows from untrusted forks.

32. HashiCorp Vault or a cloud-native secret manager?

Answer: it depends on the estate. Cloud-native managers are simpler to run, integrate tightly with that provider's IAM, KMS and services, and suit teams mostly on one cloud. Vault (or its open-source fork OpenBao) suits multi-cloud and hybrid estates that want one consistent API, and teams that need features such as dynamic secrets for many backends, PKI and certificate issuance, encryption as a service and fine-grained policies across platforms; the cost is operating a highly available, critical service, or paying for a managed offering. Many enterprises use both. Check current licensing for any tool you choose; Vault's licence changed in 2023, which is why OpenBao exists.

CI/CD hardening

33. Why use OIDC federation instead of long-lived cloud keys in CI, and how does it work?

Answer: long-lived access keys stored as CI secrets can leak through logs, compromised dependencies, forks or ex-employees, and they stay valid until someone remembers to rotate them. With OIDC federation, the CI platform (GitHub Actions, GitLab CI, Azure DevOps, Bitbucket, CircleCI and others) issues each job a signed, short-lived identity token. The cloud provider is configured to trust that issuer and exchanges the token for temporary credentials, scoped to a role, valid for minutes to hours.

GitHub job (id-token: write)
   | OIDC JWT: repo, ref, environment, workflow
   v
AWS STS AssumeRoleWithWebIdentity
   | trust policy checks aud + sub claims
   v
temporary credentials for one role, one job

The security lives in the trust policy conditions. On AWS, restrict the token.actions.githubusercontent.com:sub claim to the specific repository and branch or deployment environment (for example repo:my-org/payments:environment:production) and check the audience. Azure uses federated credentials on an app registration or user-assigned managed identity in Microsoft Entra ID; Google Cloud uses Workload Identity Federation.

Interview tip: the classic mistake is a trust policy that lets any repository assume the production role. Scope by environment and add approval rules.

34. How do you secure CI runners and keep them least-privileged?

Answer:

• Prefer ephemeral runners: one fresh VM or container per job, destroyed afterwards, so a compromised job can't persist or poison the next build. For self-hosted, use autoscaling ephemeral runners such as Actions Runner Controller.
• Never run untrusted code (pull requests from public forks) on self-hosted runners that have network access to internal systems or cached credentials.
• Separate runner pools by trust level: build runners with no production access, deploy runners that can reach production but only run reviewed workflows from protected branches.
• Least-privilege tokens: set the default GITHUB_TOKEN permissions to read-only at the organisation level and grant per job (permissions: block), and scope cloud roles per environment.
• Egress control and monitoring on runners, since exfiltration of secrets needs an outbound connection; tools such as Harden-Runner add this for GitHub Actions.

35. What are the main risks with third-party CI actions and plugins?

Answer: a third-party action or plugin runs inside your pipeline with access to its token, secrets and source code, so it is a dependency with unusually high privilege. Risks: a maintainer account is compromised and a malicious version is published; a tag such as v4 is moved to point at malicious code; or the action has an injection bug. The March 2025 compromise of the widely used tj-actions/changed-files GitHub Action (CVE-2025-30066), in which most version tags were repointed to a commit that dumped CI secrets into build logs, is the standard example. Defences: pin actions to a full commit SHA with Dependabot or Renovate proposing reviewed updates; allow-list approved actions at organisation level; give jobs minimal permissions so a compromised action has little to steal; check projects with OpenSSF Scorecard. Jenkins plugins need the same discipline.

Interview tip: mention script injection too. Using ${{ github.event.pull_request.title }} directly in a run: step lets an attacker inject shell commands through a PR title; pass it through an environment variable instead.

36. What does "zero trust" mean for a CI/CD pipeline?

Answer: assume no component is trusted because of where it sits, and verify every step explicitly. In practice: every job gets its own short-lived identity (OIDC) instead of shared keys; every artefact is signed and its provenance verified before promotion and deployment; nobody pushes directly to protected branches (branch protection or rulesets, required reviews, CODEOWNERS for sensitive paths such as workflows and IaC); human access to the CI system uses SSO with MFA; production deployments need environment approvals; the same signed artefact is promoted from test to production rather than rebuilt; and everything is logged to a place the pipeline itself can't modify.

Threat modelling

37. How do you run a threat model, and what is STRIDE?

Answer: a practical threat model answers four questions (a framing popularised by Adam Shostack and the Threat Modeling Manifesto): what are we working on, what can go wrong, what are we going to do about it, and did we do a good enough job? Draw a data-flow diagram with trust boundaries (user to API, API to database, service to third party, CI to cloud), then walk each element and flow with a prompt list. STRIDE is the common one: Spoofing (identity), Tampering (integrity), Repudiation (non-repudiation and logging), Information disclosure (confidentiality), Denial of service (availability), Elevation of privilege (authorisation). Each threat becomes a mitigation, a backlog item with an owner, or a documented accepted risk. Alternatives include PASTA, LINDDUN (privacy) and attack trees.

38. How do you fit threat modelling into fast agile delivery?

Answer: make it small, frequent and triggered. A full session for new systems and major architecture changes; a fifteen-minute "what changed and what could go wrong" checklist in design review or backlog refinement when a story touches a trust boundary (new external integration, new data type, new auth flow, new AI tool access). Keep diagrams as code next to the service (Threagile or pytm, or simply a docs folder) so they change in pull requests. Security champions (Q47) can run most sessions. The output must land in the backlog, or it was theatre.

Vulnerability management and SLAs

39. How do you prioritise vulnerabilities beyond CVSS score?

Answer: CVSS measures severity in theory; prioritisation needs likelihood and context. Combine:

• Known exploitation: is the CVE in CISA's Known Exploited Vulnerabilities (KEV) catalogue? If so, it jumps the queue.
• Exploit likelihood: EPSS (Exploit Prediction Scoring System, from FIRST) estimates the probability of exploitation in the near term.
• Reachability: does your code call the vulnerable function, and is the package loaded at runtime at all?
• Exposure: internet-facing or internal, behind authentication or not.
• Asset criticality: payment system versus internal wiki; sensitive data in reach.
• Compensating controls: WAF rule, feature disabled, network isolation.
• VEX (Vulnerability Exploitability eXchange) statements from suppliers saying a product is "not affected", which can close findings with justification.

Interview tip: say that a "critical" CVSS finding in an unreachable test dependency can wait for the normal update cycle, while a "high" in KEV on an internet-facing service is an emergency. That contrast shows judgement.

40. How would you define and run vulnerability remediation SLAs?

Answer: set remediation windows by risk tier, not raw severity, agree them with engineering leadership and risk owners, and measure against them. An illustrative policy (every organisation sets its own; regulators and frameworks such as PCI DSS impose their own requirements for in-scope systems): actively exploited and internet-facing, emergency fix within days; critical, within a couple of weeks; high, within about a month; medium and low, in the normal backlog. The clock starts at detection; findings route to owners via CODEOWNERS or a service catalogue; exceptions need an approver, a compensating control and an expiry. Report compliance and ageing per team.

To practise these controls in a real pipeline, Cloudsoft's DevSecOps training in Hyderabad has hands-on labs on SAST and SCA in CI, image signing, Kubernetes admission policy and OIDC-based deployments, in the Ameerpet classroom or live online.

DevSecOps for AI/ML pipelines

41. What changes when the pipeline ships models and prompts, not just code?

Answer: new artefact types join the supply chain and new failure modes join the test plan. Model weights, tokenizers, datasets, embeddings, prompt templates, agent tool definitions and evaluation sets all affect behaviour, so each needs provenance, integrity checks, review and versioning, just like code. The OWASP Top 10 for LLM Applications (2025 edition) is a useful checklist: it starts with LLM01 Prompt Injection and includes Supply Chain (LLM03), Data and Model Poisoning (LLM04), Improper Output Handling (LLM05) and Excessive Agency (LLM06).

The full stage-by-stage pipeline, including PII scanning of data and prompt review, is laid out in DevSecOps for enterprise AI applications. For the attacker's view of the same systems, see AI security interview questions.

42. How do you establish model provenance, and why prefer safetensors over pickle?

Answer: provenance means you can answer: where did these weights come from, who published them, which exact revision, what licence, which data trained or fine-tuned them, and has the file changed since it was approved? In practice: pull models through an internal model registry or proxy rather than directly from public hubs; pin to an exact revision or commit hash, not a moving branch; record the hash; review the licence; sign approved artefacts; and list models and datasets in an ML bill of materials (CycloneDX and SPDX both support this).

On formats: Python pickle-based files (many older .bin, .pt and .pkl files) can execute arbitrary code when loaded, so loading an untrusted model can compromise the machine. safetensors stores only tensors and metadata, with no code execution on load, so it is the safer default. If you must load pickle-based files, scan them with tools such as ModelScan or picklescan, use the restricted loading modes your framework offers (recent PyTorch versions default torch.load to weights_only=True; check current docs), and load in a sandbox.

43. How do you test for prompt injection in CI?

Answer: treat it like a regression suite. Build a versioned set of adversarial cases for your specific application: direct injections ("ignore previous instructions and..."), indirect injections hidden in retrieved documents, emails or web pages the system processes, attempts to reveal the system prompt, attempts to make an agent call a tool it shouldn't, and data-exfiltration patterns such as rendering a markdown image URL containing user data. Run them on every change to prompts, models, retrieval configuration or tool definitions, and score the outputs with deterministic checks (did a forbidden tool call happen? does the output contain a canary string planted in the system prompt?) plus model-graded checks where needed. Tools such as promptfoo, garak and PyRIT help. Fail the build on high-severity regressions.

Be honest about the limit: no test suite proves an LLM is immune to prompt injection, so the design must also limit impact: least-privilege tools, human approval for consequential actions, output encoding and filtering. The test suite tells you when a change made things worse. For deeper attack methodology, see AI red teaming.

44. What security risks do AI coding assistants introduce, and how do you manage them?

Answer: four main ones. Insecure suggestions: generated code can contain injection flaws, weak crypto or missing authorisation checks and looks plausible enough to pass a quick review. Hallucinated packages: assistants sometimes suggest dependencies that don't exist; attackers can register those names (sometimes called "slopsquatting"), so an npm install or pip install of a suggestion installs malware. Data exposure: source code, secrets or customer data in the context window sent to an external service, depending on the product's data handling terms. Agentic actions: coding agents that run shell commands, edit CI files or open pull requests can be steered by prompt injection in issues, READMEs or dependencies.

Controls: enterprise-licensed tools with agreed data-handling terms and admin policies; the same SAST, SCA and secrets scanning on AI-written code as on human code (no "AI code" bypass); dependency installs only through the internal proxy with new-package checks; CODEOWNERS review for workflow, IaC and auth code; sandboxed agents with no production credentials and restricted network access;. The enterprise rollout side is covered in AI coding assistants in the enterprise.

45. How do you secure ML infrastructure on Kubernetes, such as notebooks, training jobs and model servers?

Answer: apply the normal controls with ML-specific emphasis. Notebooks are a frequent weak point (weak authentication, broad credentials), so put them behind SSO with per-user identities and narrow data permissions. Training jobs should use workload identity with read access only to their datasets and write access only to their output location, run in isolated namespaces with network policies, and use images from the same scanned and signed pipeline as everything else. Model servers (vLLM, KServe, Triton and similar) must not expose admin or model-loading endpoints publicly and should load models only from the approved registry. Kubernetes specifics for AI workloads are covered in the sibling guide Kubernetes for AI interview questions, and the MLOps side in MLOps interview questions.

Metrics and culture

46. Which DevSecOps metrics would you report, and which would you avoid?

Answer: report metrics that show risk going down and delivery staying healthy:

• Mean time to remediate by severity tier, and the share of findings fixed within SLA (Q40).
• Vulnerability ageing: how many open criticals and highs are older than their SLA, per team.
• Escape rate: issues found by pen tests or in production that a pipeline control should have caught.
• Coverage: percentage of repositories with SAST, SCA and secrets scanning enabled; percentage of production images signed and verified at admission. (Report the real figures from your own estate.)
• False-positive rate per rule or tool, and the share of builds blocked by security checks, so you see friction.
• Delivery health: the DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore), to show security isn't slowing delivery.

Avoid vanity metrics such as "total vulnerabilities found" (rewards noisy tools) or "number of scans run". The old maxim still holds: security that slows releases without reducing risk is broken security.

47. How do you build a DevSecOps culture and scale it across a large organisation?

Answer: make security a paved road rather than a checkpoint. Security champions: one interested engineer per team with time allocated, training and a direct channel to the security team; they triage findings and run lightweight threat models. Paved roads: golden pipeline templates, base images, Terraform modules and service templates with scanning, signing and secure defaults built in, so a new service is secure on day one without anyone filing a ticket. Developer experience: findings appear where developers work (pull requests, IDE), with a fix suggestion and a link to guidance. OWASP SAMM or DSOMM help you assess maturity.

Real-world example: a GCC IT team in Hyderabad supporting dozens of product teams cannot have a security engineer review every pipeline. Shipping one reusable workflow that every repository calls, maintained by the platform team, rolls out a new control everywhere with one pull request.

48. How do you handle the tension between delivery speed and security gates?

Answer: decide what blocks based on risk and confidence, keep checks fast, and give teams a clear way through. Block on a small set of high-confidence, high-impact issues (verified secrets, critical exploitable vulnerabilities on internet-facing services, policy violations such as privileged pods or public storage); report everything else into the backlog with SLAs. Keep pull request checks fast, with deeper scans running asynchronously. Provide a documented exception path with approval and expiry so an urgent release isn't blocked by a finding that has a compensating control. If blocked builds rise without less risk, tune the rules.

Real-world scenarios

49. A developer pushed an AWS access key to a public GitHub repository an hour ago. What do you do?

Answer: treat it as an active incident: automated scanners harvest keys from public repositories very quickly, so assume it has been seen. Contain first, clean up second, prevent recurrence third.

What I would check:

1. Deactivate and then delete the key in IAM immediately, and create a replacement only if still needed (ideally replace it with a role or OIDC federation instead).
2. Review CloudTrail for every API call made with that key since the commit: new IAM users or keys, new instances (crypto-mining is common), data access, changes to logging.
3. Check for persistence the attacker might have created: new access keys, roles, Lambda functions, modified trust policies; check billing for unexpected resources across all regions.
4. Check AWS Health notices; AWS may already have flagged the key and attached a quarantine policy.
5. Remove the secret from the repository and history (git filter-repo), accepting that the exposure cannot be undone.
6. Find the root cause: why was a static key on a laptop, and why didn't push protection catch it?

Production consideration: enable push protection organisation-wide and replace human access keys with SSO-based short-lived credentials, so the next mistake has nothing long-lived to leak.

50. Developers are bypassing security scans because they slow pipelines. How do you fix it?

Answer: the bypass is a symptom; fix the cause rather than adding more enforcement first.

What I would check:

1. Measure: how long does each security step add, how often does it block, and what share of blocks were false positives?
2. Make scans fast: diff-aware SAST on pull requests, cached dependency databases, parallel jobs, full scans moved to nightly runs on the main branch.
3. Cut noise: switch low-precision rules to report-only and deduplicate findings across tools.
4. Make the secure path easiest: scans baked into shared pipeline templates so they aren't optional extras, with clear fix guidance inline.
5. Then enforce: required status checks and branch rulesets so scans can't be skipped, and a visible, approved exception path for genuine emergencies.

Production consideration: talk to the teams; a retro often reveals one misconfigured scanner causing most of the pain.

51. A critical, actively exploited vulnerability is announced in a popular Java library. You run hundreds of services. Walk me through the first 48 hours.

Answer: the goal is fast, evidence-based scoping, then mitigation, then patching, with clear communication throughout.

What I would check:

1. Query stored SBOMs and registry scan results for the affected package and versions, including transitive and shaded copies, to list affected services and images.
2. Prioritise by exposure: internet-facing first, then services processing untrusted input, then internal.
3. Apply mitigations that buy time: WAF rules for known exploit patterns, configuration flags that disable the vulnerable feature, egress restrictions.
4. Patch via automated update pull requests through the normal pipeline, rebuild images and redeploy, using expedited approval for the emergency.
5. Look for exploitation: hunt in WAF, application and runtime detection logs for indicators published with the advisory.

Production consideration: this is where an SBOM programme pays for itself; without one, day one goes on finding the library.

52. You discover that a third-party GitHub Action used across your organisation was compromised last week. What do you do?

Answer: assume any secret available to workflows that ran the bad version was exposed.

What I would check:

1. Search the organisation for workflows using the action and identify runs in the compromise window (Actions run history, audit log).
2. Inspect those runs' logs for leaked secrets and delete logs that contain them.
3. Rotate every secret those workflows could access: cloud keys, registry tokens, package-publishing tokens, deploy keys.
4. Review cloud and registry audit logs for use of those credentials; check whether any packages or images were published during the window.
5. Replace the action with a pinned, reviewed SHA or an internal fork, and add it to an allow-list policy.

Production consideration: organisations that had already moved to OIDC had little long-lived to rotate. That is the strongest argument for Q33.

53. You switch on SAST for a ten-year-old monolith and get thousands of findings. How do you onboard it?

Answer: baseline the past, block the future, and burn down by risk.

What I would check:

1. Record the current findings as a baseline so pull requests are judged only on new issues.
2. Sample and triage the top rule categories to measure precision; disable or tune noisy rules for this codebase.
3. Rank remaining legacy findings by exploitability and exposure: injection in internet-facing endpoints first, findings in dead code last.
4. Agree a burn-down target with the product owner, and fit fixes into regular sprints rather than a one-off "security sprint".

Production consideration: never let the size of the backlog delay turning on blocking for new code. The baseline makes that possible from day one.

54. CSPM flags a storage bucket in production that is publicly readable. What do you do?

Answer: confirm the exposure and its intent quickly, then contain, then investigate access.

What I would check:

1. Identify the owner and the contents: is this a deliberately public static website bucket, or does it hold internal data?
2. If unintended, block public access immediately (bucket and account-level public access block), then notify the owner.
3. Review access logs or data events for reads by unknown parties during the exposure window, to decide whether this is a data breach requiring legal and DPDP Act notification assessment.
4. Find how it happened: Terraform change, console click, or a policy that let it through? Fix the pipeline policy and add an organisation-level guardrail.

Production consideration: legitimately public buckets should be explicitly tagged and served through a CDN with origin access control, so the CSPM exception is deliberate and auditable. Indian privacy obligations for AI and data systems are discussed in the DPDP Act for AI applications.

55. Falco alerts that a shell was spawned inside a production payment-service pod. What now?

Answer: it could be an engineer debugging or an attacker; find out fast without destroying evidence.

What I would check:

1. Check the Kubernetes audit log: was there a kubectl exec by a known identity with a ticket?
2. If not explained, isolate the pod with a deny-all NetworkPolicy and remove it from service endpoints (relabel it) rather than deleting it, so the evidence survives.
3. Capture evidence: process tree, network connections, filesystem changes; snapshot the node if needed.
4. Check how it got in: vulnerable dependency, exposed endpoint, stolen credentials? Check the service account's permissions and what it could reach.
5. Rotate the secrets the pod had access to, redeploy from a known-good signed image, and patch the entry point.

Production consideration: if exec into production pods is routine for debugging, that itself is a finding. Move to ephemeral debug containers with approval and audit, and tune the rule so true positives stand out.

56. Your multi-cloud pipelines use long-lived AWS, Azure and GCP keys stored as CI secrets. How do you migrate?

Answer: migrate to federated, short-lived credentials one cloud and one environment at a time, without breaking deployments.

What I would check:

1. Inventory every stored cloud credential: which pipelines use it, what permissions it has, when it was last used.
2. Set up OIDC trust per cloud: an IAM OIDC provider and role trust policies on AWS, federated credentials on Entra ID apps or managed identities for Azure, Workload Identity Federation on Google Cloud.
3. Scope trust to repository and environment claims, with separate roles for plan, deploy-to-test and deploy-to-production.
4. Switch pipelines over in non-production first, then production; tighten permissions using access analysis of what the old keys actually used.
5. Delete the old keys, and add a policy or detection that alerts if new long-lived CI keys are created.

Production consideration: keep one documented break-glass credential, stored offline with strict access, monitored and rotated, for when the CI platform itself is unavailable.

57. A bank's auditors want evidence that every production change was reviewed, tested and scanned. How do you provide it?

Answer: consider a bank preparing for a regulatory or PCI DSS audit. The answer should be "query the pipeline", not "collect screenshots".

What I would check:

1. Branch protection or rulesets on production branches requiring approvals and passing status checks, with exported settings history.
2. For each production deployment: the commit, pull request approvals, test and security scan results, and the artefact digest, linked by deployment records.
3. Signed provenance and admission logs showing that only artefacts built by the approved pipeline were deployed.
4. Exception records with approver and expiry for anything deployed with open findings.
5. Evidence retained in tamper-resistant storage for the bank's required period, designed before the audit rather than reconstructed after it.

Production consideration: link deployment records to change tickets automatically, so evidence exists without anyone remembering to file it.

58. A data science team wants to deploy an open-weight model downloaded from a public hub into a production RAG assistant. What controls do you require?

Answer: treat the model as an untrusted third-party dependency until it passes intake.

What I would check:

1. Publisher and licence review: is the publisher who they claim to be, and does the licence allow this commercial use?
2. Format: safetensors preferred; scan any pickle-based files; reject models that need remote code unless that code is reviewed and vendored.
3. Pin the exact revision and hash, store it in the internal model registry, sign it and record it in the ML bill of materials.
4. Run security evaluations before approval: prompt-injection and jailbreak suites, sensitive-data leakage tests, and behaviour on the bank's or hospital's own test set.
5. Deploy with the standard controls: scanned serving image, least-privilege identity, no public admin endpoints, rate limits, logging.

Production consideration: licence and risk trade-offs for open-weight models are covered in open-weight LLMs for enterprise.

59. Red-team testing finds that a document uploaded to your internal AI assistant can make it email confidential data to an outside address. How do you respond and prevent it in future?

Answer: this is indirect prompt injection combined with excessive agency. Contain the capability first, then fix the design, then add the case to CI.

What I would check:

1. Disable or restrict the email tool immediately (allow internal recipients only, or require human approval for every send).
2. Search tool-call logs for past sends to external addresses to see whether this was exploited.
3. Fix the design: least-privilege tools, human-in-the-loop for consequential actions, separation of retrieved content from instructions, and output filtering for data-exfiltration patterns.
4. Add the attack and variants to the prompt-injection regression suite (Q43) so a future prompt or model change can't reintroduce it.

Production consideration: agent permissions should be designed like service-account permissions. AI agent identity and access covers the patterns.

60. You join a GCC in Bengaluru as its first DevSecOps lead. There is CI/CD but almost no security automation. What is your 90-day plan?

Answer: start with visibility and the highest-impact low-friction controls, then build paved roads, then enforce.

What I would check:

1. Days 1 to 30: inventory repositories, pipelines, cloud accounts and clusters with owners; turn on secrets scanning with push protection and SCA everywhere in report-only mode; enable CSPM across accounts; find and rotate exposed secrets; pick two pilots.
2. Days 31 to 60: build a shared pipeline template with SAST, SCA, IaC and image scanning plus SBOM generation; migrate the pilots' cloud access to OIDC; apply Pod Security Admission in warn mode; publish remediation SLAs agreed with engineering leadership; recruit security champions.
3. Days 61 to 90: roll the template out widely; switch high-confidence checks to blocking; add image signing and admission verification for production clusters in audit mode; report the first metrics (coverage, MTTR, ageing); run threat models for the two highest-risk systems.

Production consideration: say what you would not do in 90 days: buy a large platform before knowing the gaps, or block every pipeline on day one.

Key takeaways

• Place each control where it catches something earlier stages cannot: SAST and secrets in the pull request, SCA continuously, DAST against running environments, runtime detection in production.
• Signal quality decides adoption. Diff-aware scanning, tuned rules and expiring suppressions keep developers using the tools.
• Supply chain security is now core: SBOMs from the built artefact, SLSA provenance, keyless signing with cosign, verification at admission, dependencies and actions pinned by hash or SHA.
• Remove long-lived credentials wherever possible: OIDC federation for CI, workload identity for pods, dynamic secrets where a secret is unavoidable.
• Prioritise vulnerabilities with exploitation and context (KEV, EPSS, reachability, exposure), not CVSS alone, and give every finding an owner and an SLA.
• AI pipelines add models, datasets and prompts to the supply chain: safetensors, pinned revisions, model provenance and prompt-injection regression tests in CI.

Interview preparation checklist

• Build a small pipeline (GitHub Actions or GitLab CI) that runs Semgrep or CodeQL, an SCA scan, Gitleaks, Checkov or Trivy on Terraform, and Trivy on a container image.
• Generate an SBOM with Syft or Trivy, sign an image with cosign in keyless mode, and verify it with an identity constraint.
• Configure GitHub Actions OIDC to assume an AWS role (or Azure federated credential) scoped to one repository and environment, and be ready to explain the trust policy.
• Write one Kyverno or Gatekeeper policy (for example, deny images outside your registry) and one Rego policy for a Terraform plan, with tests.
• Practise one STRIDE threat model on a system you know, out loud, in ten minutes.
• Prepare two stories from your own work: a security improvement you shipped and a false-positive or friction problem you solved.
• Read the OWASP Top 10 (2025), the OWASP Top 10 for LLM Applications (2025) and the SLSA Build track levels so you can name them accurately.

FAQ

What skills are required for a DevSecOps engineer role?

Solid DevOps foundations (Linux, Git, CI/CD, Docker, Kubernetes, Terraform, one major cloud) plus application security basics, scanner tuning, IAM, secrets management, supply chain security and enough scripting in Python or Bash to automate checks.

Is DevSecOps a good career for DevOps engineers?

It is a natural next step. You keep your pipeline and cloud skills and add security depth, and organisations in regulated sectors such as banking, insurance and healthcare need people who can do both.

Do I need to know how to code for DevSecOps interviews?

Yes, at a practical level. Expect to read application code for vulnerabilities, write pipeline YAML, and script small tools in Python or Bash. Deep software engineering is less important than reading and automating.

Which DevSecOps tools should I learn first?

Learn one tool per category rather than many in one: a SAST tool, an SCA tool, a secrets scanner, an IaC scanner, a container scanner, cosign, a Kubernetes policy engine and your cloud's native security services. Understanding the category matters more than the brand.

Are certifications needed to get a DevSecOps job?

They can help you get shortlisted, but interviewers mostly test hands-on understanding. A public repository showing a secured pipeline, signed images and policies is strong evidence of skill.

How should freshers prepare for DevSecOps interviews?

Learn DevOps fundamentals first, then add the security layer: OWASP Top 10, SAST versus DAST, secrets scanning, container scanning and IAM basics. Build one secured pipeline project and be able to explain every step.

How is DevSecOps different from cloud security engineering?

DevSecOps focuses on securing the delivery pipeline and the software it produces. Cloud security engineering focuses on the cloud estate itself: identity, network, posture and detection. The roles overlap heavily in IaC, CSPM and workload security.

Do DevSecOps interviews now include AI and LLM security?

Increasingly, yes, especially where teams ship AI features. Be ready to discuss model provenance, safe model formats, prompt-injection testing in CI and the risks of AI coding assistants.

How long does it take to prepare for a DevSecOps interview?

It depends on your starting point. An experienced DevOps engineer can cover the security layer in a few focused weeks with hands-on labs; a fresher needs longer because the DevOps foundations come first.

DevSecOps interviews reward people who have actually wired these controls into a pipeline and tuned them. Cloudsoft's DevSecOps course covers secure CI/CD, supply chain signing, Kubernetes policy and cloud security posture through labs. If you want security alongside AI, ML and cloud engineering in one programme, look at the APEX AI, ML, Cloud and Cyber Security program. Both run in the Ameerpet classroom (beside Ameerpet Metro) or live online; call +91 96660 19191 for a free demo.

Related Cloudsoft resources

• DevSecOps for enterprise AI: securing the AI delivery pipeline
• AI security interview questions
• AI red teaming: how to test LLM applications
• Kubernetes for AI interview questions
• Advanced Kubernetes interview questions (scenario based)
• CI/CD for AI applications
• FinOps interview questions for cloud engineers