DevSecOps Interview Questions and Answers

What interviewers are testing: Whether you understand where DevSecOps sits in the security lifecycle—automated preventive/detective controls in delivery versus application-security design work and offensive validation.

DevSecOps prevents and detects misconfigurations and vulnerable artifacts continuously. Penetration testing validates residual risk periodically—they complement each other but interview loops differ. This guide stays on the defensive delivery side.

A strong answer is:

"DevSecOps automates guardrails in CI/CD and infrastructure. AppSec advises on design flaws. Pentesting finds what slipped through—I do not conflate building secure pipelines with running exploits in interviews unless the role is explicitly offensive."

What interviewers are testing: Whether shift-left means earlier feedback in design and CI—not more production scans only.

Shift-left moves security activities earlier in the lifecycle—design and commit time—when fixes are cheaper.

Shift-left does not eliminate production monitoring—it reduces what reaches prod untested.

A strong answer is:

"Shift-left means developers get security feedback in the PR, not a ticket three weeks after release. I automate what I can in CI and reserve manual review for architecture risk."

What interviewers are testing: Whether you thread security through every SDLC phase, not a final gate before release.

A secure SDLC threads security through:

1. Requirements — abuse cases, data classification
2. Design — threat model, trust boundaries
3. Implementation — secure libraries, secret management
4. Verification — SAST, SCA, test coverage, pen test where warranted
5. Release — change approval, signed artifacts
6. Operations — monitoring, patching, incident response
7. Decommission — data retention and secure disposal

DevSecOps automates verification and operations phases heavily.

A strong answer is:

"Secure SDLC is security at every phase—not a final scan. DevSecOps automates verify and operate with pipelines, policy-as-code, and runtime controls."

What interviewers are testing: Whether you turn STRIDE findings into concrete controls in code and pipelines.

Threat modeling identifies assets, trust boundaries, and plausible attacks before code ships.

Common frameworks: STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege).

DevSecOps engineers often facilitate lightweight models for new services and translate findings into pipeline checks (auth required, encryption in transit, no public storage).

A strong answer is:

"Threat modeling identifies assets, trust boundaries, and likely abuse paths. I turn the important findings into concrete controls—for example authenticated service communication, default-deny network rules, and preventing secrets from being exposed in source, logs, or build artifacts."

What interviewers are testing: Whether you apply least privilege from cloud IAM down to non-root containers.

Least privilege limits identity and access to the minimum required:

See Linux interview questions for user, group, and permission depth.

A strong answer is:

"Least privilege everywhere—CI jobs get scoped tokens, pods run non-root, humans get break-glass admin only when audited. Default allow is the anti-pattern."

What interviewers are testing: Whether you tune risk-based gates and golden paths—not universal merge blockers.

Interviewers want risk-based gates, not universal blockers:

• Block findings per risk policy—for example exploitable critical vulnerabilities, known-exploited CVEs, committed secrets, or prohibited IaC configurations. Severity alone should not be the only decision signal
• Warn on medium findings with ticket SLA
• Baseline secure templates so developers start compliant
• Measure false-positive rate and time-to-fix
• Partner with dev leads on exception process with expiry

A strong answer is:

"I use risk-based gates: committed secrets and findings that violate our exploitation or exposure policy block promotion, while lower-risk issues can enter an owned remediation SLA. Secure templates and time-bound exceptions keep security from becoming an arbitrary merge blocker."

What interviewers are testing: Whether you list gates that fail the build—secrets, SAST, SCA, IaC, image scan.

Security controls should block the relevant transition—merge, artifact promotion, or deployment—when policy is violated, rather than only producing a report nobody acts on. Stage order and which checks block promotion are pipeline design questions—see CI/CD interview questions for the full delivery flow; here the focus is what security gates belong in that flow.

A strong answer is:

"Every merge runs secret scanning, SAST, SCA, and IaC checks; built images are scanned before promotion. I block according to risk policy—for example committed secrets, known-exploited vulnerabilities, or exploitable critical findings—not severity alone."

What interviewers are testing: Whether you place SAST in CI and DAST on staging and what each class catches.

SAST catches SQL injection patterns early; DAST finds misconfigured headers and auth bypasses in deployment.

A strong answer is:

"SAST analyzes code without executing the application; DAST tests the running application from the outside. I use SAST for early feedback and DAST to catch runtime and deployment-level issues."

What interviewers are testing: Whether you prefer vault injection and OIDC over long-lived keys in CI config.

Secrets in CI/CD should be:

• Stored in vault or CI secret manager—not in Git or env files in repo
• Injected at runtime into the job, not logged
• Scoped per environment and job type
• Rotated on schedule and after incidents
• Audited for access

Use OIDC federation to cloud so pipelines never store long-lived AWS_ACCESS_KEY_ID.

A strong answer is:

"Secrets stay outside source control and are injected only into the jobs that need them. I prefer workload identity or OIDC for cloud access, and I run secret scanning on repository changes and history so accidental credentials are detected quickly."

What interviewers are testing: Whether you tie signed commits to branch protection and provenance—not vanity crypto.

Signed commits (GPG or SSH signing) provide cryptographic verification that a commit was signed by a trusted key associated with the contributor. Whether that key reliably maps to the claimed human identity depends on your trust model and key verification. Protected branches enforce reviews and status checks before merge. Combined with reviews and CI checks, signed commits strengthen provenance and auditability.

Together they reduce:

• Unauthorized or unreviewed changes to protected branches
• Unsigned commits where signed commits are required
• Merges without required reviews or status checks
• Force-push or history rewriting when branch policy prohibits force pushes

Detail merge strategies in Git interview questions.

A strong answer is:

"Protected main requires PR, reviews, and green CI—including security scans. Signed commits verify the signing key behind each commit and strengthen audit trails when paired with branch protection."

What interviewers are testing: Whether you treat SBOM as inventory for CVE response, not a vulnerability report itself.

An SBOM (Software Bill of Materials) lists components in an artifact—libraries, packages, licenses, versions. An SBOM is an inventory, not a vulnerability report; a vulnerability scanner correlates those components with vulnerability intelligence.

Drivers:

• Compliance and customer requirements — SBOM inventory supports faster CVE response and vendor transparency
• Faster CVE response — know if log4j is in the image without guessing

Generate SBOMs during the build/release process and retain them with, or link them to, the corresponding immutable artifact.

A strong answer is:

"An SBOM is an ingredient list for software. When a CVE drops, I query SBOMs across services instead of grepping repos manually."

What interviewers are testing: Whether you harden image build and runtime—non-root, minimal base, read-only rootfs.

Image build hardening:

Runtime hardening (often Kubernetes/container settings):

A strong answer is:

"I harden the image build with a minimal base, non-root user, no embedded secrets, and CI scanning. At deployment I add runtime controls such as a read-only root filesystem, dropped capabilities, and an appropriate seccomp profile."

What interviewers are testing: Whether you know that a smaller image is not automatically a safer image and can evaluate compatibility, attack surface, patching, provenance, and operability together.

Security depends on package content, patch cadence, provenance, vulnerability exposure, runtime needs, and debuggability—not image size alone.

A strong answer is:

"Minimize unnecessary runtime components. Distroless, slim distro images, and carefully maintained Alpine-based images are different trade-offs—I choose based on compatibility and patchability rather than size alone."

What interviewers are testing: Whether you understand image signing and admission policy as supply-chain trust controls.

Image signing binds a cryptographic identity to an image digest so consumers can verify who signed that exact content. Separate attestations can carry provenance, SBOM, or other supply-chain metadata.

Typical flow:

1. CI builds image
2. CI signs the image digest using a managed key or keyless workload identity
3. Cluster admission policy verifies the signature and, where required, provenance/attestation before deployment
4. Policy rejects unsigned or foreign-registry images

For digest-level signing and cluster verification, see sign and verify container images with Cosign.

A strong answer is:

"A verified signature tells me that a trusted signing identity signed this exact image digest; provenance tells me how it was built. Admission policy can then allow only artifacts that satisfy our signature and attestation requirements."

What interviewers are testing: Whether you know how dependency confusion exploits package resolution and how to prevent it.

Dependency confusion occurs when a build resolves an intended private dependency to an attacker-controlled public package because naming, namespace, version, or repository precedence is not properly constrained.

Mitigations:

• Scope private packages with namespace ownership
• Pin versions and verify checksums
• Use private registry proxy with pull-through rules
• Block public namespace collisions in CI policy

A strong answer is:

"I scope internal packages, pin lockfiles, and route builds through a private registry that cannot be confused with public PyPI or npm."

What interviewers are testing: Whether you prioritize exploitable CVEs in your code path—not every low in base layers.

Do not chase every low CVE in a demo nginx layer—interviewers want prioritization.

A strong answer is:

"I prioritize CVEs using exposure, exploitability, known exploitation, severity, and whether our workload actually uses the vulnerable component. Then I patch or rebuild, rescan, and give any temporary exception an owner and expiry."

What interviewers are testing: Whether you understand Kubernetes RBAC as least-privilege API access for workloads and humans—not blanket cluster-admin for applications.

RBAC depth—Role vs ClusterRole, bindings—lives in Kubernetes interview questions.

A pod can consume a Secret mounted or injected by Kubernetes without its ServiceAccount necessarily receiving API permission to get or list Secret objects.

A strong answer is:

"I give workloads dedicated or appropriately scoped ServiceAccounts and grant only the API permissions they require. Most application pods do not need broad Secret read/list permissions."

What interviewers are testing: Whether you know NetworkPolicy requires an enforcing CNI and default-deny only works when ingress and egress are explicitly controlled.

Without policies selecting a pod, Kubernetes NetworkPolicy does not restrict that pod's ingress or egress for the relevant direction. In many clusters this effectively leaves pod-to-pod traffic broadly open, subject to the CNI and other network controls.

NetworkPolicy enforcement depends on a CNI/network implementation that supports the NetworkPolicy API—creating the object alone does not guarantee isolation. For default-deny rules and CNI caveats, see Kubernetes NetworkPolicy.

Default-deny plus explicit allow rules:

• Ingress only from ingress controller namespace
• Egress to DNS (UDP/TCP 53) and required APIs only
• Deny lateral movement after compromise

A strong answer is:

"Where the cluster networking implementation enforces NetworkPolicy, I start with default deny and explicitly allow only required ingress and egress—for example ingress from the application gateway and egress to DNS and the database. That limits lateral movement if a workload is compromised."

What interviewers are testing: Whether you define Kubernetes admission control as the enforcement layer after RBAC—and how PSA relates to PSS.

Admission controllers validate or mutate API requests before persistence.

Security examples:

• OPA Gatekeeper / Kyverno — reject privileged pods, require labels, enforce image registry or signature policy
• Pod Security Admission — baseline/restricted workload-security profiles (privileged mode, host namespaces, hostPath, capabilities, seccomp)
• Image signature verification — cosign policy

A strong answer is:

"RBAC decides whether an identity may submit the Pod request; admission decides whether that requested Pod configuration is acceptable. Pod Security Admission can enforce the Pod Security Standards, while separate admission policies can enforce organization-specific requirements such as trusted registries or signed images."

What interviewers are testing: Whether you understand Kubernetes Secrets need RBAC, encryption at rest, and often an external manager for rotation and governance.

Secret values in the Kubernetes API manifest are base64-encoded, which is not encryption. By default, Secret data can be stored unencrypted in etcd; configure encryption at rest and restrict RBAC to protect it.

A strong answer is:

"Kubernetes Secrets are sensitive API objects, not a replacement for strong secret-management controls. I restrict RBAC, enable encryption at rest, and use an external secret manager when lifecycle, rotation, or centralized governance requires it."

What interviewers are testing: Whether you know Pod Security Standards define profiles and Pod Security Admission enforces or audits them.

Pod Security Standards define three profiles:

Pod Security Admission enforces profile per namespace label (enforce, audit, warn). Profile requirements and label wiring are documented in Kubernetes Pod Security Standards.

A strong answer is:

"I use Restricted where workloads support it and Baseline where compatibility requires more flexibility. Privileged should be limited to explicitly approved workloads or namespaces that genuinely require those permissions."

What interviewers are testing: Whether you treat Terraform state as sensitive and protect plan/apply workflows with policy and least privilege.

Supplying a secret from a vault prevents it from being hard-coded in configuration, but depending on how a provider or resource handles the value, Terraform may still store it in state. The sensitive flag mainly redacts output; it does not by itself prevent state storage. Some provider mechanisms—such as ephemeral values or write-only arguments where supported—can avoid persistence. Treat state and saved plan files as sensitive.

Hands-on Terraform lives in the Terraform Associate course.

A strong answer is:

"Terraform changes go through PR review with a plan, policy checks, and scoped apply credentials. I treat both state and saved plans as sensitive, store state remotely with encryption and access controls, and avoid hard-coding credentials in configuration."

What interviewers are testing: Whether you understand drift as unaudited infrastructure change that can create unknown exposure.

Drift is when live infrastructure diverges from IaC—someone changed a security group in the console.

Risks:

• Unknown exposure — port 22 opened manually
• Audit failure — Git no longer matches reality
• Reapply surprises — next terraform apply breaks prod

Detect with scheduled terraform plan, drift detection tools, and IAM and workflow controls that restrict out-of-band changes on governed resources.

A strong answer is:

"Drift is an unreviewed difference between declared IaC and live infrastructure. I detect it with scheduled plans or platform drift detection, investigate the source, and restrict out-of-band production changes so normal changes flow through review."

What interviewers are testing: Whether you know host-level hardening still matters beneath containers and Kubernetes.

At interview breadth (detail in Linux interview questions):

• SSH — disable direct root login; use strong centralized, key, or certificate-based authentication and restrict administrative access
• Patching — automated security updates or rapid cadence
• SELinux / AppArmor — enforcing mode where supported
• Auditd — record configured security-relevant events such as privileged execution, sensitive file access, identity changes, or selected syscalls
• Firewall — firewalld or nftables default deny
• Immutable infra — replace VMs/containers instead of snowflake SSH fixes

A strong answer is:

"Hosts get restricted SSH administration, enforced MAC where supported, firewall default deny, and patching SLAs. For containers I prefer immutable images over perpetual SSH patching."

What interviewers are testing: Revoke-first discipline on leaked cloud keys—assume compromise before Git cleanup.

Ordered response:

1. Revoke/disable the exposed credential immediately
2. Determine scope and preserve/investigate evidence using CloudTrail and relevant service logs
3. Rotate related credentials if exposure may extend beyond the original key
4. Remediate unauthorized changes
5. Remove the secret from current content/history where appropriate, while assuming the public value is permanently compromised
6. Prevent — secret scanning, pre-commit hooks, OIDC instead of keys
7. Post-incident — blameless review; improve developer docs

A strong answer is:

"I revoke the credential first because a public secret must be treated as compromised. Then I investigate its use, remediate anything it accessed or changed, clean the repository, and prevent recurrence with secret scanning and short-lived workload identities."

What interviewers are testing: Whether you can distinguish SAST, SCA, secret scanning, IaC scanning, and container scanning by what each inspects.

A strong answer is:

"SAST analyzes our code, SCA inventories dependencies, secret scanning looks for exposed credentials in source or repository history, IaC scanning checks infrastructure configuration, and container scanning examines the artifact we plan to ship."

What interviewers are testing: Whether you understand artifact provenance as build-time trust metadata—not just a signature on the final image.

A strong answer is:

"A verified signature tells me that a trusted signing identity signed this exact artifact digest; provenance tells me where and how it was produced. For production, I want that digest traceable to an approved repository, commit, and trusted build workflow."

What interviewers are testing: Whether you can map supply-chain threats from source through build, dependencies, artifacts, and deployment.

Common threats:

• Compromised developer credential
• Malicious dependency
• Compromised CI runner
• Poisoned cache
• Altered artifact
• Registry compromise
• Stolen signing identity
• Deployment of untrusted image

Map controls:

For a practical scan → SBOM → sign → digest promotion pipeline, see secure container image promotion in CI/CD.

A strong answer is:

"I assume attackers can poison source, dependencies, CI, or the registry. Controls chain from protected Git through signed artifacts to admission policy that only trusts our pipeline identity."

What interviewers are testing: Whether you treat CI runners as systems executing potentially hostile build code and isolate credentials, networks, mounts, and persistence accordingly.

A strong answer is:

"I assume CI executes attacker-controlled code. Untrusted PRs run on isolated ephemeral workers without production credentials or privileged host mounts."

What interviewers are testing: Whether you understand break-glass as audited, time-bound emergency privilege rather than standing production administrator access.

Break-glass is time-bound emergency privilege when normal standing admin is not appropriate:

• Avoid standing production administrator privileges where practical; use just-in-time or time-bound elevated access for emergency operations
• Emergency privilege is time-bound and justified
• Access is approved where feasible and always audited
• Credentials are rotated or revoked afterward
• Incident use is reviewed in postmortems

A strong answer is:

"I minimize standing production privilege. Break-glass access gives an authorized engineer time-bound, audited elevation for an emergency, and that access is revoked and reviewed afterward."

What interviewers are testing: Whether you govern exceptions with documented risk, ownership, compensating controls, and expiry—not permanent suppressions.

A time-bound exception or waiver is acceptable when fix before release is genuinely blocked, but it must be governed:

A strong answer is:

"I do not permanently suppress findings. I document the risk, assign business and security owners, add compensating controls where possible, scope the exception narrowly, set an expiry, and open a remediation ticket—then re-scan before the exception expires."