"What is DevSecOps?" or "how do you integrate security into DevOps?" — the framing question that reveals whether you think about security as a program or a scanner.

What is actually happening (the mental model).

DevSecOps means making security a shared, automated, continuous part of the whole lifecycle rather than a gate at the end owned by a separate team. Shift-left — catch issues where they're cheapest (in the IDE/PR, not production) — but also shift everywhere (build, deploy, runtime). The critical constraint: security must be fast and low-friction or developers route around it. The goal is to make the secure way the easy way.

How to work through it.

1. Embed security across the lifecycle — IDE/pre-commit (secret + SAST), CI (SCA, IaC scan, image scan), deploy (admission/policy), runtime (detection).
2. Automate it — as fast, low-false-positive pipeline stages, not manual reviews.
3. Shared responsibility — developers own security in their code; a small security team builds the paved road and does threat modeling.
4. Enabler not blocker — secure defaults, golden paths; the compliant path is the easy path.

Key controls and trade-offs.

Shift-left saves cost (cheap to fix early) but only works if the tooling is fast and low-noise; noisy tooling gets bypassed. Full automation frees humans for the high-value work (threat modeling) they should do.

The trap that less-experienced engineers fall into.

Treating DevSecOps as "add a scanner to CI," or as a gate that slows delivery — so developers work around it and it becomes theater.

🎯 Interviewer follow-up questions you should expect.

• "What is DevSecOps?" Security shared, automated, and continuous across the lifecycle; shift-left and shift-everywhere; an enabler not a gate.
• "How do you avoid slowing developers down?" Fast, low-false-positive, and automated in their flow; secure defaults/golden paths.
• "Whose job is security?" Everyone's — devs own their code's security; a small team builds the paved road and does threat modeling.

"How do you secure your CI/CD pipeline?" — increasingly probed after high-profile pipeline compromises, because the pipeline has broad access and is a prime target.

What is actually happening (the mental model).

The CI/CD pipeline is a high-value attack target — it has credentials to deploy to production, access to source and secrets, and runs a lot of third-party code. A compromised pipeline is a compromised everything. So you secure it as critical infrastructure: least-privilege pipeline identity, no long-lived credentials (OIDC), isolated ephemeral runners, protection from untrusted code, and supply-chain controls.

How to work through it.

1. No long-lived credentials — OIDC federation for cloud access (short-lived, scoped); no static keys in the CI system.
2. Least-privilege pipeline identity — the deploy role can do exactly what's needed, nothing more (a compromised pipeline shouldn't own the account).
3. Ephemeral, isolated runners — single-use, destroyed after each job; never run untrusted PR code on privileged runners.
4. Protect secrets — scoped to protected branches/environments, masked, not exposed to fork PRs.
5. Supply chain — pin third-party actions by SHA (not a movable tag), verify what you pull (scenario 4).
6. Branch protection + signed commits + required reviews so malicious code can't be injected.

Key controls and trade-offs.

The pipeline's power (deploy access) is exactly why it's a target — you cap the blast radius with least privilege and remove static credentials with OIDC. Ephemeral runners cost a little startup time for isolation.

The trap that less-experienced engineers fall into.

Static cloud keys in the CI system (a prime exfiltration target), over-privileged deploy roles (a compromised pipeline owns everything), and running untrusted PR code on privileged self-hosted runners.

🎯 Interviewer follow-up questions you should expect.

• "Why is the pipeline a high-value target?" It has production deploy access, source, and secrets — compromise it and you compromise everything.
• "How do you avoid credentials in CI?" OIDC federation for short-lived scoped cloud access.
• "Why pin actions by SHA?" A movable tag can be re-pointed at malicious code.

"What security testing do you run and where?" — testing whether you know the tools and where each fits in the pipeline.

What is actually happening (the mental model).

Each testing type finds a different class of vulnerability at a different stage, and you layer them (defense in depth). SAST analyses source code statically (early, in CI); DAST tests the running app from outside (later, in staging); SCA scans dependencies for known CVEs (the biggest real-world source of vulns); IAST instruments the running app to combine both. You place each where it's cheapest and most effective.

How to work through it.

1. SAST (static analysis) — scans source for code vulns (injection, hardcoded secrets) early, in the PR/CI. Fast, but false positives.
2. SCA (software composition analysis) — scans dependencies for known CVEs + license issues. Critical, because most vulns come from third-party code (Log4Shell etc.).
3. DAST (dynamic analysis) — tests the running app from the outside (in staging) for runtime vulns (auth, XSS). No false positives on exploitability, but late and slower.
4. IAST — instruments the running app to combine static + dynamic; fewer false positives.
5. Plus: secret scanning, container image scanning, IaC scanning (scenarios 8, 10) — a full layered picture.

Key controls and trade-offs.

SAST: early + broad, but noisy (false positives). DAST: real exploitability, but late and can't cover all code paths. SCA: highest ROI (dependencies are the #1 vuln source). Layer them — no single type covers everything.

The trap that less-experienced engineers fall into.

Relying on one type (e.g. only SAST), and not running SCA — missing that most real-world vulnerabilities come from vulnerable dependencies.

🎯 Interviewer follow-up questions you should expect.

• "SAST vs DAST vs SCA?" SAST scans source statically (early), DAST tests the running app (later), and SCA scans dependencies for known CVEs.
• "Which finds the most real vulns?" SCA — most vulnerabilities come from third-party dependencies.
• "Where does each run?" SAST/SCA in CI/PR, DAST against a running staging environment.

"How do you secure your software supply chain?" — post-SolarWinds/Log4Shell, a first-class senior concern.

What is actually happening (the mental model).

Your software is mostly other people's code (dependencies, base images, build tools, CI actions), so your attack surface includes everything you pull in. Supply-chain security is about knowing what's in your software (SBOM), verifying its integrity and provenance (signing, SLSA), and controlling what you consume (pinning, trusted registries) — so a compromised dependency or a malicious package can't silently enter your build.

How to work through it.

1. SBOM (Software Bill of Materials) — know exactly what's in every artifact, so when the next Log4Shell drops you can answer "are we affected?" in minutes.
2. Provenance & signing — sign artifacts (cosign), generate SLSA provenance (what was built, how, from what source), and verify signatures at deploy/admission so only trusted artifacts run.
3. Pin dependencies/actions/base images by digest — a movable tag can be hijacked.
4. Control consumption — trusted internal registry / pull-through cache, dependency scanning (SCA), and watch for dependency confusion / typosquatting (a malicious public package shadowing an internal one).
5. Least-privilege build — a compromised dependency shouldn't have broad access.

Key controls and trade-offs.

SBOM + signing + pinning add process but close the exact vectors of recent major attacks. Verifying provenance at admission is the strongest control (only trusted artifacts run) but requires the signing infrastructure.

The trap that less-experienced engineers fall into.

No SBOM (can't answer "are we affected by CVE-X?"), trusting movable tags (hijackable), and dependency confusion (an internal package name resolvable from a public registry).

🎯 Interviewer follow-up questions you should expect.

• "A new critical CVE drops in a common library — how fast can you tell if you're affected?" Minutes, via SBOMs — that's what they're for.
• "How do you ensure only trusted artifacts run?" Sign with cosign, generate SLSA provenance, and verify signatures at admission.
• "What's dependency confusion?" A malicious public package shadowing an internal one; use a trusted registry and namespace protection.

"How do you manage secrets across the org?" — a foundational DevSecOps question.

What is actually happening (the mental model).

The best secret is one that doesn't exist — prefer short-lived, dynamically-issued credentials (workload identity / OIDC) over static secrets wherever possible. Where secrets must exist, they live in a dedicated secrets manager (Vault / cloud secrets manager) as the single source of truth, with rotation, audit, tight access control, and dynamic secrets — never hardcoded, never in git, never in plaintext env/config.

How to work through it.

1. Eliminate secrets where possible — OIDC/workload identity (IRSA on EKS) for short-lived, auto-expiring credentials; no static key to steal.
2. Central secrets manager — Vault / AWS Secrets Manager / SSM as the single source of truth; apps fetch at runtime.
3. Dynamic secrets — Vault can generate short-lived, per-use DB credentials that auto-expire (huge blast-radius reduction).
4. Rotation + audit + least privilege — rotate regularly, log every access, scope who/what can read each secret.
5. Never in git / plaintext — secret scanning (gitleaks) in pre-commit + CI; encrypt at rest.

Key controls and trade-offs.

Workload identity removes the static secret entirely (strongest) at the cost of setup. A central secrets manager adds a runtime dependency but gives rotation/audit/dynamic secrets. Dynamic short-lived secrets are the gold standard but need the tooling.

The trap that less-experienced engineers fall into.

Static long-lived secrets everywhere (leak risk), secrets in env vars/config/git, and no rotation — so a leaked secret stays valid indefinitely.

🎯 Interviewer follow-up questions you should expect.

• "How do you manage secrets at scale?" Eliminate where possible (workload identity/OIDC), central secrets manager for the rest, dynamic short-lived secrets, rotation, and audit.
• "What are dynamic secrets?" Short-lived, per-use credentials (e.g. Vault-generated DB creds) that auto-expire, and shrinking blast radius.
• "How do you keep secrets out of git?" Secret scanning in pre-commit and CI; secrets live in the manager, not the repo.

A secret was leaked (public repo, log, Slack) — or "secrets are scattered everywhere and we don't know where." An incident + a systemic problem.

What is actually happening (the mental model).

For a leak: rotate first, investigate second — a leaked secret is compromised the moment it's exposed; scrubbing it is secondary. For sprawl: the root cause is no central management + no scanning, and the fix is consolidating to a secrets manager and adding detection so it can't recur silently.

How to work through it.

1. Rotate/revoke immediately — invalidate the leaked value before anything else.
2. Investigate blast radius — what did the secret access? check logs (CloudTrail) for whether it was used; remediate anything done with it.
3. Scrub — remove from git history (filter-repo), but know that's damage-reduction, not a cure.
4. Prevent — secret scanning (gitleaks) in pre-commit + CI + platform push-protection; move to a secrets manager; move to workload identity so there's no static secret next time.

Key controls and trade-offs.

Consolidating to a central manager + scanning is the fix; the trade-off is migration effort. Detection (scanning everywhere secrets might land) catches future leaks fast.

The trap that less-experienced engineers fall into.

Scrubbing the secret from git and thinking they're safe (it's already leaked — must rotate), and not asking "what did it access?" (missing the actual damage).

🎯 Interviewer follow-up questions you should expect.

• "A key leaked to a public repo — first move?" Rotate it immediately; a leaked secret is compromised. Then investigate blast radius via logs.
• "Why isn't scrubbing history enough?" It was already exposed/scraped; rotation is the only real fix.
• "How do you prevent secret sprawl?" A central secrets manager, secret scanning everywhere, and workload identity to reduce secrets that exist.

"Explain zero trust" or "how do services authenticate to each other?" — the modern security-architecture question.

What is actually happening (the mental model).

Zero trust means never trust, always verify — you don't trust the network (being "inside the perimeter" grants nothing); every request is authenticated and authorized on its own. The old model was a hard perimeter with a soft, trusted interior — one breach and the attacker moves freely (lateral movement). Zero trust eliminates implicit trust: strong identity for every actor (human and workload), least privilege, micro-segmentation, and encryption/mTLS everywhere, so a compromised component can't freely reach everything.

How to work through it.

1. No implicit network trust — being inside the network grants nothing; every request is verified.
2. Strong workload identity — services get cryptographic identities (SPIFFE/SPIRE, mTLS via a service mesh) and authenticate to each other, not "trust because same VPC."
3. Least privilege + micro-segmentation — default-deny networking (NetworkPolicies), fine-grained authz, so lateral movement is contained.
4. Encryption everywhere — mTLS between services; assume the network is hostile.
5. Continuous verification — short-lived credentials, re-auth, device/context checks.

Key controls and trade-offs.

Zero trust dramatically limits lateral movement (contains a breach) at the cost of complexity (identity for everything, mTLS, segmentation). A service mesh provides mTLS + identity but adds operational overhead.

The trap that less-experienced engineers fall into.

Trusting the network ("it's inside the VPC, so it's safe") — flat trusted networks are exactly what lets one breach become total compromise via lateral movement.

🎯 Interviewer follow-up questions you should expect.

• "What is zero trust?" Never trust, always verify; no implicit network trust; strong identity, least privilege, micro-segmentation, and encryption everywhere.
• "How do services authenticate in zero trust?" Cryptographic workload identity and mTLS (service mesh / SPIFFE), not network location.
• "Why does it matter?" It contains lateral movement — a breach of one component can't freely reach everything.

"How do you secure containers?" — spanning build-time (image) and runtime.

What is actually happening (the mental model).

Container security is layered across the image and the runtime: build minimal, non-root, scanned, signed images (fewer packages = fewer CVEs, root-in-container ≈ root-on-host), and run them with least privilege (drop capabilities, read-only FS, no privileged) plus admission control so only trusted images run. Every layer shrinks the blast radius of a compromise.

How to work through it.

1. Minimal base (distroless/alpine) + multi-stage build — fewer packages, smaller attack surface.
2. Scan images (Trivy/Grype) in CI, block on criticals; rebuild regularly (images rot — base CVEs accumulate).
3. Non-root + drop capabilities + read-only root FS + no --privileged — a container escape as root is root on the host.
4. Sign images (cosign) + admission control so only signed/scanned images run.
5. Pin base images by digest; SBOM per image.
6. Runtime — detection (scenario 12), seccomp/AppArmor.

Key controls and trade-offs.

Distroless is smallest/most secure but has no shell (debug via ephemeral containers). Signing + admission is the strongest control but needs the infra. Layered controls, each reducing blast radius.

The trap that less-experienced engineers fall into.

Root containers with full capabilities and a writable FS (a container escape = host root), never rebuilding images (accumulating base CVEs), and scanning once but not enforcing (no admission control).

🎯 Interviewer follow-up questions you should expect.

• "How do you secure a container image?" Minimal non-root base, scan, block on criticals, rebuild regularly, sign, admission-verify, and pin by digest.
• "Why is a root container dangerous?" A container escape as root is root on the host.
• "An image hasn't changed but has new CVEs — why?" Base-image rot; rebuild on a cadence to pick up patches.

"How do you secure a Kubernetes cluster?" — a dense topic; the interviewer wants a layered, blast-radius-aware answer.

What is actually happening (the mental model).

Kubernetes security is defense in depth across identity, workload, network, and supply chain — because the default posture is permissive (flat pod networking, broad service accounts). You harden each layer so a single compromised pod can't reach everything: least-privilege RBAC, Pod Security admission (no privileged/root/host mounts), default-deny NetworkPolicies, image admission (only signed), plus secrets encryption and runtime detection.

How to work through it.

1. RBAC least privilege — scoped roles, dedicated ServiceAccounts per workload (never cluster-admin sprawl; disable SA token automount where unused).
2. Pod Security Standards / admission — block privileged, host namespaces, host-path, root containers; roll out with audit/warn first.
3. NetworkPolicies default-deny — flat pod networking is a lateral-movement risk; allow only what's needed (including DNS).
4. Admission control (OPA/Kyverno) — only signed/trusted images, mandatory limits/labels, no :latest.
5. Secrets — encrypt etcd at rest (K8s Secrets are base64, not encrypted), external secret stores.
6. Runtime detection (Falco), audit logging, and node hardening.

Key controls and trade-offs.

Default K8s is permissive; each control tightens it. Default-deny networking is high-value but needs careful allow-listing (forgetting DNS breaks the cluster). Admission control adds gates but enforces org-wide policy.

The trap that less-experienced engineers fall into.

Broad RBAC (cluster-admin handed out), flat pod networking (lateral movement), assuming K8s Secrets are encrypted (they're base64), and privileged containers.

🎯 Interviewer follow-up questions you should expect.

• "How do you harden a cluster?" Least-privilege RBAC, Pod Security admission, default-deny NetworkPolicies, image admission, secrets encryption, and runtime detection.
• "Are K8s Secrets encrypted?" No, base64; enable etcd KMS encryption, tight RBAC, or an external secret store.
• "Why default-deny networking?" Flat pod networking lets a compromised pod move laterally to everything.

"How do you secure your IaC / prevent insecure infrastructure?" — shifting security left to the infrastructure definition.

What is actually happening (the mental model).

IaC lets you catch insecure infrastructure before it's provisioned — a public S3 bucket, an open security group, an unencrypted volume become a failed PR check, not a production breach found in an audit. You scan IaC in CI (tfsec/checkov/Terrascan), enforce guardrails with policy-as-code (OPA/Sentinel), and prevent drift (manual console changes that bypass the reviewed IaC).

How to work through it.

1. Scan IaC in CI — tfsec/checkov/Terrascan block insecure config (public buckets, 0.0.0.0/0 security groups, unencrypted volumes, missing logging) in the PR.
2. Policy-as-code guardrails — OPA/Sentinel enforce org rules (no public resources, mandatory encryption/tags) as a merge gate.
3. Secure-by-default modules — reusable modules with encryption, logging, least-privilege baked in, so the easy path is secure.
4. Prevent drift — restrict console write access so infra is only changed through reviewed IaC; scheduled drift detection.
5. Least-privilege IaC pipeline identity (ties to scenario 2).

Key controls and trade-offs.

Scanning + policy-as-code shift infra security left (cheap, pre-provision) at the cost of authoring policies. Secure-by-default modules make it effortless for consumers.

The trap that less-experienced engineers fall into.

No IaC scanning (insecure config reaches prod, found later in an audit), and allowing manual console changes that bypass the reviewed, scanned IaC (drift reintroduces insecurity).

🎯 Interviewer follow-up questions you should expect.

• "How do you stop insecure infra being provisioned?" IaC scanning (tfsec/checkov), policy-as-code (OPA/Sentinel) as merge gates; secure-by-default modules.
• "How do you prevent drift undermining this?" Restrict console writes so changes go through reviewed IaC; scheduled drift detection.

"How do you find and fix cloud misconfigurations across accounts?" — the continuous-posture question.

What is actually happening (the mental model).

At scale, insecure cloud config (public buckets, over-permissive IAM, unencrypted resources, disabled logging) accumulates and can't be caught by review alone — you need continuous scanning of the live environment (CSPM) plus preventive guardrails so misconfig can't happen. It's the runtime counterpart to IaC scanning: IaC scanning catches it pre-provision; CSPM catches drift and manually-created resources.

How to work through it.

1. Continuous posture scanning — Security Hub / Config / Prowler / a CSPM tool continuously check the live environment against benchmarks (CIS) for misconfig.
2. Preventive guardrails — SCPs at the org level (block public buckets, disabling CloudTrail, unapproved regions) so misconfig is prevented, not just detected.
3. Threat detection — GuardDuty for anomalous activity (crypto-mining, credential misuse).
4. Prioritise & remediate — by risk (public + sensitive data first); auto-remediate the clear-cut ones.
5. Centralised — aggregate findings across accounts (Organizations) into one view.

Key controls and trade-offs.

CSPM detects (catches everything including drift/manual changes) but is reactive; SCP guardrails prevent but only cover what you've codified. Use both — prevent what you can, detect the rest.

The trap that less-experienced engineers fall into.

Relying only on IaC scanning (misses manually-created resources and drift) or only on detection (reactive; misconfig exists until found) instead of combining preventive guardrails + continuous detection.

🎯 Interviewer follow-up questions you should expect.

• "How do you catch cloud misconfig across many accounts?" Continuous CSPM scanning (Security Hub/Config/Prowler), SCP guardrails to prevent, and centralised across the org.
• "CSPM vs IaC scanning?" IaC scanning is pre-provision; CSPM catches drift and manually-created resources in the live environment.
• "How do you prevent, not just detect?" SCPs enforcing guardrails org-wide (no public buckets, no disabling CloudTrail).

"How do you detect an attack in progress / a compromised container?" — the detection-and-response side, because prevention isn't enough (assume breach).

What is actually happening (the mental model).

You can't prevent everything, so you must detect — runtime security watches actual behavior for signs of compromise (a container spawning a shell, unexpected network connections, privilege escalation, crypto-mining) and alerts/responds. In Kubernetes/containers, tools like Falco watch syscalls against rules; at the cloud level, GuardDuty watches for anomalous API activity. Detection + fast response limits the damage of a breach that got past prevention.

How to work through it.

1. Runtime behavioral detection — Falco (syscall-level rules: unexpected shell in a container, writes to sensitive paths, outbound to a mining pool), or an EDR/CWPP.
2. Cloud anomaly detection — GuardDuty (unusual API calls, credential misuse, reconnaissance).
3. Baseline + anomaly — know normal behavior; alert on deviation.
4. Automated response — isolate/kill a compromised pod, revoke credentials, quarantine — fast, to limit damage.
5. Feed a SIEM (scenario 15) for correlation and investigation.

Key controls and trade-offs.

Runtime detection catches what prevention missed (assume-breach) but generates alerts (tuning needed to avoid fatigue). Automated response is fast but risks false-positive disruption — balance.

The trap that less-experienced engineers fall into.

Relying only on prevention (no detection, so a breach that gets past controls goes unnoticed), and no response plan (detecting but not acting fast).

🎯 Interviewer follow-up questions you should expect.

• "How do you detect a compromised container at runtime?" Behavioral detection like Falco on syscalls (unexpected shell, odd network, privilege escalation); GuardDuty for cloud anomalies.
• "Why runtime detection if you have prevention?" You assume breach — prevention isn't perfect; detection, fast response limits damage.

"You have 5,000 vulnerabilities across your estate — what do you do?" — the realistic, overwhelming-backlog question.

What is actually happening (the mental model).

You can't fix everything, so you prioritise by actual risk, not raw CVSS score. A "critical" CVE in a component that isn't exploitable in your context (not internet-facing, no reachable code path, compensating controls) is lower priority than a "medium" that's actively exploited on an internet-facing service. You prioritise by exploitability + exposure + reachability + business context, use signals like EPSS (exploit probability) and KEV (known-exploited), and drive down the risk that matters rather than chasing the number.

How to work through it.

1. Prioritise by real risk, not raw severity — combine CVSS with exploitability (EPSS), known-exploited (CISA KEV), exposure (internet-facing?), and reachability (is the vulnerable code path actually used?).
2. Business context — sensitive data / critical service raises priority.
3. Compensating controls — a WAF/segmentation may lower effective risk.
4. Automate the pipeline — continuous scanning, auto-triage, SLAs by risk tier, auto-PRs for dependency bumps (Dependabot/Renovate).
5. Reduce at the source — minimal images + fewer dependencies = fewer vulns to manage.

Key controls and trade-offs.

Risk-based prioritisation focuses effort where it matters (vs drowning in CVSS-criticals that aren't exploitable). It requires context (reachability, exposure) that raw scanners don't give — reachability analysis and EPSS/KEV add that.

The trap that less-experienced engineers fall into.

Chasing raw CVSS scores (fixing un-exploitable "criticals" while an actively-exploited "medium" on an internet-facing service sits), and no SLAs/automation (the backlog grows forever).

🎯 Interviewer follow-up questions you should expect.

• "You have thousands of vulns — how do you prioritise?" By real risk: exploitability (EPSS), known-exploited (KEV), exposure, reachability, and business context — not raw CVSS.
• "A critical CVSS but not internet-facing and the code path isn't used — priority?" Lower than an exploited medium on an exposed service; context matters.
• "How do you keep the backlog from growing?" You automate scanning, auto-PRs (Renovate), SLAs by risk tier, and reduce dependencies at the source.

A severe, actively-exploited CVE drops in a widely-used library (Log4Shell, Heartbleed). "It's Friday night — what do you do?"

What is actually happening (the mental model).

This is a time-critical incident, and the first question is "are we affected, and where?" — which is fast if you have SBOMs and slow (panic) if you don't. You assess exposure, mitigate immediately (a WAF rule / config flag can buy time before you can patch everywhere), then patch systematically, and hunt for signs you were already exploited. It's a fire drill that rewards preparation (SBOM, fast patch pipeline).

How to work through it.

1. Determine exposure fast — query SBOMs / SCA across the estate: which services use the vulnerable version, and are they internet-facing? (SBOMs turn this from days into minutes.)
2. Mitigate immediately — a fast compensating control (WAF rule to block the exploit pattern, disable the vulnerable feature/flag) buys time before a full patch.
3. Patch systematically — prioritise internet-facing first; use the fast deploy pipeline; auto-PR the dependency bump across repos.
4. Hunt for prior exploitation — check logs/IDS for indicators; assume you may have already been hit.
5. Communicate — status to stakeholders; coordinate.

Key controls and trade-offs.

Preparation is everything: SBOMs for instant exposure assessment, a fast patch/deploy pipeline, and a WAF for a quick mitigation. Without them it's a chaotic multi-day scramble.

The trap that less-experienced engineers fall into.

No SBOM (can't quickly answer "are we affected", so days of manual hunting), patching without a quick mitigation first (exposed the whole time), and not checking whether they were already exploited.

🎯 Interviewer follow-up questions you should expect.

• "A Log4Shell-class CVE drops — what first?" Determine exposure fast via SBOMs/SCA, then a quick mitigation (WAF rule) to buy time, and then patch internet-facing first.
• "How do you know if you're affected in minutes?" SBOMs — that's exactly what they're for.
• "How do you buy time before patching everywhere?" A WAF rule or disabling the vulnerable feature as a compensating control.

"How do you detect and respond to a security incident?" — the SIEM + IR process question.

What is actually happening (the mental model).

Security IR is like operational IR but with a twist: you must preserve evidence, assume the attacker is active, and contain before eradicating. You centralise security-relevant logs into a SIEM for correlation and detection, have defined detections and playbooks, and follow a structured process: detect → contain → eradicate → recover → learn (a blameless post-incident review). Speed matters (limit dwell time), but so does not tipping off or losing the attacker.

How to work through it.

1. Centralised security logging (SIEM) — aggregate CloudTrail, VPC flow logs, app/auth logs, GuardDuty/Falco findings; correlate for detections.
2. Detections + playbooks — defined rules for known attack patterns; runbooks per incident type.
3. IR process — detect → contain (isolate, revoke creds — stop the bleeding) → eradicate (remove the foothold) → recover → learn (blameless review).
4. Preserve evidence — snapshot/forensics before you wipe; assume the attacker is active.
5. Reduce dwell time — fast detection + response; measure MTTD/MTTR.

Key controls and trade-offs.

A SIEM gives correlation/detection at a cost (volume, tuning, false positives). Contain-first limits damage but you must preserve evidence for eradication and to ensure you got the whole foothold.

The trap that less-experienced engineers fall into.

No centralised security logging (can't detect or investigate), eradicating before preserving evidence (lose forensics, may miss the attacker's other footholds), and treating a security incident like a normal ops one (missing the adversarial dimension).

🎯 Interviewer follow-up questions you should expect.

• "How do you detect a security incident?" Centralised logging in a SIEM with correlation/detections, plus runtime and cloud anomaly detection.
• "IR process?" You detect → contain → eradicate → recover → learn; preserve evidence; assume the attacker is active.
• "Contain or investigate first?" You contain to stop the bleeding, but preserve evidence so you can fully eradicate the foothold.

"How do you build security into a design?" or "walk me through threat modeling a system" — the proactive, design-time security skill.

What is actually happening (the mental model).

Threat modeling is thinking like an attacker at design time — systematically asking "how could this be attacked?" before it's built, when fixing is cheapest. A common framework is STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege). You map the system (data flows, trust boundaries), enumerate threats per component, and decide mitigations — building security in rather than bolting it on.

How to work through it.

1. Map the system — components, data flows, and trust boundaries (where data crosses from less-trusted to more-trusted).
2. Enumerate threats — walk STRIDE per component/flow: what can be spoofed, tampered, disclosed, denied, escalated?
3. Prioritise by risk (likelihood × impact) and decide mitigations — authn/authz, encryption, validation, rate limiting, least privilege.
4. Focus on trust boundaries — that's where most vulnerabilities live (inputs, external integrations, privilege transitions).
5. Do it early and iteratively — at design, and revisit on major changes.

Key controls and trade-offs.

Threat modeling is cheap prevention (design-time) that avoids expensive production vulnerabilities. It's a human activity (can't fully automate) — the value is the structured "think like an attacker" discipline, especially at trust boundaries.

The trap that less-experienced engineers fall into.

Skipping threat modeling and bolting security on later (expensive, incomplete), and analysing everything equally instead of focusing on trust boundaries where the real risk is.

🎯 Interviewer follow-up questions you should expect.

• "How do you threat model?" Map the system and trust boundaries, walk STRIDE per component, prioritise by risk, decide mitigations — at design time.
• "What's STRIDE?" Spoofing, Tampering, Repudiation, Information disclosure, DoS, and Elevation of privilege.
• "Where do most vulns live?" At trust boundaries — inputs, external integrations, privilege transitions.

"How do you handle SOC2 / PCI / HIPAA without it killing velocity?" — the regulated-environment question.

What is actually happening (the mental model).

Manual compliance is slow, error-prone, and hated. Compliance as code turns controls into automated, continuously-verified policy and generates audit evidence automatically — so compliance is a byproduct of how you work, not a separate paperwork exercise. You codify controls (policy-as-code), continuously check the environment against them, and make the compliant path the easy path so people don't route around it. An audit becomes a query, not a fire drill.

How to work through it.

1. Controls as code — encode requirements as policy-as-code (OPA/Sentinel/Config rules): encryption required, logging enabled, access restricted, etc.
2. Continuous compliance — scan the environment continuously against the controls (CSPM, Config); flag/auto-remediate drift.
3. Automated audit evidence — generate the evidence auditors need (who deployed what, control status over time) automatically.
4. Make the compliant path the easy path — secure-by-default modules, guardrails baked into the pipeline, so compliance is automatic.
5. Segregation of duties enforced by the pipeline (author ≠ approver for prod).

Key controls and trade-offs.

Compliance-as-code is upfront investment that pays off in continuous assurance + painless audits. The alternative (manual, point-in-time) is slower, error-prone, and only proves compliance at audit time, not continuously.

The trap that less-experienced engineers fall into.

Treating compliance as manual paperwork (slow, and only true at audit time), and bolting heavyweight approval processes onto delivery (people route around them).

🎯 Interviewer follow-up questions you should expect.

• "How do you do SOC2/PCI without killing velocity?" Compliance as code — controls as policy-as-code, continuously verified, evidence generated automatically; make the compliant path the easy path.
• "How does an audit go with this?" It's a query — evidence is generated continuously, not scrambled for at audit time.

"How do you make security part of the engineering culture?" — the people side, and a senior/staff differentiator.

What is actually happening (the mental model).

Security fails when it's a gatekeeping silo that says no — developers route around it, and it becomes adversarial. It succeeds when it's shared, enabling, and blameless: a small security team builds paved roads and tooling, security champions embedded in dev teams spread ownership, and incidents are treated as blameless learning, not blame. You make security easy and rewarding rather than a tax. The goal is security as an enabler that engineers want to engage with.

How to work through it.

1. Security as an enabler, not a blocker — build paved roads and secure defaults so the easy path is secure; don't just say no.
2. Security champions — embed a security-minded engineer in each team to spread ownership and be the local go-to (scales a small security team).
3. Blameless security — a reported vulnerability or mistake is a learning opportunity, not a punishment (or people hide issues).
4. Make it visible and rewarding — training that's practical, recognise good security work, gamify (capture-the-flag).
5. Shared responsibility — developers own their code's security; security team enables.

Key controls and trade-offs.

A collaborative, enabling security culture scales far better than a gatekeeping team (which becomes a bottleneck people route around). It requires the security team to shift from "no" to "here's the easy secure way" — a mindset change.

The trap that less-experienced engineers fall into.

Security as a gatekeeper that only says no (adversarial, routed around), and a blame culture (people hide vulnerabilities/mistakes instead of surfacing them).

🎯 Interviewer follow-up questions you should expect.

• "How do you build a security culture?" Security as an enabler with paved roads, security champions embedded in teams, blameless learning, and shared responsibility.
• "What are security champions?" Security-minded engineers embedded in dev teams who spread ownership and scale a small security team.
• "Why blameless for security?" Blame makes people hide vulnerabilities; blameless surfaces them so they get fixed.

"How do you protect a public-facing service from attacks?" — the perimeter/edge question.

What is actually happening (the mental model).

A public endpoint faces a hostile internet — application attacks (injection, XSS), volumetric attacks (DDoS), and abusive bots (credential stuffing, scraping). You defend at the edge, before traffic reaches your origin: a WAF filters malicious application-layer requests, DDoS protection absorbs volumetric floods (a CDN/scrubbing layer), and bot/rate-limiting controls abuse. Edge defense keeps attacks away from your origin and adds a fast compensating-control layer (a WAF rule can mitigate a fresh CVE — ties to scenario 14).

How to work through it.

1. WAF — filters application-layer attacks (OWASP Top 10: injection, XSS) before they hit the origin; managed rule sets + custom rules.
2. DDoS protection — a CDN / scrubbing layer (CloudFront + Shield, Cloudflare) absorbs volumetric floods; the origin is shielded and not directly reachable.
3. Rate limiting & bot mitigation — throttle abusive clients, block credential stuffing/scraping, CAPTCHA/bot-detection.
4. TLS + secure headers at the edge.
5. WAF as a fast mitigation — a WAF rule can block a fresh exploit pattern (Log4Shell) while you patch.

Key controls and trade-offs.

Edge defense stops attacks before the origin (efficient, scalable) but a WAF can have false positives (blocking legit traffic) — tune it, run in detection mode first. DDoS protection is essential for public services but adds cost.

The trap that less-experienced engineers fall into.

Exposing the origin directly (no edge protection, so attacks hit the app), and no rate limiting (credential stuffing/scraping/abuse), and treating a WAF as set-and-forget (false positives block real users).

🎯 Interviewer follow-up questions you should expect.

• "How do you protect a public service?" Edge defense: WAF for app-layer attacks, DDoS protection/CDN for volumetric, rate limiting, bot mitigation, origin not directly reachable.
• "How can a WAF help with a fresh CVE?" A WAF rule can block the exploit pattern as a fast compensating control while you patch.
• "WAF trade-off?" False positives blocking legit traffic — tune it, run in detection mode first.