<style> body, p, li { text-align: justify; } </style>

Interview Questions: DevSecOps

Companion question bank for the 6-part tutorial series in this folder: 01-fundamentals-and-shift-left.md, 02-sast-dast-sca.md, 03-container-and-kubernetes-security.md, 04-secrets-management-and-iam.md, 05-cicd-pipeline-security-and-supply-chain.md, 06-compliance-and-cheatsheet.md.

Answers are short and plain on purpose — use the diagrams, commands, and worked examples from the tutorials to expand them out loud.

---

Part 1 Questions: Fundamentals & Shift-Left

1. What is DevSecOps, in one sentence?#

DevOps with security folded in as everyone's job, checked continuously at every stage, instead of one team reviewing everything right before release.

2. Why did the old "security team reviews everything at the end" model break down?#

It doesn't scale — a small security team can't manually review every change from a large, fast-moving org, so it becomes a bottleneck, and finding a serious flaw right before a release deadline creates painful, late, expensive fixes.

3. What does "shift-left" mean?#

Move security checks earlier in the timeline — catching an issue in a spell-check-as-you-type way (in the IDE, in code review) instead of only after the whole document (or app) is finished.

4. Why does the cost of fixing a bug grow at each later stage?#

A design-time flaw is just an idea, cheap to change. A production flaw can mean an active breach, incident response, customer impact, and regulatory fallout — none of which apply if it's caught before a single line of code ships.

5. Walk through STRIDE.#

Spoofing (pretending to be someone you're not), Tampering (maliciously changing data/code), Repudiation (denying you did something, no proof either way), Information Disclosure (data leaking to someone who shouldn't see it), Denial of Service (making something unavailable), Elevation of Privilege (gaining more access than you should have).

6. Explain the shared responsibility model.#

The cloud provider secures "the cloud" itself — physical hardware, hypervisor. You secure what you put "in" the cloud — your data, your access configuration, your app code. Most real cloud breaches are customer-side misconfigurations, not provider failures.

7. What's "security as code"?#

Writing security policy as automatically-enforced code (like an OPA/Rego rule) instead of a PDF/wiki page nobody reads — enforced on every change, every time, with zero reliance on human memory.

---

Part 2 Questions: SAST, DAST, SCA

8. What's the difference between SAST, DAST, and SCA, in one line each?#

SAST reads your own source code without running it. DAST attacks a running app from the outside, like a real attacker. SCA checks your third-party dependencies against known vulnerability databases.

9. How does SAST actually find vulnerabilities under the hood?#

Data-flow (taint) analysis — it traces untrusted input (a "source," like user input) through the code and flags it if that data reaches a dangerous operation (a "sink," like a raw SQL query) without being sanitized along the way.

10. Why should active DAST scans never run against production?#

They genuinely attack the target — submitting forms, injecting payloads, sometimes triggering real state changes like creating test orders. Only run active scans against staging.

11. Why are transitive dependencies such a big deal for SCA?#

A real app might have 20 direct dependencies but hundreds or thousands of transitive ones (dependencies of dependencies). A serious vulnerability can sit several levels deep in a package nobody on the team has ever heard of — manual review simply doesn't scale here.

12. Does a high CVSS score always mean "fix this first"?#

No — CVSS measures theoretical severity, not whether the vulnerable code path is actually reachable in your app. A 9.8 CVSS bug in a function you never call is a lower real priority than a 6.5 sitting directly in your request-handling path.

13. Name a few OWASP Top 10 categories and what tool typically catches each.#

Injection (SAST, DAST), Vulnerable & Outdated Components (SCA), Security Misconfiguration (DAST, IaC scanning), Broken Access Control (SAST code review + DAST).

---

Part 3 Questions: Container & Kubernetes Security

14. Why does a container need image scanning on top of SCA?#

SCA checks your app's own dependency manifest. Image scanning checks the base OS and runtime layers underneath your app — a completely different set of packages, with their own possible CVEs.

15. List the key Dockerfile hardening changes and why each matters.#

Pin an exact version (not :latest — unreproducible, unpredictable). Use multi-stage builds (final image doesn't carry build tools it doesn't need). Run as a non-root user (limits what an attacker can do if the app is exploited). Never bake secrets into image layers (permanently embedded, extractable by anyone who can pull the image).

16. Are containers as isolated as VMs?#

No — containers share the host's kernel (isolated via namespaces/cgroups/seccomp), while a VM has its own separate kernel with hardware-level isolation. A serious kernel vulnerability can theoretically let a container "escape" — which is exactly why non-root and minimal images matter as layered defenses.

17. What's the least-privilege principle applied to Kubernetes RBAC?#

Grant exactly the permissions needed, in exactly the namespace needed, nothing more. A CI pipeline that only updates Deployments in one namespace should never get cluster-admin "just in case" — that turns a compromised credential into a full cluster compromise.

18. What's the default network behavior between pods in Kubernetes, and why does it matter?#

By default, ANY pod can talk to ANY other pod, cluster-wide — no isolation at all. This means a compromised low-risk pod can freely reach a high-risk internal service unless you add explicit, default-deny NetworkPolicies.

19. Are Kubernetes Secrets encrypted by default?#

No — only base64-encoded at rest, which is trivially reversible by anyone with sufficient access. Real protection needs etcd encryption-at-rest and/or a dedicated secrets manager.

20. What does Falco add that scanning and RBAC can't provide?#

Real-time, behavior-based detection — e.g., "a shell was spawned inside a container that normally never spawns shells." It catches genuinely novel attacks that don't match any known, pre-identified pattern.

---

Part 4 Questions: Secrets Management & IAM

21. Why are secrets the single highest-value target for an attacker?#

A leaked secret can bypass every other control you've built — perfect RBAC, perfect network policies, perfect scanning mean nothing if an attacker simply has a valid password sitting in plain text.

22. Does deleting a secret from a git file actually remove it?#

No — it's still fully present in every prior commit's history. The only real fix is treating it as permanently compromised and rotating it immediately.

23. What should you do the moment a secret leaks — rotate first or investigate first?#

Rotate first, always. Every minute of delay is a minute an attacker (who may have found it independently) can use it. Investigate afterward.

24. What's Vault's "dynamic secrets" feature, and why is it powerful?#

Instead of one shared, long-lived password, Vault can generate a brand-new, unique credential on demand for each app instance, and automatically delete it after a set lease (e.g., 1 hour). A leak now self-expires quickly instead of staying valid indefinitely, and every action is traceable to a specific credential/instance.

25. Explain envelope encryption simply.#

A fast, local, one-time-use key (the data key) does the heavy lifting of encrypting your actual data. Only that small data key itself gets encrypted by the cloud KMS. This avoids a slow network round-trip to the KMS for every byte of data — only one call is needed, regardless of data size.

26. Why prefer workload identity (IAM roles) over long-lived static access keys?#

Workload identity credentials are automatically issued, automatically rotated, short-lived, and never stored anywhere — there's nothing sitting in a config file or secrets manager to leak in the first place.

---

Part 5 Questions: CI/CD & Supply Chain Security

27. Why did the SolarWinds attack matter so much for the industry?#

Attackers compromised the build system itself (not any single customer), injecting malicious code into a legitimate, signed update — around 18,000 organizations installed it, trusting it completely. It proved even mature companies can be devastated through their build pipeline, not just their product code.

28. What's the "pwn request" pattern, and how do you prevent it?#

A CI trigger (like GitHub's pull_request_target) that runs with access to real repo secrets, even for a pull request from an untrusted fork. If that workflow also checks out and runs the fork's code, an attacker can exfiltrate secrets. Fix: use the regular pull_request trigger (no secret access) unless you specifically avoid running untrusted code.

29. Why should third-party CI actions be pinned to a commit SHA instead of a version tag?#

A tag like @v2 is mutable — the maintainer (or an attacker who compromises them) could push new code under that same tag later, and your pipeline would silently start running it. A commit SHA can't be moved.

30. What does IaC scanning catch that application-code scanning (SAST) doesn't?#

Misconfigured infrastructure before it's ever provisioned — like a publicly readable S3 bucket or an open security group — one of the most common real-world causes of actual breaches.

31. What is an SBOM, and why does it matter?#

A complete, machine-readable inventory of every component (including every transitive dependency) that went into an artifact — like an ingredients label for software. When a new severe CVE is announced, an SBOM turns "which of our 300 services are affected?" from a days-long manual audit into an instant search.

32. What does artifact signing prove, and why is "keyless" signing an improvement?#

It proves an artifact genuinely came from your trusted build process and wasn't tampered with. Keyless signing (Sigstore) avoids managing a long-lived private key (itself a leak risk) by issuing a short-lived certificate tied to a verified identity instead, recorded in a public transparency log.

33. What is SLSA, and what's it used for?#

A tiered maturity model (Level 1-4) for supply chain integrity — similar in spirit to CVSS for vulnerability severity. Level 1 is "we have a real build script." Level 3-4 means the build platform is hardened against tampering, with signed, verifiable provenance — exactly what would have prevented a SolarWinds-style attack.

---

Part 6 Questions: Compliance

34. Is passing a compliance audit the same as being secure?#

No — compliance is a checkbox exercise proving you follow a defined set of controls; it doesn't guarantee you're actually resistant to real attacks. You can pass an audit with checkbox-driven controls that don't meaningfully reduce risk, and you can be genuinely secure without any certification at all.

35. What's the difference between SOC 2 Type I and Type II?#

Type I checks whether controls are designed correctly at a single point in time (a snapshot). Type II checks whether they actually operated effectively over a sustained period (typically 6-12 months) — much stronger assurance, and what most enterprise customers actually require.

36. How does ISO 27001 differ conceptually from SOC 2?#

SOC 2 is "prove you follow a fixed set of trust criteria." ISO 27001 is "prove you have an ongoing system (an ISMS) for identifying and managing risk," selecting specific controls from a large catalog based on your own risk assessment — more process-and-risk-centric.

37. What's the highest-leverage architectural decision for reducing PCI-DSS scope?#

Never touch raw cardholder data at all — use tokenization via a compliant third-party processor, so card data flows directly from the customer's browser to the processor, and your own systems only ever see a non-sensitive token. This shrinks your compliance scope dramatically.

38. What's GDPR's "right to be forgotten," and why is it a real engineering challenge?#

Users can request their personal data be deleted, and that has to actually propagate across backups, logs, caches, analytics pipelines, and any downstream system that received a copy — not just one database row delete.

39. Why do auditors care about "evidence," not just whether a control exists?#

If your team does the right thing but keeps no record, an auditor has no way to confirm it happened even if it genuinely did — indistinguishable from never having happened at all. Mature teams automate evidence generation as a byproduct of good tooling (version-controlled configs, audit logs) rather than relying on manual record-keeping.

---

Quick-Fire / Rapid Recall#