The interviewer asks: "What does 'shift-left security' mean and how have you implemented it?" Which answer best demonstrates DevSecOps practice?
Option B is strongest because it defines shift-left precisely (SDLC integration at each stage) and provides concrete tooling at each layer: IDE → pre-commit → CI pipeline. Key structure: IDE plugins → pre-commit hooks → SAST/SCA in CI → threat modelling at design phase → remediation cost metric. Option A describes a single gate (before production) which misses the "left" point. Option C confuses a process change with a tooling/architectural change. Option D confuses responsibility distribution with shift-left.
2 / 5
The interviewer asks: "What is the difference between SAST and DAST, and when do you use each?" Which answer best demonstrates security testing knowledge?
Option B correctly reverses the order of A's definition, names the vulnerability classes each finds, and provides tooling for each. Key structure: SAST = static → CI → SonarQube/Semgrep; DAST = dynamic → staging → ZAP/Burp Suite; combined coverage = code + runtime. Option A completely reverses the definitions. Option C is a false dichotomy. Option D is incorrect — pen testing and SAST/DAST are related but distinct practices.
3 / 5
The interviewer asks: "How do you secure container images in a production Kubernetes environment?" Which answer best demonstrates container security depth?
Option B is strongest because it covers all five security layers in the container lifecycle: build (image hardening), CI (scanning), admission (policy enforcement), runtime (anomaly detection), and network (segmentation). Key structure: distroless → digest pinning → Trivy in CI → OPA/Kyverno admission → Falco runtime → network policies → Cosign signing. Option A is dangerous — "latest" tag is unpredictable and can introduce regressions. Option C is reactive (weekly) and misses in-cluster protection. Option D names tools but lacks architectural depth.
4 / 5
The interviewer asks: "What is compliance-as-code and which tools have you used?" Which answer best demonstrates policy automation maturity?
Option B is strongest because it defines the concept precisely (policies as code, enforced automatically), names tools at each layer (IaC, Kubernetes, cloud), and connects to audit requirements (SOC 2, ISO 27001). Key structure: Checkov (IaC) → OPA/Conftest (K8s manifests) → AWS Config/Azure Policy (cloud) → Git-versioned policies → audit trail. Option A confuses documentation-as-code with policy-as-code. Option C describes manual checklist compliance (the opposite of automation). Option D misdefines the concept entirely.
5 / 5
The interviewer asks: "How do you handle secrets management in a CI/CD pipeline?" Which answer best demonstrates production-grade secrets hygiene?
Option B is strongest because it addresses secrets at every stage: pre-commit (scanning), CI/CD (OIDC, no stored keys), runtime (Vault/Secrets Manager injection), and operational (rotation + audit). Key structure: Gitleaks pre-commit → OIDC no static keys → Vault/Secrets Manager injection → dynamic credentials → audit logging. Option A stores secrets in CI env vars — they are visible in logs and to CI admins. Option C uses .env files which are manually shared (no rotation, no audit). Option D — base64 is encoding, not encryption — a critical misconception.