Interview prep

Sixty-three technical questions with model answers, spread across the thirteen domains this course teaches, plus open-ended scenario questions, behavioural questions you can slot your own experience into, questions worth asking the interviewer, and a realistic plan for the last week. Every answer is written the way you'd actually want to say it out loud — a clear opening claim, the mechanism underneath it, and the honest caveat — and every one links back to the lesson that covers it properly, because an interview answer you can't extend under a follow-up question isn't an answer, it's a recital.

How a DevSecOps interview is usually shaped

☺ Like you're 10: Interviews usually come in a few rounds, and each round is checking something different — can you talk about it, can you actually do it, would you make good calls under pressure, and are you someone people can work with.

Loops vary by company size and by whether the role sits in a central security team or embedded in platform engineering, but the same four shapes recur, and knowing which one you're in changes how you should answer. Answering a screen with a forty-five-minute architecture monologue reads as poor judgement; answering a deep-dive with a one-line definition reads as thin.

Two cross-cutting things get assessed in every stage regardless of its nominal topic. The first is calibration: whether you can distinguish "this is a real, exploitable finding" from "this is a scanner being noisy," because a candidate who treats every Critical as an emergency is as expensive to employ as one who treats none of them as one — that's the whole subject of DevSecOps anti-patterns. The second is honesty about scope: saying "I've run Trivy and Checkov in anger, I've read about SLSA but never implemented above L1" is a far better answer than a vague claim that collapses on the second follow-up. Interviewers rarely penalise a clean "I haven't done that — here's what I understand about it and how I'd approach learning it." They reliably penalise a bluff.

The topic map: what gets probed, and where it's covered

☺ Like you're 10: Here's every topic on the list, how hard people usually dig into each one, and which lesson to re-read if you're shaky.

The "how deeply probed" column below is this course's judgement, based on how central each topic is to the day-to-day work of the role and how often it shows up in published role descriptions — not a measured weighting from any employer's real syllabus. Read it as a study-order hint, not as a prediction. If your target role is cloud-heavy, cloud posture and IaC move up; if it's a product-security role at a software vendor, threat modeling and secure SDLC move up.

Domain 1 — What DevSecOps actually is

☺ Like you're 10: The opening question. It sounds easy, and that's the trap — a fuzzy answer here makes everything you say afterwards sound fuzzy too.

Four questions, all near the top of a loop. None of them is hard; all of them are load-bearing, because this is where the interviewer forms their first estimate of whether you think about security as a discipline or as a set of tools you've been asked to install. Covered in What is DevSecOps?.

🟢 1.1 Define DevSecOps

Q: How would you define DevSecOps to someone who already knows DevOps well?

A: DevSecOps is the practice of making security a continuous, automated, and shared responsibility across the whole software delivery lifecycle, instead of a distinct phase a separate team owns near the end. It isn't a new team, a new tool category, or a rebrand — it's DevOps' own culture and automation applied specifically to security. The cleanest way to show that to someone who knows DevOps is to run security through CALMS, the framing DevOps already uses: Culture, security is a value the whole team owns rather than one team's turf; Automation, checks run on every commit rather than in a scheduled review meeting; Lean, small fast feedback loops instead of one giant end-of-cycle audit; Measurement, vulnerability density, mean-time-to-remediate, and scan coverage tracked sprint over sprint the same way deploy frequency and lead time already are; and Sharing, one backlog and one dashboard rather than three.

The thing that makes that concrete rather than aspirational is that the checks are executable. A policy that lives in a wiki depends on a reviewer remembering it; the same policy as a merge-blocking status check runs identically on every commit whether or not anyone is paying attention.

What they're really checking: whether you lead with a definition or with a tool list. "We use Snyk and Checkov" is an answer to a different question. A senior candidate defines the practice first, then names tools as instances of it.

🟢 1.2 Shift left

Q: What does "shift left" mean, and is there anything about it you'd push back on?

A: Shift left means moving security activities as early into the lifecycle as possible, because that's where a fix is cheapest — threat modeling during design rather than after the fact, static analysis at code review rather than at release, dependency and infrastructure-as-code scanning at build time rather than discovered in production. The further a defect travels before someone finds it, the more code, deployment, and investigation surround it by the time anyone fixes it.

The pushback I'd offer is on the reading of the word "only." Shift-left is an also, not an only. Design-time and code-time checks structurally cannot see a misconfigured resource created by a runtime change, a credential leaked into a log stream next Tuesday, or a fresh exploit against a dependency that was genuinely clean when it shipped. A pipeline that shifts every check left and then stops watching production has traded one blind spot for another — which is why incident response and runtime monitoring still sit on the timeline.

🟡 1.3 Security as code

Q: Give me a concrete example of "security as code," and tell me what it buys you over a careful human reviewer.

A: A concrete example: an Open Policy Agent rule, written in Rego, evaluated against a Terraform plan in CI, that denies any plan opening a security group to 0.0.0.0/0. Others in the same family — Checkov or tfsec scanning infrastructure-as-code before terraform apply is allowed to run, a SAST or SCA tool wired in as a required merge-blocking status check, a secrets scanner running pre-commit and again in the pipeline.

What it buys you over a human reviewer is three things, and only one of them is speed. A person reading diffs can review a handful of pull requests a day; a policy check runs on every commit in seconds. But the more important two are consistency — the rule doesn't depend on which reviewer happened to be paying attention that day, or on how late in the sprint it is — and auditability: the rule is a file in git, so a change to the rule itself is a reviewable, timestamped diff rather than a change in one person's judgement. That last property is what makes the same control double as compliance evidence, which is the bridge to compliance & governance.

The honest limit: policy as code enforces rules you already knew you wanted. It doesn't find the design flaw nobody thought to write a rule about — that's still threat modeling and human review.

🔴 1.4 Selling it to a sceptical org

Q: You join a team that ships fast and thinks security is process overhead. How do you get DevSecOps adopted without becoming the person everyone routes around?

A: I'd start from the assumption that the scepticism is rational rather than ignorant. If every previous interaction with security has meant a delayed release and a rejected pull request with no alternative offered, then treating security as a cost to route around is the correct response to the incentives they've been given. So the first move isn't to add a gate — it's to remove friction the team already feels, and attach the security benefit to that.

Concretely, in rough order: (1) Measure before enforcing. Run the scanners in report-only mode for a few weeks to learn the real finding rate and false-positive rate on this codebase, so the first gate I turn on doesn't fire two hundred times on day one and burn all my credibility at once. (2) Make the safe path the fast path. A golden base image with hardening and scanning already baked in, and a paved-road CI template that wires up SAST, SCA, and secrets scanning by default, get adopted because they save work, not because anyone mandated them — that's the core argument on security culture & champions and platform engineering for security guardrails. (3) Promote rules from guardrail to gate only after they've proven a low false-positive rate, and only for findings with no legitimate exception. (4) Every deny explains itself — which rule fired, where, why, who owns it, and how to request a time-boxed waiver. An unexplained block is the single most reliable way to teach an org to work around you.

And I'd reserve a hard "no" for the small minority of cases where it's genuinely warranted. A "no" that arrives twice a year lands. A "no" that arrives twice a week is background noise.

What they're really checking: whether you understand that adoption is the hard part, not tool selection. Candidates who answer this purely technically — "I'd add SAST, SCA, and a policy gate" — have answered a question that wasn't asked.

Domain 2 — Threat modeling

☺ Like you're 10: This is the "think before you build" skill, and it's the one no tool can do for you — so interviewers use it to sort people who understand security from people who can install scanners.

Expect this domain to go practical: a common format is "here's a rough architecture, threat model it out loud." Prepare by being able to draw a data flow diagram and run STRIDE across it without notes. Covered in threat modeling.

🟢 2.1 What a threat model is

Q: What is threat modeling, and when in the lifecycle does it belong?

A: It's a repeatable exercise, not a document: look at a system's design, enumerate the ways an adversary could abuse it, and decide for each one whether you're mitigating it, accepting it, transferring it, or explicitly deferring it with a tracked follow-up. The output is a list of threats mapped to the part of the system they affect, with a severity or likelihood rating and — critically — a disposition for every single one.

What makes it threat modeling rather than a generic bug hunt is that it starts from the system's structure — how data moves, who's on each side of a boundary — rather than from a list of known vulnerability classes to grep for. That's why it belongs at design time: a missing authorization check found on a whiteboard is a five-minute edit to a diagram; the same check found by a penetration tester is a scramble to patch, retest, and explain; found by an attacker in production it's an incident response engagement and possibly a breach notification.

🟢 2.2 STRIDE

Q: Walk me through STRIDE. What does each letter stand for, and what security property does each one violate?

A: STRIDE came out of Microsoft in the late 1990s (Loren Kohnfelder and Praerit Garg) and is a mnemonic for six threat categories, each tied to a security property being violated. Applied to every element of a data flow diagram it turns "think about security" into six concrete questions per element.

The point worth adding unprompted: STRIDE is deliberately a checklist, not a scoring formula. It tells you that you haven't finished until you've asked the spoofing question about every trust-boundary crossing; it doesn't tell you how bad any given spoofing threat is. Severity and prioritisation come afterwards — from CVSS, from a model like DREAD, or from plain team judgement about blast radius and exploitability. Its value is coverage, because six categories asked consistently catch far more than an unstructured "does anything look sketchy" review that only surfaces the two or three threat types top of mind that week.

🟡 2.3 Trust boundaries

Q: What's a trust boundary, and why does STRIDE analysis concentrate on them?

A: A trust boundary is any point where data crosses from one level of trust to another: from an anonymous user's browser into your application, from your application into a database it authenticates to, from your VPC out to a third-party API. STRIDE concentrates there because a threat confined entirely inside one trust zone you control end to end — your own service talking to its own cache — is a much smaller concern than a threat at a point where a less-trusted actor is on one side.

The input STRIDE needs is a data flow diagram: external entities, processes, data stores, and the flows connecting them. And the diagram that matters is the one reflecting where data really crosses between components, not the tidy one in the design doc. In practice the interesting boundaries are exactly the ones people leave off the official diagram — a debug endpoint that reads production data directly, a cron job with its own database credentials, an internal admin panel someone declared safe because "it's only reachable from the VPN now." A system drawn with no trust boundaries at all isn't a system with no external risk; it's a sign the diagram hasn't been done properly yet.

What they're really checking: whether you'd ask about the undocumented paths. A strong answer to a live modeling exercise includes the question "what else talks to this database that isn't on the diagram?"

🟡 2.4 Attack trees

Q: When would you use an attack tree instead of STRIDE?

A: Not instead — alongside. STRIDE over a data flow diagram is breadth-first: it pushes you to look at every element and every boundary once, and it produces the broad list of "these threats exist." An attack tree, a technique formalised by Bruce Schneier in the late 1990s, is the depth-first complement: you start from a single attacker goal at the root — "exfiltrate the customer database," "impersonate an admin user" — and decompose it into the sub-goals or steps that would achieve it, branching until each leaf is a concrete, evaluable action. Branches get marked AND (all sub-steps required) or OR (any one suffices), which makes the tree useful for estimating the cheapest viable path to the goal rather than just enumerating all paths.

So the workflow is: run STRIDE over the DFD to get coverage, then build an attack tree for the handful of threats that are high-severity or hard to reason about in one line — typically the ones you'd want a red-teamer or a security champion to walk through step by step, like "how would someone actually get from a compromised low-privilege service account to production database access." Attack trees don't scale to full-system coverage, because building one per element is a lot of work for little marginal insight; they're the right tool once you already know which target deserves the deeper look. The offensive security lesson covers what happens when someone actually walks one of those paths for real.

🔴 2.5 Keeping a model alive

Q: A team tells you they threat modeled this service. The model is eighteen months old. What's your assessment, and what would you change?

A: My assessment is that it's a historical document, not a security control, and I'd say that without implying anyone did anything wrong — the most common way threat modeling fails isn't skipping it, it's treating one pass as permanent. A threat model reflects the architecture and trust boundaries at a specific moment. Eighteen months of changes — a new external integration, a service split in two, a boundary quietly removed because "it's only reachable from the VPN now" — can invalidate large parts of it without anyone noticing, because nothing forces a re-check.

What I'd change is to give it triggers and a cadence, the way any other recurring engineering activity has them. Event triggers: re-run the model whenever a new trust boundary appears (new external integration, new service, new deployment target) or whenever a major feature changes what data flows where. A fixed backstop: a scheduled revisit regardless — quarterly is a common baseline for actively developed systems — to catch the changes nobody flagged. A home for the artifact: keep the DFD as a living diagram next to the architecture docs, and make re-running the STRIDE pass a checklist item on any pull request that touches it. Some teams do that as a PR requirement; others run a lighter recurring workshop. Either works. What doesn't work is "we did threat modeling" continuing to mean a single meeting from a year and a half ago.

I'd also check one thing before proposing any of that: whether the original model recorded dispositions and whether the mitigations it decided on actually shipped. A model whose accepted risks were never revisited and whose mitigations were never implemented has a second problem underneath the staleness.

Domain 3 — SAST, DAST & SCA

☺ Like you're 10: Three different kinds of check — reading the code, poking the running app, and checking the parts you borrowed. This is the biggest block of questions, because it's most of the job.

Seven questions, and this is where a technical deep-dive typically spends the most time. The pattern is always the same escalation: definitions, then blind spots, then triage, then "so how do you stop the tool from being ignored." Covered in SAST, DAST & SCA, with depth on the composition side in Software Composition Analysis in Depth and on the static side in Static Analysis & Secrets Detection.

🟢 3.1 The three categories

Q: Explain the difference between SAST, DAST, and SCA.

A: They answer three different questions. SAST — static application security testing — analyses source, bytecode, or binaries without executing them, building an abstract syntax tree or control-flow graph and matching against dangerous constructs: string concatenation flowing into a SQL query, unsanitised input reaching an eval(), a hardcoded key, user input reaching a shell command. It answers "is my code written safely." DAST — dynamic — treats the deployed application as a black box and attacks it the way an external adversary would, crawling routes and throwing malformed input at every field, header, and parameter, watching real HTTP responses for evidence the attack worked. It answers "does my running app behave safely." SCA — software composition analysis — doesn't read your code at all; it resolves your third-party dependencies and matches them against known-vulnerability data. It answers "are my dependencies known-vulnerable."

The reason all three exist is that each one's blind spot is a different one's strength. A pipeline missing any one of them has a permanent gap that no amount of tuning the other two will close.

🟢 3.2 Pipeline placement

Q: Why does SAST typically run earlier in a pipeline than DAST?

A: Because of what each one needs as input. SAST needs nothing but the source tree, so it can run in the editor as you type, as a pre-commit hook, or as a required check on every pull request — seconds to minutes on a diff. DAST needs a live, reachable, deployed instance to attack, so it can only run after a build has been deployed somewhere, which in practice means staging, after unit tests and the SAST gate have already passed. A full DAST scan against a non-trivial application also runs from roughly twenty minutes to several hours, which rules it out as a per-commit check on cost grounds even if you could point it at something.

So the normal shape is: SAST and SCA together as required merge-blocking checks at pull-request time, since both need only the source tree and a lockfile; image scanning after the build produces an image; DAST against staging, gated before promotion to production; and posture and runtime monitoring running continuously rather than per-deploy, because a live environment can drift independent of any release.

🟡 3.3 What DAST catches that SAST can't

Q: Name a class of vulnerability DAST can find that SAST structurally cannot, and explain why.

A: Runtime and configuration issues, because they don't exist as a pattern in any source file for a static tool to match against. Concrete examples: a missing Content-Security-Policy or X-Frame-Options header; a session cookie missing the Secure or HttpOnly flag; a misconfigured TLS listener; an authentication bypass that only appears when two middleware layers interact in a particular order at runtime. None of those are visible by reading any single file, and all of them are visible the moment you actually send requests to the running system.

There's a second, related gap worth naming because it belongs to neither tool: business logic. A SAST engine won't flag "this endpoint lets a normal user cancel someone else's order," because nothing about that code looks syntactically wrong — and a generic DAST crawler usually won't either, because it doesn't know what the application is supposed to permit. That whole class is authorization logic, and it's why API security testing uses an explicit authorization matrix — broken object-level authorization is the canonical case, and finding it means replaying user A's requests with user B's token and checking what comes back, not fuzzing for injection strings.

The cost of DAST's realism is precision about location: a finding tells you a symptom — "this endpoint returned a 500 with a stack trace for this payload" — not a source line. Someone still has to trace the response back to the code.

🟡 3.4 Why SCA carries so much weight

Q: Why does SCA matter as much as it does, and what's its characteristic failure mode?

A: Because a typical production codebase is majority third-party code. Open-source composition surveys have consistently put third-party and open-source code somewhere in the region of 70–90% of a typical application's footprint — the exact figure varies by study and by ecosystem, but the direction has been stable for years. A scanner analysing only the code your team wrote is, by construction, looking at a minority of what actually ships.

The deeper reason it earns its own category is transitivity. Your manifest names direct dependencies; the vulnerable package is usually several hops down, pulled in by something you trusted. Log4Shell (CVE-2021-44228, disclosed December 2021) is the teaching example: teams that grepped their own pom.xml for "log4j" and found nothing still shipped it, because it arrived three or four levels deep inside libraries that logged through it. Which is also why an SCA tool has to read the lockfile, not the manifest — the manifest is a wish list of version ranges, the lockfile is what the resolver actually installed.

Its characteristic failure mode is reachability: a CVE match tells you a vulnerable version is present, not that your code ever calls the vulnerable function. Naive SCA output ranks purely by the dependency's CVSS score and reports Critical on libraries whose affected code path you never touch, which buries the genuinely exploitable findings under noise. More mature tools attempt reachability analysis specifically to filter for this. A related trap in npm specifically: the same package can resolve at two different depths simultaneously when two direct dependencies need incompatible ranges, so "we updated it" can be true of the hoisted copy and false of the nested one.

🟡 3.5 CVSS, EPSS and KEV

Q: Your scanner reports a CVSS 9.8. How do you decide how urgently to act?

A: The base score alone doesn't tell me, because CVSS measures severity — how bad it is if exploited — not likelihood. I'd want three signals before I put a number on urgency.

First, read the vector, not the headline. Every report exposes the full vector string alongside the number. Log4Shell's is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, scoring 10.0: network-reachable, low complexity, no privileges needed, no user interaction, and — the part people skip — S:C, Scope Changed, meaning a successful exploit affects resources beyond the vulnerable component itself. Compare Text4Shell (CVE-2022-42889) at 9.8, whose vector is identical except S:U. Two Criticals, meaningfully different blast radii.

Second, add EPSS. The Exploit Prediction Scoring System, maintained by FIRST, estimates the probability a CVE will actually be exploited in the wild in the next thirty days, and it's recalculated daily — so a CVE's EPSS score can climb sharply the week exploitation starts, while its CVSS score never moves at all. Third, check CISA's KEV catalog. Where EPSS is a probability, KEV is a confirmed fact: these are vulnerabilities CISA has verified are being actively exploited, with mandated remediation deadlines for US federal agencies under BOD 22-01 and increasingly treated as a hard "patch now" signal regardless of sector.

Stack them and triage falls out: high severity plus high EPSS plus on KEV is patch-immediately, block the release. High severity with low EPSS and not on KEV is scheduled remediation with a tracked deadline. And — the pairing CVSS-only triage misses entirely — a Medium with high EPSS or a KEV listing gets escalated anyway, because active exploitation overrides a modest severity score. Finally, reachability: a 9.8 in code you never call is genuinely lower priority than a 6.1 on an internet-facing endpoint. Whatever thresholds you pick, write them down as policy so triage doesn't depend on who's on call.

🔴 3.6 Four thousand findings on day one

Q: You turn SAST on against a five-year-old codebase and get four thousand findings. Now what?

A: The one thing I would not do is make it a blocking gate on day one, because a report with four thousand open untriaged findings is functionally identical to a report with zero: nobody can find the one that matters inside that much noise, so nobody looks at any of it. That's the mechanism that lets a scanned, known vulnerability sit unpatched — a giant backlog trains people to treat the tool's entire output as background noise, including the entry that was actually dangerous.

What I'd do instead, in order:

• Baseline the existing findings. Snapshot the current set as accepted-for-now and gate only on new findings introduced by a diff. That makes the gate immediately meaningful without asking anyone to fix five years of history before they can merge a typo fix.
• Tune the rule set before widening coverage. Most of four thousand is usually a handful of noisy rules firing repeatedly, plus test fixtures and vendored directories that should be excluded. Sample fifty findings by hand, work out the true-positive rate per rule, and turn off or downgrade the rules that don't hold up. Suppress confirmed false positives with a documented reason, not silently.
• Burn down the baseline by severity band, with owners and an SLA. Every open finding needs an owner and a severity-based clock from the moment it's created — and the gate that matters later is finding age past SLA, not finding existence. Route it through a vulnerability-management platform that dedupes across tools and tracks age rather than count; DefectDojo is the common open-source reference point, and the mechanics are in vulnerability management & triage.
• Watch for repeats. If one rule fires two hundred times across repos, that's not two hundred tickets, it's one shared fix — a golden-path template that was written wrong, or a pattern worth blocking at commit time. Fixing the same class of bug two hundred times individually is whack-a-mole remediation.

And I'd report an outcome metric alongside the coverage metric from the start — "median days-to-fix for Criticals" next to "% of repos with SAST enabled" — because a coverage number with no paired outcome number is a number chosen because it always goes up.

🔴 3.7 What blocks a build

Q: How do you decide which findings block a build and which go to a backlog?

A: I'd frame it as two separate questions that get conflated: how severe is this class of finding, and how confident is the tool. Blocking on a category where the tool's false-positive rate is high is how you train people to click past gates.

My default policy shape: hard-fail on findings that are both high-confidence and have no legitimate exception in this organisation — a verified secret detected in a diff, a failed signature verification, a Critical or High CVE in a production dependency with a fix available, a publicly writable storage bucket in an IaC plan. Warn and track on Mediums, on findings in a rule category still being tuned, and on Criticals where no fix exists yet — because blocking on something nobody can fix just produces an override habit. Never block silently: every deny returns the specific rule that fired, where, why, a link to a fix guide, a named owner, and a documented, time-boxed waiver path.

The waiver mechanism is the part people underrate. A gate with no appeal path doesn't get respected, it gets routed around — people disable the check "just this once," mark a finding a false positive with no review, split a diff across two pull requests so the trigger doesn't fire, or reach for the admin override that exists for emergencies and quietly becomes the default. A waiver that's explicit, attributed, time-boxed, and expires loudly is strictly better than an override nobody can audit.

Finally, I'd promote rather than launch: new rules start as warnings, and after a few weeks of watching the real finding rate and false-positive rate on this codebase, the ones that hold up get promoted to hard gates. Turning everything into a hard gate on day one, before rules are tuned, is how you teach engineers to bypass the pipeline entirely — a local apply with hand-edited state, or a console change nobody reviews.

Domain 4 — Secrets management

☺ Like you're 10: Where passwords and keys live, how they get handed out, and what to do the moment one leaks — which is almost never "delete it and hope."

Five questions. The second one is asked in some form in most DevSecOps loops, because the intuitive answer is wrong and the correct answer is short. Covered in secrets management.

🟢 4.1 Why hardcoded secrets are a standing liability

Q: What's actually wrong with a credential in a config file, beyond "someone might see it"?

A: Three things compound. Permanence: git stores every commit as an immutable object, so a secret pasted into source becomes part of the codebase's permanent record — present in every clone, fork, CI cache, and mirror that ever pulled the history. Leak surface: hardcoded secrets escape through far more channels than a careless git add. Verbose application logs and unhandled exceptions routinely dump connection strings and auth headers into log aggregators that far more people can read than the source repo. CI systems echo environment variables into build logs unless the platform explicitly masks them. And once a secret is baked into an artifact — a container image layer, a compiled binary, a published package — it ships to everyone who pulls that artifact, including anyone who mirrored it after you "fixed" it upstream.

Operational cost: a hardcoded secret is usually referenced in more than one place — a dozen services reading the same value, a key copy-pasted into three repos — so rotating it means finding every reference and redeploying every consumer in lockstep. Teams skip rotation because it's manual and risky, which is precisely the incentive a centralised secrets manager exists to remove.

🟢 4.2 The deleted-secret question

Q: A developer committed an AWS access key, noticed an hour later, deleted it in the next commit, and force-pushed. Are we fine?

A: No. Treat the credential as compromised and rotate it — that's the whole answer, and everything else is secondary.

Deleting a secret in a later commit doesn't remove it from history. Force-pushing over the branch tip doesn't remove it from local clones anyone already made, from forks, from CI caches, or from any mirror that pulled before the rewrite. On a hosted platform there may also be cached objects and pull-request refs that survive a branch rewrite. Rewriting history with something like git filter-repo is a legitimate cleanup step, but it is a cleanup step, not a substitute for rotation.

Beyond rotating, I'd want two more things: pull the access logs for the exposure window to scope what that key actually touched — an hour of exposure on a public repo is long enough for automated scrapers to have found and used it — and check whether the same credential was reused anywhere else, because if it was, rotating one reference doesn't close the exposure.

🟡 4.3 What a secrets manager buys you

Q: We moved our secrets out of the repo and into environment variables. Is that enough?

A: It depends entirely on what populates the environment variable. If the value comes from the secrets manager at deploy or container start, that's the right pattern. If it comes from a .env file sitting in the repo next to the code, it's the same hardcoded secret with an extra layer of indirection — the .env belongs in .gitignore, with only a .env.example of placeholder keys in version control.

What a real secrets manager — Vault, AWS Secrets Manager, Azure Key Vault, Google Secret Manager — buys over a flat file is three things a file structurally cannot provide. Centralised access policy: who and what can read which secret, enforced in one place rather than scattered across filesystem permissions on whichever machines happen to hold a copy. An audit log of every read: who accessed which secret and when, which is usually the first thing an incident responder pulls when scoping a suspected credential compromise. Encryption and versioning managed by infrastructure built for the job, rather than bolted on.

The application never has the value on disk in source control; it authenticates to the manager — via an IAM role, a Kubernetes service account, or a short-lived token — and requests the value it needs. In Kubernetes specifically, tools like the External Secrets Operator or a Vault agent injector extend this into the cluster so the value never lands in a plaintext Secret manifest either. Vault's own lesson covers the mechanics.

🟡 4.4 Static vs dynamic credentials

Q: Why is a short-lived dynamic credential better than a static one with identical permissions?

A: Because the exposure window is bounded by design rather than by how fast a human reacts. A static credential — a database password set once and used for a year — is valid until somebody remembers to change it, so a leak from six months ago is still exploitable today. A dynamic credential is generated on demand with a TTL measured in minutes or hours: Vault's database secrets engine, for example, can create a fresh database user with scoped permissions per application instance and revoke it automatically when the lease expires. If that leaks, an attacker has at most the remaining TTL.

That difference matters because detection is slow. Industry breach reporting has consistently found that the gap between compromise and detection is measured in weeks, not minutes — so a control that depends on someone noticing is a control that fails in the common case. A fifteen-minute TTL doesn't depend on anyone noticing at all.

Cloud providers apply the same idea at the infrastructure layer: AWS STS role assumption and workload identity federation on GCP and Azure issue temporary credentials to a workload's identity rather than embedding a long-lived access key, which is why modern cloud guidance treats a hardcoded IAM access key as close to a code smell. In CI specifically, that's the OIDC federation pattern covered in workload identity & pipeline IAM: the pipeline exchanges a signed, short-lived identity token for cloud credentials, and no long-lived secret is stored in the CI system at all.

🔴 4.5 Designing the whole programme

Q: Design a secrets programme for an org with two hundred repositories and no current tooling. Where do you start and what does "done" look like?

A: I'd sequence it as detect, then contain, then prevent, because you can't rotate what you haven't found and you can't prevent recurrence while the existing leaks are still live.

Detect. Run a full-history scan across all two hundred repos — Gitleaks, TruffleHog, or detect-secrets — not just the current tree, because history is where the exposure lives. TruffleHog's live verification against the issuing provider is valuable here specifically because it separates "credential-shaped string" from "credential that currently works," which is the difference between a triage queue you can act on and one you can't.

Contain. Every verified live credential gets rotated, prioritised by blast radius, with access logs pulled for the exposure window. This is the expensive phase and it's the one that gets skipped; I'd resource it explicitly rather than assuming teams will fit it around feature work.

Prevent, in three layers, because each one can be bypassed. Pre-commit hooks are the cheapest place to stop a leak but they're a courtesy, not a control — any developer can pass --no-verify. So the same scanning runs again as a mandatory CI gate that fails the build, and again as platform-level push protection on the remote where the hosting provider supports it, plus periodic full-history rescans to catch what slipped through both. Findings fail the build; they don't log a warning.

And make the safe path the easy path, or none of the above holds. A self-service secrets-manager integration that's faster to adopt than rolling your own, a paved-road CI template with secret injection already wired, and short-lived dynamic credentials as the default. "Done" looks like: no new secrets reaching a shared branch (measurable — count of CI secret-scan failures reaching main, which should be zero), every long-lived static credential either eliminated or on an automated rotation schedule, and a documented rotation policy with three triggers — scheduled, on personnel change, and immediately on suspected exposure.

Domain 5 — Container & supply-chain security

☺ Like you're 10: What's inside the box you ship, who packed it, and how anyone downstream can tell it wasn't swapped on the way.

Six questions. This domain has grown fastest in interview weight over the last few years — signing, SBOMs, and provenance moved from specialist to expected. Covered in container & supply-chain security, with more in Software Bills of Materials and container runtime security.

🟢 5.1 Minimal and distroless base images

Q: Why use a distroless or minimal base image? Is it just about image size?

A: Size is a side effect; the security argument is attack surface. A general-purpose base image ships a shell, a package manager, coreutils, and hundreds of libraries intended for interactive administration — none of which a compiled binary or a bundled application needs at runtime. Every one of those packages is a component a CVE can eventually apply to and that you're responsible for patching, and every shell binary in the image is a tool an attacker can use to pivot once they have code execution, whatever gave them that foothold.

Distroless strips the base to the language runtime and its direct OS-level dependencies — no shell, no package manager. Alpine-based images are a lighter version of the same idea with a real but minimal userland, and scratch goes furthest: a genuinely empty base, viable only for a fully static binary.

Two other things I'd pair with it, because they're what actually make the pattern work. A multi-stage build, so the compiler and source tree never cross into the shipped image — only the built artifact does. And an explicit non-root user: running as root is one of the most common image-scan findings precisely because the default Dockerfile in most tutorials never sets a USER line, and container escapes that depend on a root-owned process have no foothold to start from without one.

The honest trade-off is operational: no shell means no shelling into production to debug, which pushes you toward ephemeral debug containers instead. Interviewers like hearing that named, because it's the objection their platform team will raise.

🟢 5.2 Signing vs scanning

Q: We scan every image before it's pushed. Do we still need signing?

A: Yes, because they answer different questions and neither substitutes for the other. Scanning tells you what's inside the image — which known-vulnerable packages it contains. Signing tells you the image actually came from who it claims to and hasn't been altered since. A signed image can still be full of vulnerable dependencies, and a clean scan means nothing if the bytes were swapped after the scan ran.

Without signature verification, nothing stops a compromised registry, a network path in between, or a malicious insider from replacing a legitimate image under the same tag — the classic version being a poisoned mutable tag silently redirecting a future deploy. Sigstore's cosign is what most of the industry has converged on: sign an image's digest with a private key, or use keyless signing where identity ties to an OIDC login such as a CI workflow identity and the signature is recorded in a public transparency log rather than requiring anyone to manage a long-lived key. Then a Kubernetes admission controller — Kyverno or the Sigstore policy controller — enforces verification at deploy time, refusing to schedule a pod whose image isn't signed by an expected identity.

The detail worth adding: verification has to happen somewhere that isn't the same system that produced the signature, and it should be pinned to a digest rather than a mutable tag, or you've verified something other than what you're about to run.

🟡 5.3 SBOMs

Q: What's an SBOM, and what does it actually get you?

A: A Software Bill of Materials is a structured, machine-readable inventory of every component in a built artifact — every OS package and language dependency, at specific versions — usually expressed as SPDX (a standard published as ISO/IEC 5962:2021) or CycloneDX (from the OWASP community). Tools like Syft and Trivy generate one from a built image in CI, and it's stored alongside the artifact.

The payoff isn't at build time, it's afterwards. When a new CVE is disclosed, the operational question is "which of our services use this library, at which version, and where are they deployed?" Without SBOMs that's a manual, multi-day audit that's easy to get wrong — the Log4Shell scramble is the canonical example. With SBOMs generated at build time and indexed centrally, it's a query against stored inventories that returns a precise list of affected artifacts in minutes.

Two nuances worth having ready. Generated at build time beats reconstructed later: the build knows exactly what it resolved and installed; anything reconstructed by scanning a finished image afterwards is an inference and will miss things the build could have recorded for free. And an SBOM is an inventory, not an assessment — it doesn't tell you whether anything in it is vulnerable, which is why it's stored and then repeatedly re-queried as vulnerability data changes, rather than checked once and filed.

🟡 5.4 SLSA

Q: What is SLSA, and what would you have to change to move a pipeline up a level?

A: SLSA — Supply-chain Levels for Software Artifacts, originated at Google and now under the OpenSSF — is a framework for describing how much you can trust that an artifact was built the way its source claims. It isn't a scanner; it's a set of increasing process and provenance guarantees you audit a build pipeline against, so that "secure pipeline" means something specific instead of meaning something different to everyone in the room.

Roughly: Build L1 requires the build to be scripted and automated and to produce provenance metadata describing how the artifact was made. Build L2 requires that provenance to come from a managed build service and to be signed, so a consumer can distinguish a genuine CI-produced artifact from a fabricated one. Build L3 requires the build platform to isolate workflows from each other, so one compromised job can't forge convincing provenance for another artifact.

Moving up in practice means: from nothing to L1, stop building on laptops and emit provenance from CI. L1 to L2, move to a managed build service and sign the provenance — in-toto attestations recording which pipeline, which commit, and which inputs produced this exact artifact, with cosign doing the signing. L2 to L3, harden the build platform itself: ephemeral, isolated runners, no shared mutable state between jobs, and no path for a job to influence another job's provenance.

The honest caveat I'd offer unprompted: very few organisations run every build at the top level, and claiming L3 across the board would invite a follow-up I'd rather earn than dodge. The framework's practical value is as a shared vocabulary for stating precisely how much trust a given pipeline provides.

🔴 5.5 Dependency confusion

Q: Explain dependency confusion. Why doesn't image scanning catch it?

A: It exploits how package managers resolve a name when both a private internal registry and a public registry could plausibly hold a package with that name. If an organisation has an internal package called, say, acme-auth-utils on a private registry, and an attacker publishes a package with exactly that name to the public registry — typically with a deliberately higher version number — a misconfigured build can resolve to the public, attacker-controlled package, because default resolution logic in several ecosystems consults the public registry and treats a higher version there as authoritative regardless of source.

It's demonstrated, not theoretical: the researcher Alex Birsan published counterfeit packages under internal names he'd found leaked in manifests and internal tooling references and got code execution inside a long list of large companies' networks in 2021.

Scanning doesn't catch it because every downstream control runs after the wrong package has already been resolved and pulled into the build. An SCA scan sees a package with no known CVEs — the attacker's package isn't in any vulnerability database, it's brand new and it's malicious rather than vulnerable. An SBOM faithfully records the wrong package. A signature attests that your pipeline really did build this artifact, which is true and unhelpful. The compromise happened at resolution time, upstream of all three.

So the fix is configuration at resolution time: scope internal package names explicitly (npm's org scoping is the standard example), pin the package manager to the private registry as the sole source for internal names rather than allowing fall-through to public, and defensively reserve placeholder packages on the public registry for your internal names so an attacker can't claim them first. The broader lesson — and it's the reason interviewers like this question — is that supply-chain security needs controls at source, build, and artifact, not one scanner covering everything downstream. Typosquatting is the adjacent attack that exploits a keystroke rather than a namespace; both are covered in dependency & license risk.

🔴 5.6 When a clean image still misbehaves

Q: The image passed every scan and it's signed. It's now doing something strange in production. What kind of control would have caught that, and how does it work?

A: A build-time scan is a statement about known vulnerabilities in the image's contents at the moment it was scanned. It says nothing about behaviour, and nothing about vulnerabilities disclosed after the scan ran — a package clean today can have a CVE published next week without a single byte of the image changing. So two different controls apply.

For the second problem, rescanning: registries rescan stored images, and scanning what's actually running matters as a separate layer, because a pipeline that passed its gate six months ago is not necessarily still clean.

For the first — strange behaviour — you need runtime security, which watches what the container does rather than what it contains. The mainstream mechanism is eBPF: a probe attached in the kernel observes syscalls from container workloads without needing a kernel module, and a rules engine such as Falco matches those events against behavioural rules. The signals that matter in practice are things a static scan can't express: a shell or package manager executing inside a container that shouldn't have one, an outbound network connection to somewhere the workload has no business talking to, a write to a path that should be read-only, or a privilege escalation attempt inside the container.

The trade-off to name: runtime rules have a base-rate problem. A rule that's accurate in a lab can still produce more false positives than a team can read once it's applied to thousands of workloads, so a runtime programme is mostly tuning and suppression work, not installation work. And detection needs the same treatment as code — rules in version control, tested against known-good and known-bad traces, reviewed in pull requests — which is the argument in detection engineering.

Domain 6 — IaC security & policy as code

☺ Like you're 10: Checking the building plans before anything gets built, and writing the building code down as a program so a computer can check it every single time.

Five questions. For anything platform-adjacent this is a heavy block, and Rego literacy is a genuine differentiator — many candidates can describe policy as code and far fewer can sketch a rule. Covered in IaC security & policy as code and infrastructure as code hardening.

🟢 6.1 What an IaC scanner does

Q: What does an IaC scanner check, and why is scanning infrastructure definitions worth doing at all?

A: It's static analysis for infrastructure definitions. Tools like Checkov, tfsec, Terrascan, and the IaC modes of broader scanners parse a Terraform plan, CloudFormation template, or Kubernetes manifest and check each resource block against a library of known-bad patterns: a storage bucket with public read or write access, a security group with an unrestricted source CIDR, a database instance provisioned without encryption at rest, an IAM policy granting a wildcard action on a wildcard resource, a listener accepting plaintext HTTP where TLS should be mandatory. Those checks map closely onto published benchmarks such as the CIS Benchmarks, so a failing check is usually a specific citable line item rather than an arbitrary opinion.

It's worth doing because misconfiguration — not a novel zero-day — is repeatedly identified as the leading cause of cloud security incidents, and every one of those misconfigurations exists as a line of text in an IaC definition before it exists in a running account. Before IaC, a bad security group was a state inside a console, invisible to review until someone went looking. As code it's a text diff in a pull request: reviewable, diffable, and scannable before anything is applied.

Where it runs decides whether it's worth anything. Run manually before a migration, it catches a snapshot and lets new problems accumulate immediately. Run as a required pipeline step, it catches every misconfiguration on every change at the moment fixing it is a one-line diff. Most teams wire it in at two points: a fast pass on plan output in the pull request, and a slower exhaustive pass over the whole repository on a schedule — because a plan-time scan only sees what that change touches, not the accumulated state of everything already deployed.

🟢 6.2 Policy as code

Q: The scanner already has hundreds of built-in rules. Why would we also need policy as code?

A: Because the built-in library covers generic, industry-common misconfigurations, and every organisation also has rules that are specific to it: no resource may be created without a cost-centre tag; only a named team may provision in a particular region; no storage bucket may be created without a matching audit-logging rule; production databases must be in a specific subnet group. A scanner vendor can't ship those, because they're facts about your organisation.

Historically those rules lived in a security wiki, a PDF standard, or an architecture review board's memory — none of which a computer can check and none of which a developer reliably reads before opening a pull request. Policy as code expresses them as versioned, executable code instead. A general-purpose policy engine — Open Policy Agent with Rego is the reference implementation most tooling converges on, with HashiCorp Sentinel as a commercial alternative — evaluates a structured input (a Terraform plan in JSON, a Kubernetes admission request, an API call) against the policy and returns an allow/deny decision.

The benefit is that the rule now gets the same treatment as any other code: reviewed in a pull request, versioned so you can see when it changed and who changed it, unit-tested against known-good and known-bad inputs, and applied identically in every environment rather than depending on which reviewer was paying attention.

🟡 6.3 Guardrails vs gates

Q: Should every policy violation block a deploy?

A: No, and conflating the two is a common way a policy-as-code programme loses credibility. A soft guardrail evaluates the policy, surfaces a warning in the pull request or as an annotation on the plan, and lets the engineer proceed — typically with a required justification or a second approver. A hard gate blocks outright: the merge is disallowed or the apply fails, and there's no path to production without either fixing the resource or going through an explicit, logged exception process.

Use a guardrail for rules with legitimate exceptions or a real false-positive rate — a wildcard IAM action that's genuinely scoped by a condition block the scanner doesn't parse, or a new rule category still being tuned against the existing estate. Use a hard gate where there's no legitimate exception in your organisation: publicly writable storage holding customer data, encryption disabled on a regulated data store, a database exposed directly to the internet.

The failure mode runs in both directions, which is the part worth saying out loud. Making everything a hard gate on day one, before rules are tuned, trains engineers to route around the pipeline entirely — a local apply with hand-edited state, or a console change nobody reviews. Making everything a soft guardrail forever means the highest-severity findings pile up as warnings that get dismissed by habit. The pattern most mature programmes converge on is promotion: launch new rules as guardrails, watch the finding rate and false-positive rate for a few weeks, then promote the ones that hold up.

🟡 6.4 Writing a rule

Q: Sketch a policy rule that denies a publicly readable storage bucket. Talk me through it.

A: In Rego, evaluated against Terraform plan JSON, it's deliberately unremarkable — and that's the point I'd make while writing it:

package terraform.s3
import future.keywords.in

# Deny creating an S3 bucket if its ACL grants public read access.
deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket_acl"
  resource.change.after.acl in ["public-read", "public-read-write"]
  msg := sprintf(
    "resource %q: S3 bucket ACL %q is publicly readable; use a private ACL and grant access via bucket policy instead",
    [resource.address, resource.change.after.acl],
  )
}

Three things to walk through. It iterates over the planned resource changes and filters to the resource type it cares about — so it's evaluating what's about to happen, not the current state. It compares a value. And it builds a message. That's the whole rule: policy as code isn't a research problem, it's taking a rule an engineer can already state in one sentence and making it something CI enforces on every plan without anyone remembering to look.

The part I'd emphasise is the message. A deny that returns nothing but a boolean is what trains people to route around the gate — there's nothing to act on. A useful deny returns which rule fired, on which resource, why it's wrong, what to do instead, and ideally a named owner and a link to request a time-boxed waiver. I'd also unit-test the policy: a known-bad plan fixture that must be denied and a known-good one that must pass, so a later edit can't silently disable the rule. Conftest is the usual harness for running these in CI.

🔴 6.5 The limits of a pre-deploy gate

Q: You've got hard gates on every Terraform plan. What are you still exposed to?

A: Two things, and the first is the one people miss.

A hard gate only blocks what goes through the pipeline. Anyone with standing console access or local credentials can run terraform apply directly or click a change into existence, bypassing every policy check you've written. Gates in CI are necessary but not sufficient — they have to be paired with restricting direct write access to the cloud account itself, ideally down to the pipeline's own service identity, with human access being break-glass and time-boxed. Without that, the gate is security theatre with a convincing UI.

And pre-deploy scanning says nothing about a resource that was compliant at deploy time and stopped being compliant afterwards — a security group widened during an incident and never narrowed, a bucket policy loosened at 2 a.m. while debugging, a resource that fell out of Terraform's management entirely. That's configuration drift, and only continuous re-evaluation catches it: scheduled plans against existing state, cloud-native config rules, or a CSPM platform re-checking every live resource against the same policy set used at deploy time.

The framing I'd offer is that pre-deploy scanning, admission-time policy, and drift detection are the same rule set applied at three points in a resource's lifecycle — before it's created, at the moment it's created, and for as long as it continues to exist. A programme that only runs the first has a false sense of coverage, because the environment can fail every rule it started out passing.

Domain 7 — Cloud security posture

☺ Like you're 10: Which parts of the cloud the provider locks and which parts you have to lock yourself — and how you keep checking, since a door can get propped open any day.

Five questions. The shared responsibility model and least privilege are near-universal; specific service names depend on which cloud the employer runs, so find that out before the interview and rehearse in the right dialect. Covered in cloud security posture, with the consolidated-platform view in CNAPP.

🟢 7.1 Shared responsibility

Q: Explain the shared responsibility model. What does the customer never get to hand over?

A: Every major provider draws the same line: the provider is responsible for security of the cloud — physical data centres, hardware, the hypervisor isolating tenants, the network fabric — and the customer is responsible for security in the cloud: how they configure what they provision on top, meaning their data, their IAM policies, their application code, and depending on the service model their operating system and runtime.

Where the line sits moves with how much of the stack the provider manages. With raw virtual machines you inherit almost everything above the hypervisor — OS patching, runtime, middleware, application, data, IAM. With a managed platform service the provider absorbs the OS and runtime, leaving application code, data, and access configuration. With SaaS the provider runs essentially the whole stack and you're left with exactly two things.

Those two things are the answer to the second half of the question: your data, and who is allowed to touch it. Data and identity/access configuration never transfer, in any service model. That's worth saying explicitly, because the common misconception in the other direction — "we moved to SaaS so security is handled" — is precisely the gap that produces incidents.

🟢 7.2 CSPM

Q: What is CSPM, and how is it different from an annual compliance audit?

A: Cloud Security Posture Management is tooling that connects to a cloud account or a whole organisation through the provider's own APIs, reads live configuration, and checks it against a baseline — the CIS Benchmarks, an internal policy set, or a compliance framework's control list. The distinguishing property is continuously: it re-scans on a cadence measured in hours.

An annual audit is a snapshot, and cloud configuration drifts far faster than annually. Someone opens a security group for a debugging session and forgets to close it; a module ships without an encryption flag; a bucket policy gets loosened during an incident and never gets tightened back. A quarterly or annual check means a control that silently drifted in month three can go unnoticed for the rest of the year. CSPM turns that from a year of exposure into hours, and most platforms now offer automated or one-click remediation for well-understood findings.

Worth adding: a well-run CSPM and a well-run continuous-compliance programme frequently read the exact same underlying signals for two different audiences — one feeding a security engineer's dashboard, the other mapped against a framework's control list. They're not separate systems doing separate work, which is the practical argument for building the control once and mapping it many ways.

🟡 7.3 The misconfigurations that actually matter

Q: Which cloud misconfigurations cause most real incidents, and can you give an example of them chaining?

A: Four categories dominate real scan results and real incidents. Publicly exposed storage — a bucket or blob container with public read or write, usually set once for a legitimate reason and never revisited. Over-permissive IAM — roles and policies granting wildcard actions or wildcard resources far beyond what the attached workload needs, plus stale cross-account trust relationships nobody remembers creating. Unencrypted data — volumes, snapshots, and database instances created without a managed key, or load balancers accepting plaintext HTTP. Exposed management ports — SSH, RDP, or a database port open to the whole internet instead of restricted to a bastion or VPN range.

The important point is that the worst breaches chain them rather than exploiting one. The 2019 Capital One breach is the standard teaching case: a server-side request forgery vulnerability in a misconfigured web application firewall let an attacker reach the instance metadata service and pull temporary credentials belonging to an IAM role scoped far wider than the workload required, and that over-permissioned role turned a single SSRF into access to over 100 million customer records. Fixing the SSRF would have closed that specific exploit; fixing the IAM role would have closed that exploit and every other path to the same data. The full timeline is in the Capital One case study.

What they're really checking: whether you think in attack paths rather than in finding lists. "SSRF plus over-permissive role plus reachable metadata service" is a chain; three separate scanner findings ranked by CVSS are not.

🟡 7.4 Least privilege in practice

Q: Everyone says "least privilege." How would you actually get there on an account that's been running for three years?

A: Least privilege means an identity — human, service account, or pipeline — gets exactly the permissions its job requires, granted that way from the start rather than trimmed after an audit flags the excess. On a three-year-old account nobody granted it that way from the start, so the work is a retrofit, and retrofits almost never happen on their own — which is precisely why the cloud providers ship access-analysis tooling that reports which granted permissions an identity has actually exercised over a trailing window. In practice, when vendors analyse real permission-usage logs, the share of granted permissions that ever get used is strikingly small.

So the sequence I'd run: observe before cutting — turn on access analysis and let it collect a meaningful window of real usage, typically ninety days, so you're rewriting policies from evidence rather than guesswork. Start with the identities with the widest blast radius, not the most numerous: standing human admin credentials and any service identity holding broad managed policies. Rewrite from an allow-list of the actions and resources actually exercised, rather than starting from a broad managed policy and hoping nobody exercises what it also grants. Time-box what's left: just-in-time role assumption for production access rather than a standing admin credential sitting in a profile for months. Codify it so the policy is reviewable text enforced before a change merges, not a console click.

And for anything new, the key idea is the cheap one: turn access analysis and posture scanning on at account creation. Reviewing a role at creation time is one design decision; reviewing it a year later is an archaeology project against logs nobody kept long enough.

🔴 7.5 Detective vs preventive

Q: Your CSPM keeps flagging public buckets and someone keeps creating them. What do you do?

A: Stop trying to detect the thing faster and make it structurally impossible instead. CSPM is a detective control: the misconfiguration has to exist before a scan can flag it, which means there's always a window between creation and remediation, and a recurring finding means that window keeps reopening.

The preventive answer is an organisation-level guardrail that sets a hard ceiling on what any identity in scope can do, regardless of how permissive its own IAM policy is. On AWS that's a Service Control Policy attached at the account or organisational-unit level — denying the API calls that make a bucket public makes a public bucket impossible to create in that account, not merely something a scan will eventually catch. Azure Policy with a Deny effect at the management-group level and GCP's Organization Policy Service with a public-access-prevention constraint play the same role on their platforms.

I'd run both, not one. Guardrails for categories that should never happen anywhere in the estate; CSPM for everything the guardrails don't yet cover, plus drift on things guardrails can't express. And I'd treat the recurrence itself as information: if three teams keep creating public buckets, either there's a legitimate use case the guardrail needs an exception path for — a static-asset account, say, separated at the organisational-unit boundary — or the paved-road module everyone copies from has the wrong default. Fixing the template usually removes more findings than any amount of alerting on the symptom.

Domain 8 — Incident response & forensics

☺ Like you're 10: A break-in isn't a broken window. You don't sweep up first — you preserve what happened, work out who got in, and only then fix it.

Five questions, usually delivered as a live scenario rather than as definitions. The discriminator between a good and an excellent answer is almost always evidence preservation. Covered in incident response & forensics.

🟢 8.1 The lifecycle

Q: Walk me through an incident response lifecycle.

A: The SANS model is PICERL, six phases: Prepare — build the capability before you need it: runbooks, an on-call rotation, logging and detection coverage, forensic tooling, and a tested communication plan. Identify — confirm the event is actually a security incident, scope what's affected, and establish a rough timeline from the first available signal. Contain — stop it getting worse, choosing a strategy appropriate to what's at stake. Eradicate — remove the root cause: the malware, the compromised credential, the vulnerable code path used to get in. Recover — restore systems to normal operation, with verification that the threat is actually gone before traffic returns. Lessons learned — a blameless review that turns what happened into updated runbooks, detections, and controls.

It maps directly onto NIST SP 800-61's four phases — Preparation; Detection and Analysis; Containment, Eradication and Recovery; Post-Incident Activity — which is the same process at coarser granularity. Both are cyclical rather than linear: the output of Lessons Learned feeds back into Prepare, and if it doesn't, you're running the same incident again next quarter.

🟡 8.2 Security incident vs outage

Q: How is responding to a security incident different from responding to an outage?

A: An availability incident optimises for one thing: restore service as fast as possible, then find the root cause afterwards. There's no downside to acting immediately. A security incident adds three obligations on top of that, and getting any of them wrong can outlast the technical fix by months.

You have to preserve evidence, not just restore service. The outage instinct — reboot the box, roll back the deploy, clear the queue — actively destroys evidence during a breach. It may trigger legal and regulatory notification obligations that an availability incident never does, on clocks that start running from when you became aware rather than from when you finished investigating. And containment becomes a genuine trade-off rather than an obvious call, because stopping the damage and understanding it can pull in opposite directions.

None of that replaces operational on-call muscle memory; it layers on top of it. The practical consequence is that the escalation path is different: a security incident usually needs incident command, legal, and often communications in the loop early, and those are people an availability runbook never pages.

🟡 8.3 Evidence and chain of custody

Q: What's the order of volatility, and what is chain of custody for?

A: Order of volatility, set out in RFC 3227, says collect the most volatile evidence first, because it disappears the moment power or process state changes. Roughly: CPU registers and cache, then routing tables and ARP cache, then running processes and network connections, then memory, and only then disk, backups, and archival logs. The practical consequence is that a reboot flushes memory that might hold the only copy of an in-memory payload or a decryption key, and rotating a log file before it's exported deletes the record of what happened.

Chain of custody is the paperwork that makes evidence usable later — in a courtroom, an insurance claim, or a regulator's inquiry. It records who collected each artifact, when, from where, with what tool, and every hand it passed through afterwards, with each transfer logged and each artifact hashed at collection so later tampering is detectable. In cloud terms that also means forwarding logs to write-once storage before normal retention rotates them out, and imaging disks with a tool that doesn't modify the source rather than copying files off a live, still-mounted volume.

🔴 8.4 Isolate now or watch?

Q: You've found an attacker inside a production segment. Do you cut them off immediately?

A: It depends on whether there's active, irreversible loss happening, and I'd want that to be a decision the runbook already made rather than one I'm improvising at 2 a.m.

Immediate isolation has a real cost during a security incident that it doesn't have during an outage: it tips off the attacker, cuts off the telemetry you're using to understand what they've touched, and can permanently forfeit the chance to trace lateral movement, scope the true blast radius, or attribute the intrusion. Watching an active intruder for a bounded window, inside a segment you control, is sometimes the higher-value move — teams do it deliberately to map which systems were reached and what left the network before shutting the door.

The trade-off tips hard the other way the moment loss is active and irreversible. Ransomware mid-encryption or confirmed exfiltration in progress means immediate isolation, full stop, because every extra minute of observation is measured in encrypted or stolen data. Reconnaissance-stage access with a contained blast radius is where monitored containment can be justified.

Two things I'd insist on either way. It isn't a call an individual on-call engineer should make alone under pressure — it belongs in the runbook with legal and incident-command sign-off baked into the escalation path. And "watch" is only a legitimate option if you actually have the monitoring to learn something from watching; observing an attacker with insufficient telemetry is just delay with extra risk.

What they're really checking: whether you have a decision rule or an instinct. Either extreme stated as a universal — "always isolate immediately" or "always watch first" — reads as inexperience. The signal is naming the condition that flips the decision.

🟡 8.5 The leaked-credential runbook

Q: Write me the runbook for "a production credential has leaked."

A: In order, and the order matters:

• Revoke or rotate the credential immediately. Not after the investigation — the investigation runs against a credential that no longer works.
• Invalidate any active sessions it authorised. Rotating the credential doesn't necessarily kill sessions or tokens already issued from it, and that's a gap people leave open.
• Pull access logs for the exposure window — from first possible exposure, not from discovery — to scope what it actually touched. If you don't know when it was first exposed, assume the earliest plausible time.
• Rotate everything else that credential had access to, and anything sharing the same value elsewhere, before declaring the incident closed.
• Preserve the evidence — the logs, the commit or artifact where it leaked, the timeline — under chain of custody, because whether this becomes a notifiable event isn't your call to make alone.
• Then the systemic question: why did a long-lived credential exist in a form that could leak, and what would have caught it earlier — a pre-commit hook, a CI gate, push protection, or a short-lived credential that would have expired on its own.

The reason this needs to be written down in advance rather than derived live is that the sequence takes judgement that isn't available under pressure, and the steps people skip when improvising — session invalidation and downstream rotation — are exactly the ones that leave the incident half-closed. This course has a hands-on version of the whole thing in the leaked-credential triage drill.

Domain 9 — Security culture & champions

☺ Like you're 10: One security person can't watch every team, so you train a helper inside each team — and you never punish the person who tells you they made a mistake.

Four questions. At senior and lead level this is often the round that decides the outcome, because it's where the interviewer works out whether hiring you scales or just adds one more reviewer. Covered in security culture & champions, with a real-world example in the Etsy case study.

🟢 9.1 The champions model

Q: What is a security champion, and what problem does the model solve?

A: It solves a ratio problem. A central security team cannot review every pull request, sit in every design meeting, or answer every "is this okay" message across an org running dozens of product teams — the security-engineer-to-developer ratio is commonly cited somewhere in the range of 1:100 to 1:400, and it gets worse as engineering headcount grows faster than security hiring. The champions model closes that gap by designating one embedded, trained advocate per product team rather than by hiring more security engineers.

A champion is a developer who already writes that team's code and sits in that team's standups, and who additionally becomes the local point of contact for security questions, first-pass triage of scan findings, and translating central policy into decisions the team actually understands. They keep their engineering role and spend a bounded slice of time — often quoted around 10–20% — on the champion function, supported by a recurring cross-team sync, a dedicated channel, and a curriculum from the central team covering the org's threat model, tooling, and escalation paths.

What changes for the central team is the job description: from doing all the work to training and supporting the network that does most of it. Both OWASP SAMM and BSIMM name this function explicitly, because the pattern in both models is that maturity correlates less with tool coverage than with how distributed security ownership is across engineering.

🟡 9.2 Avoiding the "no" reputation

Q: Security teams often get a reputation as blockers. Why does that happen, and what would you do about it?

A: It happens because it's a rational response to the incentives. If "talk to security" reliably means a delayed release, a rejected pull request, or a design sent back with no alternative offered, then engineers learn to loop security in as late as possible — precisely when the cost of fixing anything is highest. Teams respond to incentives, and a review that only ever says no is a cost with no visible upside.

The fix isn't lowering the bar; it's shifting where the effort goes. Instead of gatekeeping at the end, the highest-leverage work is making the compliant path the path of least resistance: a golden container base image with scanning and hardening already baked in, a paved-road CI template that wires up SAST and dependency scanning by default, a self-service secrets-manager integration that's genuinely faster to adopt than rolling your own. When the secure option is also the fastest option, adoption stops needing enforcement.

That reframes the function as an enabler that ships guardrails and reference implementations, and reserves an actual "no" for the small minority of cases where it's warranted — a genuine critical vulnerability, a clear policy violation. Which is also what keeps a "no" credible when it does happen. The wider version of this argument is platform engineering for security guardrails: self-service scales further than a review queue ever can, because a review queue's throughput is bounded by headcount and a template's isn't.

🟡 9.3 Blameless response

Q: An engineer tells you they disabled the SAST gate on their branch last night to hit a deadline. How do you handle it?

A: First, thank them for telling me — genuinely, and out loud, because the reporting channel is worth more than this one incident. Then ask the actual question, which isn't "why were you careless" but "why did skipping the gate feel like the only way to hit that deadline?"

That question usually surfaces something systemic: the gate takes twenty minutes on a two-line diff, or it fires on test fixtures every time, or there's no waiver path so bypassing is the only mechanism available. Every one of those is fixable and every one of them will otherwise recur with a different engineer next month. The finding I care about is the friction, not the person.

The reason to be strict about this is that the reporting pipeline is fragile in one direction only. The moment one self-reported mistake results in disciplinary action, reporting for that whole team quietly stops — not just for that person, but for everyone who heard about it — and it rarely reopens on its own. Rebuilding trust after a punitive response takes far longer than the incident took to happen. Both the SRE literature and the DevOps research converge on the same finding for operational incidents: organisations that formally protect reporters get more reports, earlier, which is the entire input a security programme needs.

The boundary worth stating explicitly, because interviewers sometimes probe it: blameless doesn't mean consequence-free for deliberate, malicious, or repeatedly negligent acts, and the policy should say so in writing, so the distinction isn't left to guesswork under pressure. And a reporting record that looks clean because nobody reports anything is not evidence of safety — it's evidence the channel is broken.

🔴 9.4 Measuring culture

Q: How would you know whether security culture is actually improving, rather than just feeling better?

A: I'd insist on trend lines rather than point-in-time numbers, and on pairing every activity metric with an outcome metric, because activity metrics are the ones that always go up.

The metrics I'd actually watch: median time-to-remediate by severity band, which is the single best outcome metric a security programme has, and the one that's zero-value if nobody's fixing anything. Findings still open past their SLA, rather than raw finding count. Self-reported near-misses going up — counter-intuitively a good sign under a blameless model, because it means the channel works. Median time-to-report for a suspicious email getting shorter, which measures whether people know what to do rather than whether they clicked. Phishing simulation click-through rate trending down over successive quarters, not a single pass rate. And how often security is engaged at design time versus at release, which is the most direct measure of whether shift-left is real in this org or aspirational.

What I'd refuse to report unpaired: "we deployed twelve scanners," "95% pipeline coverage," "forty thousand scans this quarter." Those measure what ran, not what got fixed, and a team under pressure to report a good number will optimise the number instead of the outcome it was standing in for. Coverage is a real and useful metric — but only ever next to an outcome metric on the same slide: percentage of repos with SAST enabled beside median days-to-fix for Criticals on those repos.

And I'd sanity-check the numbers against something qualitative, because all of the above can be gamed and none of it captures whether an engineer feels able to say "I think I broke something." Asking that in retrospectives is not rigorous, but it's informative in a way a dashboard isn't.

Domain 10 — Compliance & governance

☺ Like you're 10: Proving to someone else that your controls really work — and doing it with automatic receipts instead of a panic before the audit.

Four questions. How heavily this gets probed depends almost entirely on the employer: near-zero at an early-stage startup, central at a fintech, healthcare, or enterprise-SaaS vendor. It's a fair thing to ask the recruiter about. Covered in compliance & governance and compliance as code at scale.

🟢 10.1 SOC 2 Type I vs Type II

Q: What's the difference between a SOC 2 Type I and a Type II, and which do enterprise buyers ask for?

A: A Type I attests that controls were designed appropriately as of a single date. A Type II attests that those same controls actually operated effectively over an observation window, typically six to twelve months. Enterprise buyers almost always ask for Type II specifically, because a Type I only proves a control existed on paper for one day, not that anyone followed it.

Two adjacent facts worth having ready, because this question usually widens. SOC 2 is an AICPA audit against one or more Trust Services Criteria — Security is mandatory, and Availability, Confidentiality, Processing Integrity, and Privacy are opt-in, so "we're SOC 2 compliant" doesn't tell you which criteria were in scope. And ISO 27001 works differently: it certifies an information security management system — the process by which you identify risks and select controls — on a three-year cycle with annual surveillance audits in between, so it's a standing commitment rather than a one-time project.

As an engineer my job in any of these isn't the legal interpretation — that stays with legal and compliance — it's building and operating the systems that generate evidence an auditor will accept.

🟡 10.2 Compliance as code

Q: What does "compliance as code" mean in practice?

A: It means stopping treating evidence as something a human gathers under deadline pressure and starting to treat it as a byproduct of systems that already run continuously. It's the same idea as policy as code, pointed at a different audience: a rule like "no storage bucket may be public" or "every instance must have encryption at rest enabled" is written once as a machine-checkable policy and then evaluated automatically on every infrastructure change and on a recurring schedule against everything already deployed. Each evaluation produces a timestamped pass/fail record. That record is the evidence — nobody has to remember to take a screenshot.

The contrast is the audit fire drill: weeks of compiling screenshots, exporting access-review spreadsheets, and reconstructing six to twelve months of history to prove controls were followed. That's expensive in engineering time and structurally weak, because a control that silently drifted in month three can go unnoticed until the next audit, if it surfaces at all.

Continuous collection closes the gap at both ends, which is why it's genuinely both more secure and less painful rather than a trade-off between the two. Operationally, the same automated checks that generate evidence also alert in near real time when a control drifts — MFA disabled to debug something gets caught in hours rather than eleven months later. And at audit time you hand over a continuous, timestamped stream of control evaluations to sample rather than a reconstruction from memory. Platforms built for this connect by API to the cloud provider, identity provider, version control, and HR systems, and pull the same category of signal a CSPM already collects.

🟡 10.3 Compliant is not secure

Q: We just passed our SOC 2. Are we secure?

A: No — and I'd say that carefully rather than dismissively, because the certification is real work and worth having.

What a clean report attests is that specific controls existed and were followed during a defined audit period. Auditors sample evidence and test control design and operation; a standard engagement does not include a penetration test against your production stack. So the report is evidence about your process, not a statement about the absence of vulnerabilities in your code. Treating "we passed our audit" as equivalent to "we are secure" is the conflation that produces the most dangerous kind of false confidence, because a team convinced it's covered stops asking the questions a team with no certification is still forced to ask.

The constructive version of the answer: the audit tells you the controls you chose were operating. It doesn't tell you whether they were the right controls, whether the threat model that selected them is current, or whether an attacker could achieve their goal without violating any of them. So I'd pair the compliance programme with the actual security work — threat modeling, scanning with real remediation, and offensive testing — rather than treating one as a substitute for the other.

🔴 10.4 One control, many frameworks

Q: We need SOC 2, ISO 27001, and PCI DSS. How do you avoid building three separate programmes?

A: By building the control once, in code, and maintaining a mapping from that one control to every framework requirement it satisfies. A single "MFA is enforced for all privileged access" check can serve as evidence for a SOC 2 criterion, an ISO 27001 Annex A control, and a PCI DSS requirement simultaneously. Building three manual processes for three frameworks is redundant work; building one automated control and mapping it three ways is not.

Concretely, the shape I'd aim for: a control catalogue where each entry has an owner, an implementation (the policy, the pipeline gate, the CSPM rule that enforces it), an evidence source (where the timestamped pass/fail record lands), and a mapping to the framework requirements it covers. When a new framework arrives, most of the work is mapping rather than building, and the gaps that fall out of the mapping are the actual project.

Two things I'd be careful about. First, the mapping is a claim that needs review — "this check satisfies that requirement" is an interpretation, and it belongs with compliance rather than being asserted unilaterally by engineering. Second, frameworks genuinely differ in ways that don't collapse: PCI DSS applies a merchant-level system based on transaction volume that determines whether a self-assessment questionnaire suffices or an on-site assessment is required, and most engineering teams reduce that scope dramatically by keeping cardholder data out of their own systems entirely and tokenising through a processor. HIPAA has no certification to earn at all — there's a Security Rule risk analysis and safeguards you implement and can be audited against, usually after a complaint or a breach. And GDPR carries obligations no control catalogue satisfies by itself, including notifying the relevant supervisory authority within 72 hours of becoming aware of a personal data breach. Scope calls on any of these belong to legal, and saying so is a strength in an interview, not a dodge.

Domain 11 — Secure SDLC

☺ Like you're 10: Each stage of building software gets the safety check that fits what exists at that point — you can't inspect wiring before it's run.

Four questions. This domain is often the interviewer's organising structure for the whole conversation, so knowing the phase map lets you place any question they ask and answer it in context. Covered in the secure SDLC and secure SDLC gates & DSOMM.

🟢 11.1 Abuse cases

Q: What's an abuse case?

A: The adversarial mirror of a user story, written alongside it during requirements. A requirements document built only from user stories describes how the system should behave for a legitimate user and says nothing about how it behaves for an attacker, because nobody wrote that case down. So next to "as a user, I want to reset my password via an emailed link" you write "as an attacker, I want to enumerate valid accounts by comparing the reset endpoint's response times and error text."

The value is that it forces a design decision — a generic response, a constant-time response — before the flow is coded, rather than after a report. It's the cheapest possible security artifact: it costs a sentence and it changes acceptance criteria, which is what makes the requirement traceable through to test.

🟡 11.2 The phase map

Q: Name the security activity that belongs at each phase of the lifecycle.

A: Six phases, each with the check that fits what actually exists at that point:

The caveat I'd add unprompted, because it's what separates a memorised table from an understood one: that isn't six sequential gates on a calendar. A team shipping several times a day isn't spending a week in "requirements" — it's running a scaled-down version of nearly every row on nearly every change, continuously, inside the same pipeline. Reading the SDLC as a waterfall is what turns this table into a once-per-project audit checklist instead of a description of what kind of thinking each phase calls for, however short that phase is.

🟡 11.3 Where penetration testing fits

Q: Why not run a penetration test on every release?

A: Cost and cadence. Manual penetration testing takes days to weeks and is billed at specialist rates, so it doesn't scale to every change — which is exactly why the automated checks exist further left. It gets targeted at high-risk changes instead: a new authentication flow, a payment integration, a service newly exposed to the internet. A common cadence, and the one some compliance regimes require, is annual plus after any significant change to in-scope systems, and plenty of mature programmes apply that pattern even without a mandate driving it.

The more interesting half of the answer is why you still need it at all when you're scanning everything. Automated scanning has a structural blind spot: it finds implementation flaws that match a known pattern. It doesn't find business logic flaws — a workflow that lets a user reach a state they shouldn't — and it doesn't chain low-severity findings into a high-severity path, which is exactly what a human adversary does. A pentest is scoped, time-boxed, and hunting for a goal; a scanner is matching patterns.

Worth distinguishing from the neighbours, since interviewers often follow up: a penetration test hunts for vulnerabilities within a defined scope and reports them; a red team emulates an adversary against a goal and tests detection and response as much as prevention; a purple team runs the same exercise collaboratively with defenders in the room so the output is a written detection rule rather than a PDF. Offensive security for DevSecOps covers where each one earns its keep.

🔴 11.4 Maturity models

Q: SAMM, BSIMM, DSOMM — what's the difference, and would you use one?

A: They answer three different questions, and the mistake is treating them as competing scorecards.

OWASP SAMM is prescriptive: five business functions — Governance, Design, Implementation, Verification, Operations — each broken into practices scored on a maturity scale, used as a self-assessment that produces a roadmap. It tells you what "good" is supposed to look like and what the next level requires. BSIMM is descriptive: built from repeated measurement of real security programmes across many organisations, it reports what those organisations actually do — which activities are common, which are rare — so you can benchmark against real practice rather than an idealised target. OWASP DSOMM, the DevSecOps Maturity Model, is the narrowest and the most immediately usable of the three for an engineer, because it's organised around pipeline activities rather than around an organisational function.

Would I use one? Yes, with two conditions. First, pick one and use it as a conversation structure rather than a score to optimise — the value is in the gap analysis, not the number, and a team that starts optimising its maturity score has recreated the vanity-metric problem in a new format. Second, don't invent your own scorecard, which is the tempting move and the wrong one: a homegrown model has no external calibration, so it drifts toward measuring what you're already good at.

What I'd do with the output is turn the two or three lowest-scoring practices with the highest blast radius into an actual roadmap with owners and dates, and re-assess on a fixed cadence so movement is visible. A maturity assessment that never gets re-run is the same failure mode as a threat model that never gets revisited. The comparison in full is in maturity models: DSOMM, SAMM & BSIMM.

Domain 12 — Security in CI/CD

☺ Like you're 10: The pipeline is the kitchen every meal passes through — if someone gets into it, they don't spoil one plate, they spoil every plate.

Six questions. This is where the role's distinctive expertise lives, and where a candidate with real hands-on experience separates cleanly from one who has read about it. Covered in security in CI/CD and zero trust for pipelines.

🟢 12.1 Why the pipeline is a target

Q: Why is a compromised build system worse than a compromised application server?

A: Because of what it touches and what it's trusted for. A pipeline sits at a uniquely privileged point: read access to source, credentials to pull private dependencies, permission to push images and packages to registries, and often direct deploy access to production. Compromise it and you don't need to find a bug in the application — you inject into the build process itself, and every downstream consumer that pulls the resulting artifact inherits the compromise.

Two properties make it especially damaging. Scale: a vulnerability in one service affects that service; a compromised build step affects every artifact that step touches, every release, every environment. Stealth: because the artifact is produced by a trusted process and often signed by it, it doesn't attract the scrutiny a random third-party download would. The target isn't a server; it's the trust relationship between "this came from our build" and "this is safe to run." The SolarWinds case study is the reference example of that trust being turned into a distribution channel.

🟡 12.2 Pipeline credentials

Q: How should a pipeline authenticate to a cloud account?

A: Ideally with no stored credential at all. The pattern is OIDC federation: the CI platform issues a short-lived, signed identity token describing the workflow — which repository, which branch or environment, which job — and the cloud provider is configured to trust that issuer and exchange the token for temporary credentials scoped to a specific role. Nothing long-lived lives in the CI system, so there's no static key to leak, rotate, or find in a build log.

Three things that matter as much as turning it on. Scope per job, not per pipeline. A pipeline isn't one identity, it's dozens of jobs doing different tasks: the job running unit tests has no legitimate reason to hold credentials that can push to a production registry, and the job building an image has no reason to hold write access to Terraform state. When every job shares one broad credential "for convenience," compromising the weakest job — often the one executing the least-trusted code, like a third-party test dependency — hands an attacker everything every other job could do. Constrain the trust policy tightly. The cloud-side trust condition should pin the specific repository and, where possible, the branch or environment — a policy that trusts an entire CI organisation is a policy that trusts anyone who can create a repository in it. Separate build from deploy, so the job that compiles and tests is not the job holding production deploy credentials.

It's the same principle as short-lived credentials for applications, applied to the identities the pipeline itself uses. Workload identity & pipeline IAM covers the mechanics per cloud, and generalises it to service-to-service identity with SPIFFE and SPIRE.

🟡 12.3 Ephemeral runners

Q: What's the security argument for ephemeral build runners?

A: It bounds how long a compromise can persist. An ephemeral, single-use environment — a fresh container or VM spun up for one job and destroyed immediately after — means an attacker who compromises a build step during execution has nothing to come back to: no persistent runner to plant a backdoor on, no credentials cached on disk for the next job to inherit, no modified build tool waiting to poison the next run.

Long-lived self-hosted runners trade that away for speed or cost and reintroduce exactly the persistence risk ephemeral runners exist to eliminate. A self-hosted runner that isn't rebuilt from a clean image between jobs is one compromised dependency away from silently backdooring every subsequent build it executes — and the compromised dependency doesn't even have to be yours; a malicious postinstall script in a transitive test dependency is enough.

If self-hosted runners are unavoidable — and they often are, for network access to internal resources or for specialised hardware — the mitigations are to rebuild them from an immutable image per job or at minimum per day, isolate them at the network layer so they can only reach what they need, never run untrusted pull-request code on them (the fork-PR case is the classic hole), and treat the runner itself as untrusted infrastructure whose output has to prove itself through signing and provenance rather than through being trusted by location.

🟡 12.4 Branch protection

Q: What does branch protection buy you, and what's the most common way it's misconfigured?

A: It protects what gets into the pipeline. A protected branch requires an approving review before merge, requires the relevant status checks — SAST, dependency scanning, tests — to pass, and blocks force-pushes and direct commits entirely. Without it, a single compromised developer credential or a careless direct push can land unreviewed code straight into the branch every release ships from, bypassing every human check the team believes it has. Code-owner rules narrow it further: changes to the CI configuration itself, or to deployment manifests, can require review from a specific platform or security team rather than any available approver.

The most common misconfiguration is scope: protection is applied to the default branch only, leaving release branches and hotfix branches unprotected — which are exactly the branches most likely to receive a rushed, under-reviewed change during an incident. So the audit question is "which branches can produce a production deploy," and every one of those needs the rules, not just main.

Two adjacent gaps worth mentioning: an admin override that exists for emergencies and quietly becomes a routine path, and the CI configuration itself being editable by anyone who can open a pull request — because a pipeline definition that a contributor can modify is a pipeline definition an attacker can modify.

🟡 12.5 Signing commits and artifacts

Q: What does a signed commit actually prove, and where does artifact signing fit?

A: A signed commit, verified against a developer's key, proves the commit was authored by someone holding that key. It matters because git author identity is otherwise self-asserted — anyone can set their configured email to someone else's address, which is precisely why hosting platforms render an "unverified" state on commits claiming an identity with no matching signature.

Artifact signing extends the same guarantee downstream, past the point where any human is looking. Cosign has become the de facto standard for signing container images and other build outputs, and paired with a transparency log it produces a public, tamper-evident record of what was signed and when rather than a private key check nobody can audit. In-toto attestations go further and record build provenance: which pipeline, which commit, which inputs produced this exact artifact — which is the SLSA provenance requirement made concrete.

What that closes is a specific category of attack: an adversary who compromises a registry or a network path in between can swap the bytes, but they can't forge a valid signature over different bytes without the key. The control only pays off if something actually verifies — a deploy step or an admission controller that checks the signature and the provenance before pulling, pinned to a digest. Signing with no verification step is a ritual.

What they're really checking: whether you know signing and scanning answer different questions. If your answer to "we scan, do we need signing" is "signing is extra scanning," that's a wrong-model signal.

🔴 12.6 Warn vs hard-fail

Q: What makes a policy gate an actual gate?

A: That it hard-fails. A warning is advisory and gets normalised into noise the moment a team is used to seeing it on every build — the classic failure mode is a dashboard full of red that nobody acts on because nothing ever actually stopped shipping. A hard-fail gate makes the pipeline itself enforce the policy: the build cannot produce a deployable artifact until the finding is fixed or an authorised person grants a documented exception. That distinction is also what most compliance frameworks are really checking during an audit — not that a scanner ran, but that its output was capable of stopping a release.

The gate needs three things to survive contact with a real team. A tuned threshold, expressed as code — "no Critical or High CVEs with an available fix in production dependencies," "every image must carry a valid signature from an expected identity," "no verified secret in the diff" — rather than blocking on everything. A readable failure: which rule, which resource, why, a link to a fix guide, a named owner. And a real exception path: explicit, attributed, time-boxed, and expiring loudly. Without the third, people find the workaround — disabling the check for one PR, marking a finding a false positive with no review, splitting the diff so the trigger doesn't fire, or using the emergency admin override as a routine tool. Every one of those trains the org that the gate is an obstacle to defeat rather than a signal to read.

The way I'd summarise the whole domain if asked to: every control here reduces to the same question — if this specific job, credential, or environment is compromised right now, what's the blast radius? Least privilege bounds what it can touch, signing makes tampering detectable after the fact, ephemeral runners bound how long a compromise persists, and hard-fail gates bound whether a compromised or vulnerable build can reach production at all.

Domain 13 — The tooling landscape

☺ Like you're 10: Knowing which specialist checks which layer — and not buying nine tools when three already cover it.

Three questions. This domain is usually a breadth check rather than a depth check: name a tool per category, then go deep on the two or three you actually claim. Covered in the tooling landscape and the per-tool pages under the tool guide.

🟢 13.1 A tool per category

Q: Name the tool categories you'd expect in a mature pipeline and a representative tool for each.

A: Eight categories, each answering a different question:

I'd organise it by function rather than by vendor deliberately, because the market consolidates fast — a product that only scanned dependencies two years ago may now ship secrets scanning and manifest checks in the same CLI. The questions don't change even when the products answering them do.

🟡 13.2 Choosing tools

Q: How do you choose a scanner, and how do you avoid ending up with nine of them?

A: Two rules matter more than which specific product wins a bake-off. First, it has to run inside the pipeline the team already uses, not as a separate portal someone has to remember to check. A finding that surfaces only in a security dashboard three days after merge gets fixed eventually, if at all; the same finding as a required check that blocks merge gets fixed before the code ships, because it's in the path the developer is already on. Second, a scanner nobody trusts gets ignored, and an ignored tool provides zero security value regardless of what it can technically catch — so tuning thresholds and suppressing confirmed false positives with a documented reason isn't optional maintenance, it's the difference between a gate and a formality.

On sprawl: the eight categories are a way to reason about coverage, not eight purchases. Real tools already span several — Trivy alone acts as an SCA scanner, an image scanner, an IaC scanner, and a secrets scanner from one binary. Before adding a ninth tool to close a gap, check whether something already in the pipeline can be pointed at the new surface first, because tool sprawl carries its own maintenance, noise, and triage cost. And overlapping tools multiply duplicate findings unless something dedupes across them, which is the argument for routing everything through one vulnerability-management system of record rather than four consoles.

The evaluation criteria I'd actually apply, in order: does it run in CI in a time budget the team will tolerate; what's its false-positive rate on our codebase, measured on a sample rather than taken from marketing; can its policy be expressed as code and version-controlled; and does it export findings in a form our tracker can ingest.

🔴 13.3 Consolidation and buy-vs-build

Q: A vendor is pitching a single platform to replace four of your tools. How do you evaluate that?

A: The pitch is usually correlation rather than convenience, and that part of it is real. Four separate tools produce four separate consoles, four severity scales, and no way to tell that the exposed workload, the over-permissioned role, the vulnerable package, and the sensitive data are the same attack path. A platform that ingests all four and builds a graph can rank "internet-exposed workload with a known-exploited CVE assuming a role that can read the customer data store" above a thousand isolated Criticals. That prioritisation is the genuine value; consolidating login screens is not.

What I'd probe before believing it: depth per category. A unified platform is rarely best-in-class in every category it absorbs, so the question is whether its weakest module is good enough for the surface that matters most to us. How it collects. Agentless API-based collection is easy to deploy and blind to runtime behaviour; agents see more and cost more operationally. Lock-in. Can policies and findings be exported, or does adopting it mean the control definitions now live in a vendor's UI rather than in our git repository — which would quietly undo the auditability argument for policy as code. And what it doesn't cover: SAST and DAST usually sit outside these platforms, so "replaces four tools" needs checking against which four.

How I'd de-risk it: pilot on a bounded scope — one account, one team — with success criteria written down in advance, chiefly the false-positive rate on our own estate and whether the graph actually surfaces attack paths we hadn't already found by hand. And I'd keep the pipeline-native scanners regardless of the outcome, because a platform that reports on live cloud state doesn't help a developer at pull-request time, which is where the cheapest fixes are. The full comparison is in CNAPP & the unified cloud security stack.

Scenario and design questions

☺ Like you're 10: These are the "how would you build it" questions. There's no single right answer, so what's being marked is how you break the problem down — not what you land on.

Scenario questions are not looking for a canned architecture. They're looking for structure under ambiguity: do you scope the problem before designing, do you name your assumptions, do you make trade-offs explicit and choose rather than listing options, and do you know what you'd measure to find out whether the design worked. Six scenarios below, each with an approach rather than an answer — memorising an architecture for these is exactly the failure mode they're built to detect.

🔴 Scenario 1 — Design a secure pipeline for a new service

Q: We're standing up a new customer-facing service. Design the security controls in its delivery pipeline.

Clarify first: what data does it handle (that sets the regulatory scope and the ASVS level), what's it built in and does it deploy to containers, and are there existing paved-road templates I should be extending rather than inventing next to?

Then walk the pipeline in order, attaching each check where its input exists. Pre-commit: a fast SAST pass and secret scanning on the diff — cheap, local, and easy to bypass, which is why it's a courtesy and not a control. Pull request: branch protection with required review and required status checks; SAST and SCA against the lockfile; secret scanning as a mandatory gate this time; IaC scanning on the plan. Build: multi-stage build to a minimal non-root base image; SBOM generated from the build; the artifact signed with provenance. Post-build: image scan with a severity threshold, gating the push to the registry. Deploy to staging: DAST, plus an authorization-matrix test if there's an API worth the name. Admission: verify the signature and provenance by digest before anything schedules. Runtime: behavioural monitoring, plus continuous posture scanning of the account it lives in, plus registry rescanning of stored images, because a clean scan expires.

Cross-cutting, and this is where candidates differentiate: the pipeline's own identity is OIDC-federated and scoped per job, not one shared credential; runners are ephemeral; every gate returns a readable failure with a waiver path; and the new-rule rollout is report-only first, promoted to blocking once tuned.

Then attack it. This design doesn't stop dependency confusion (registry scoping does), doesn't find business-logic authorization flaws (an explicit test matrix and a pentest do), and doesn't cover changes made outside the pipeline (restricting direct account access does). Say those out loud — naming what your own design misses is the strongest single move available in a design round.

🔴 Scenario 2 — A critical dependency CVE just dropped

Q: A remote-code-execution vulnerability in a widely used library was disclosed an hour ago. Walk me through your first four hours.

The structure is scope, contain, remediate, learn — and the first one is where all the preparation pays off.

Scope (first 30–60 minutes). Which of our artifacts contain the affected component, at which versions? With SBOMs generated at build time and indexed centrally, that's a query returning a precise list in minutes. Without them it's a multi-day manual audit, and I'd say so plainly — including that the real answer to this question was given six months ago when someone did or didn't wire SBOM generation into the build. In parallel: is it on KEV, what does EPSS say, and is the vulnerable path actually reachable in how we use the library, because "present" and "exploitable" aren't the same claim.

Contain (in parallel, not after). Which affected services are internet-reachable, and can we put a compensating control in front of them today — a WAF rule, disabling the specific feature, a network restriction — while patching proceeds? Containment buys time; it doesn't end the incident.

Remediate. Patch in dependency order, internet-facing and highest-privilege first. Watch for the transitive trap: the fix may need to come from an intermediate dependency that hasn't released yet, in which case a temporary override or pin is the honest interim answer, tracked with an expiry so it doesn't become permanent. Verify by rebuilding and re-querying the SBOMs rather than by asking teams whether they patched.

Learn. Two questions in the review: how long did scoping take, and what would make it faster next time? And did anything in our pipeline let the vulnerable version in without flagging it? If the answer to the first is "days," the output of the incident is an SBOM programme, not a patch.

🔴 Scenario 3 — Policy as code across forty repositories

Q: Leadership wants policy-as-code enforcement across forty repos by end of quarter. How do you run that?

The risk here isn't technical, it's adoption — a rollout that turns forty teams against the programme in week two is worse than no rollout, because the second attempt starts from a deficit.

Phase 1 — observe. Run the policy set in report-only mode across all forty repos and collect data for two to three weeks: how many findings per repo, which rules dominate, and — sampled by hand — what the true-positive rate is per rule. This tells you which rules are ready and which need work, and it gives you the numbers to push back on a deadline with evidence rather than opinion.

Phase 2 — tune and pilot. Fix or drop the noisy rules. Pick two or three friendly teams as a pilot, ideally including one with a genuinely awkward codebase so you find the hard cases early rather than late. Write the fix guides during the pilot, because the guide is what makes the deny useful.

Phase 3 — promote in bands. Turn on blocking for the highest-severity, zero-legitimate-exception rules first, everywhere. Leave the rest as warnings. Then promote further rules as their false-positive rate proves out. Publish the promotion schedule in advance so nothing turns hostile overnight.

Phase 4 — make it sustainable. Policies live in a repository with tests and code review; teams can propose changes; there's a waiver path with an owner and an expiry; and there's a dashboard showing waivers about to expire, because waivers are the part that rots.

And manage the deadline honestly. If the numbers say full blocking enforcement across forty repos by quarter-end will produce mass overrides, the professional answer is to renegotiate scope with evidence — "blocking on these six rules everywhere by quarter-end, the remaining twenty as warnings with a promotion schedule" — rather than to hit the letter of a target in a way that destroys the control's credibility.

🟡 Scenario 4 — No SBOMs, three hundred services

Q: We have no software inventory at all. Where do you start?

Start where the data is already free. SBOM generation at build time is close to zero marginal cost if the build is already containerised: a step that emits SPDX or CycloneDX from the built image and stores it alongside the artifact. Retrofitting inventory by scanning three hundred running services afterwards is more work and produces worse data, because a reconstruction is an inference while the build knows what it resolved.

Sequence: (1) add generation to the shared CI template so new builds are covered by default and adoption follows the template rather than a mandate; (2) backfill the highest-risk services — internet-facing and data-handling first — rather than alphabetically; (3) store SBOMs somewhere queryable across all artifacts, because an SBOM sitting next to an artifact nobody can query is a compliance artifact rather than an operational one; (4) prove the value with a drill — pick a real recent CVE and time how long it takes to answer "are we affected," then publish the number.

What to watch for: SBOM quality varies enormously between generators and ecosystems, so validate that what you're producing actually resolves transitive dependencies rather than just direct ones. And be clear internally that an SBOM is an inventory, not an assessment — it becomes useful when something repeatedly re-queries it as vulnerability data changes, which means the storage layer is the project, not the generation step.

🟡 Scenario 5 — A container is behaving oddly in production

Q: Runtime monitoring alerts that a production container just spawned a shell and opened an outbound connection to an unfamiliar address. Go.

Treat it as a possible breach, not an outage, which sets the order of everything that follows. And say the first thing out loud: do not kill the pod.

Contain without destroying evidence. Isolate at the network layer first — a NetworkPolicy or security group change that cuts the workload's egress and lateral reach while leaving it running. Cordon the node so nothing new schedules there. Then capture: snapshot the disk, capture memory if tooling allows, export the container's process list and open connections, and pull the relevant logs to write-once storage before retention rotates them. Hash artifacts at collection and record who took what, when, with which tool.

Scope in parallel. What identity did that workload hold, and what could it reach? Rotate those credentials, assuming compromise. Check whether the same image is running elsewhere — if the entry point was the image rather than the instance, this is a fleet problem, not a pod problem. Pull the image's SBOM and provenance: was it built by our pipeline, is it signed, and does its digest match what we expect?

Then eradicate and recover: rebuild from a known-good image, redeploy, rotate anything the host held, and only then terminate the original workload. And in the review: was the alert good, and would it have fired if the attacker had been quieter? A single behavioural rule catching a noisy attacker is not evidence of detection coverage.

🔴 Scenario 6 — You've inherited a Kubernetes cluster

Q: You've just taken over a production cluster nobody has security-reviewed. What do you do in the first month?

Clarify: managed or self-managed control plane, single or multi-tenant, and is there any policy engine already installed? Those three answers change the plan substantially.

Week one — inventory and the cheap wins. What's running, what's exposed, what's privileged. Run a benchmark scan against the cluster for a baseline. The cheapest high-value findings are usually: workloads running as root or with privileged security contexts, service accounts with cluster-admin, secrets stored as plain manifests, and an API server or dashboard reachable more widely than intended.

Weeks two to three — the four layers, in order of blast radius. Pod-level: apply Pod Security Admission at an appropriate level per namespace — the standards that replaced PodSecurityPolicy, which was removed in Kubernetes 1.25 — starting in audit mode and moving to enforce. Network: move namespaces to default-deny with explicit allow rules, one namespace at a time, because a badly ordered default-deny rollout is an outage. RBAC: find and narrow the over-broad bindings, with cluster-admin as the priority; this is where the biggest gap usually is and where the work is genuinely slow. Admission control: a validating policy engine to enforce what the above can't express — required labels, disallowed registries, image signature verification.

Week four — make it durable. Runtime monitoring so the cluster tells you when something deviates; continuous benchmark re-checks so drift surfaces; and the same policies enforced at pull-request time on the manifests, so the cluster stops being the only place the rules exist.

What I'd cut if I had two weeks instead of four: everything except RBAC narrowing and getting privileged workloads down, because those two bound the blast radius of everything else. The full treatment is in the Kubernetes security deep dive.

Behavioural questions, STAR-shaped

☺ Like you're 10: These are the "tell me about a time when" questions. The trick isn't a clever story — it's telling a real one in an order the listener can follow.

STAR is Situation (briefly — two sentences, enough context to follow), Task (what was specifically yours to do), Action (what you did, in first person singular, with the reasoning), Result (what changed, quantified where you honestly can, plus what you'd do differently). The most common failure is spending 80% of the time on Situation and running out of time before Action — which is exactly the part being marked.

Tell me about a time you disagreed with a developer about a finding

Why they ask: security is a persuasion job. They want to know whether disagreement ends in a shared decision or in an escalation.

Shape: S — a specific finding, a specific pushback ("this is a false positive," "it's not reachable," "we don't have time this sprint"). T — what you owned: deciding whether the finding was real and getting to an outcome that stuck. A — this is the whole answer. Show that you investigated their claim rather than defending yours: did you actually check reachability, did you read the code path, did you reproduce it. Then show how you closed it: either you were right and you explained the exploit path concretely enough that they agreed, or they were right and you closed the finding and tuned the rule so it wouldn't fire on the same pattern again. R — the outcome plus the systemic follow-through: the rule was tuned, the fix guide got written, the same argument didn't happen again next month.

Strongest version: the story where you were wrong. "I pushed hard, they showed me the vulnerable function was never called, I withdrew the finding and added reachability filtering" demonstrates calibration, which is the trait actually being assessed. It also implicitly proves you can be told no, which matters if they're going to trust you with a blocking gate.

Describe a security incident you were involved in

Why they ask: to hear whether you understand the difference between an incident and an outage, and whether you contributed to the fix or just watched.

Shape: S — what the first signal was and how it arrived, kept short and free of unnecessary identifying detail. T — your specific role: were you incident commander, investigator, the person doing containment, the person communicating? Be precise, and don't inflate — "I was one of three people pulling logs" is credible in a way that "I led the response" often isn't. A — the sequence, in order, showing the security-specific judgement: did you preserve evidence before remediating, how did you decide on containment, when did you escalate and to whom. R — resolution, plus what the review changed. Two numbers land well if you have them honestly: time from detection to containment, and what shipped afterwards that would catch it earlier.

If you haven't been in one: say so directly and pivot to the closest real thing — a drill, a game day, a near-miss you handled, or a production outage where you can show the same discipline. Interviewers accept that far better than a vague story that falls apart under one follow-up. This course's incident timeline drill is worth running for exactly this reason.

Care with detail: don't name a current employer's unpatched systems or an unresolved issue. "A payment-adjacent service" is enough context; specifics that would help an attacker are a red flag to a good interviewer, not a sign of candour.

Tell me about a time you had to say no

Why they ask: to find out whether your "no" is reflexive or reasoned, and whether you offer a path forward with it.

Shape: S — the request and the deadline pressure behind it. T — what made it your call. A — show that you quantified the risk in terms the requester cared about rather than asserting a policy, that you looked for a middle path before refusing (a compensating control, a reduced scope, a time-boxed exception with an owner and an expiry), and that you named who would own the risk if you were overruled. R — what happened, including if you were overruled, which is a perfectly good ending as long as the risk was documented and accepted by someone with the authority to accept it.

Strongest version: one where the answer was ultimately "yes, with conditions." That demonstrates you reserve a hard no for cases that warrant it — which is exactly what keeps a no credible when you use one.

Tell me about a mistake you made

Why they ask: to see whether you can be honest about failure, since a security team that can't will not report its own incidents either.

Shape: S and T — short. A — what you did the moment you realised, which is the part being marked: did you tell someone immediately, or did you try to quietly fix it first? R — the outcome plus the systemic change. The best endings aren't "I was more careful afterwards" (that's not a control), they're "we changed the process so the same mistake couldn't be made silently again."

Choose a real one with real consequences. A sanitised non-mistake — "I care too much about security" — reads as evasion and costs you more than the mistake would. A gate you turned on too aggressively that caused a revolt, a finding you dismissed that turned out real, a rollout you sequenced badly: all fine, all more credible than perfection.

Tell me about a time you influenced without authority

Why they ask: because for most of this role you can't mandate anything, and if you could, mandating would be the wrong tool.

Shape: S — a change you needed teams to adopt that you couldn't require. T — the adoption target. A — the actual mechanics of persuasion: did you find a pilot team who'd benefit first, did you make the new path measurably easier than the old one, did you bring evidence rather than an assertion, did you recruit someone respected on the team to champion it? R — adoption numbers if you have them, and — better — whether it stuck after you stopped pushing.

The detail interviewers listen for: whether you reduced someone else's work as part of the ask. "I asked forty teams to add a step" is a harder story than "I gave forty teams a template that removed three steps and added one."

Tell me about prioritising with more findings than capacity

Why they ask: because this is the actual daily condition of the job, and a candidate without a prioritisation model will drown in it.

Shape: S — the volume and the constraint. T — what you had to deliver. A — your prioritisation model, stated explicitly: severity and exploitation likelihood and reachability and exposure, rather than sorting by CVSS. Then the harder half: what you explicitly chose not to do, and how you communicated that choice upward so it was a decision rather than a silent gap. R — what got fixed, and what happened to the deferred items (tracked with owners and dates, or you've described a backlog, not a plan).

Strongest version: one where you found a structural fix that closed a whole class of findings at once, rather than a story about working harder through a queue.

Tell me about something manual you automated

Why they ask: automation is the discipline's core lever, and this question also reveals whether you measure anything.

Shape: S — the manual process and its real cost, in hours or in missed coverage. T — what you set out to change. A — what you built and, importantly, what you deliberately left manual and why, because "automate everything" is not a judgement. R — the before-and-after numbers, plus the maintenance story: who owns it now, and does it still run? An automation nobody maintained for six months is a cautionary tale, and telling it as one is more impressive than pretending otherwise.

Tell me about explaining a technical risk to a non-technical stakeholder

Why they ask: because someone has to translate "over-permissioned IAM role" into a business decision, and it's usually you.

Shape: S — the risk and the audience. T — what decision you needed from them. A — how you framed it: in terms of what could happen to the business rather than what the vulnerability was called, with a plain-language likelihood and a concrete "here's what it would cost us and here's what it costs to fix." Offering two or three options with costs, rather than one demand, is what turns a briefing into a decision. R — the decision they made and what it enabled, including the case where they accepted the risk, which is a legitimate outcome when it's documented and owned.

The trap: avoid making the story about how you simplified it for them. Interviewers hear condescension quickly. Make it about what they needed to decide.

Smart questions to ask them

☺ Like you're 10: At the end they'll ask if you have questions. Good ones tell you whether the job is what the advert says — and they also show you know what matters.

Ask questions whose answers would actually change your decision. Generic questions ("what's the culture like?") produce generic answers. Discipline-specific questions get you real information, and they demonstrate that you know what makes this role good or miserable.

Two to ask the hiring manager rather than the panel: "What does a good first ninety days look like?" and "What's the thing about this team you'd want a candidate to know that isn't in the job description?" The second one gets an unusually honest answer surprisingly often.

The last week before the interview

☺ Like you're 10: A realistic plan for the final week — practising out loud beats re-reading, and sleep beats cramming.

An honest plan, on the assumption you have a normal job during it. The two highest-return activities in the final week are saying answers out loud and writing down your own stories. Re-reading feels productive and transfers least.

Weak on a domain? The lesson links in the topic map go straight to the material each question is drawn from. For rapid recall, use the flashcards and the self-check; for the practical side, the capstone lab track walks a real pipeline from threat model to compliance evidence, which is the best possible preparation for a scenario round. And if a certification is part of your plan, the certifications page compares the three that come up most.