Security is a posture you can measure
Every class before this one added something to Campux's estate — a virtual network, a pipeline with real deploy rights, a container registry, a database an app can reach — and none of them asked how that gets used against you. Class Thirty-One is the class that asks it, twice. There are only two ways an estate this size actually gets hurt: someone reaches something they should not, or something the estate depends on turns out not to deserve the trust it was given. Both are old problems with an old fix — a lock and a lookout — and at cloud scale neither survives as a habit a person remembers to keep up. This class replaces both with mechanisms, and splits cleanly along that line.
Part I, 31a, answers the first question: who can reach what, and for how long. Every dangerous string in the estate — the database password, the signing key, the certificate that expires the week nobody is watching — gets a single hardened home, Key Vault, opened only through a scoped role and a managed identity, so "who can see this" becomes a role assignment you can list rather than a rumour you cannot verify. And every unit of standing power — the service principal that deploys to production, the human who could become Owner at 2am — gets scrutiny that runs on a schedule, because privilege never holds still. It only ever drifts upward, one convenience and one forgotten cleanup at a time, and nothing in the system pushes back against that drift except a checklist somebody actually runs and a grant that expires instead of accumulating.
Part II, 31b, answers the second: how exposed is the estate you have already built, and how much of what it depends on can actually be trusted. "Are we secure?" has no yes, so Defender for Cloud turns the question into one with an answer — a score, built from a checklist of known-good configuration, that rises as real gaps close and that you are allowed to argue with when a recommendation genuinely does not apply. The code and the packages underneath it get four scanners that watch continuously and cost nothing to enable, because the compromises worth losing sleep over arrive far more often through a stranger's dependency than through your own front door. And a handful of ideas — Zero Trust, the fold of posture and runtime detection into one product, policy written as enforced code instead of a wiki page nobody reads — turn all of it from a list of tools into a stance you can defend in a design review.
Moving any of this to Azure does not hand the problem to Microsoft, either. The line of responsibility only relocates depending on the service model: Microsoft holds the datacentre and the hypervisor at every tier, but identity and data stay yours to lock whether the workload sits on a virtual machine, on App Service, or inside a SaaS mailbox you barely configured. Neither half of this class works if that fact gets misread as "the platform handles security" — the vault's door, the audit's four questions, the score, and the four scanners are all built to answer for the layers that were always yours, and no tier of service ever moves those off your desk.
The two halves share one shape worth carrying into both. Every mechanism in this class replaces a habit that depended on a human remembering — remembering not to paste a password into a setting, remembering to revoke an old grant, remembering to check whether a package picked up a new CVE — with something that runs on its own and reports rather than hopes. And every one of them assumes the layer above it will, eventually, fail: the vault assumes an app setting will leak; the audit assumes a role will be over-granted; the scanner assumes a dependency will rot; the score assumes a configuration will drift. Stack enough of those assumptions and the estate survives the failure of any single one — which is the whole idea behind defence in depth, not one wall but several, each catching what the one before it let through.
Read the two halves in the order they are built, because they compound in one direction only. 31a gives the estate its doors and its keys; 31b gives it a way to see how well the doors are actually holding, and what to do about the parts of the estate nobody built a door for at all. A vault nobody can read is not yet a secure estate, and a rising secure score behind credentials nobody has audited in a year is not one either. Campux needed both halves before either one earned its keep — and so will you.
A lock and a lookout, run as mechanisms, not memory.
The track — two parts
The rest of Class Thirty-One is two pages, each a full class in its own right with its own labs, its own drills, and its own case-file work. The first answers who can reach the estate and for how long; the second answers how exposed the estate already is and what it is quietly built on. Take them in order — the second half's posture story leans on the first half's vault and audit to answer its hardest question.
- 31a · Secrets & Identity
- Key Vault behind an Entra-controlled, role-scoped door, read only through a managed identity; the pipeline least-privilege audit that runs on a calendar; and Privileged Identity Management, which makes standing power something you activate and it expires rather than something you hold forever.
- 31b · Posture & Supply Chain
- Defender for Cloud's secure score, made legible and arguable; four scanners watching the code and the packages beneath it; and the language — Zero Trust, CNAPP, policy as code — that turns a product list into a posture story you can tell in an interview.
The one table the whole class is built to fill in
Before the two parts teach each control in full, hold the shape whole. Five threats, five controls, and which half of the class teaches each one — the decision stops being "which security product is impressive" and starts being "which threat is this control actually answering."
| Threat | Control | Taught in | Azure service |
|---|---|---|---|
| A secret committed to source control | A hardened vault, read only through a scoped role, plus push protection at commit time | 31a | Key Vault |
| Standing privilege nobody remembers granting | Privilege that expires — eligible not active, time-boxed activation, recertified on a schedule | 31a | Privileged Identity Management |
| A misconfiguration nobody is watching for | A continuously evaluated posture score, prioritised and arguable | 31b | Defender for Cloud |
| A vulnerable dependency or base image | Four scanners on the supply chain, each finding routed to an owner | 31b | Dependabot & Defender for Containers |
| A misconfigured resource or pod deployed anyway | Policy written as code, enforced at the platform before the resource exists | 31b | Azure Policy & Gatekeeper |
Read down the "taught in" column and the split from §1 becomes concrete: the top two rows are about who holds power and for how long, the bottom three are about how exposed the estate already is. A team that only ever works the bottom three has a rising score and an unaudited pipeline sitting underneath it; a team that only ever works the top two has clean privilege and no idea whether a base image three layers down has a published CVE. The two parts ahead build all five rows by hand.
Where Campux lands, and why
The running client gives the split somewhere to bite. Campux Retail is small enough — forty stores, one storefront, a six-person team — that it needs both halves in full and neither half's hardest edge.
The storefront's security posture, in one page
Every credential the storefront needs now lives in a vault, read by a managed identity holding nothing broader than Secrets User on its own vault — no password has sat in an app setting since the sprint that moved them, and the pipeline that deploys the app answers to the same quarterly audit as every other production identity Campux runs. None of it was free: it took a leaked key, aged the better part of two years before anyone rotated it, to make the case for doing any of this properly. That is the ordinary way this work gets funded — not foresight, but the postmortem of a near miss that landed on the missing guardrails and not on the tired engineer who committed it.
The score that resulted, the week Defender switched on, read forty-three percent — a baseline, not a verdict, and the number that matters is the one that follows it upward each quarter as the identity findings clear and the exemptions get written down with reasons attached rather than waved away. Underneath the score, four scanners now watch every pull request and every push, and the two things they found in Campux's own history — two more forgotten secrets, both rotated — are what proved the exercise was never theoretical to begin with.
What Campux has not needed, at this size, is either half's harder edge: no attack-path graph chaining an exposed VM to customer data, because nothing sits exposed to chain from; no Gatekeeper admission policy on a Kubernetes cluster Campux does not run. The estate's actual soft spot, named the honest way this class teaches you to name it, is the one every estate this size shares — the workflow files that grant the pipeline its power are still the most valuable text in the company, and they get the review to match. Posture is not a finish line here. It is a page the team keeps rewriting as the estate grows into needing the parts it does not need yet.
Which half is this, actually?
A ticket arrives with the tag "security" and nothing else. Before triaging it, you ask the question this hub exists to teach: is this a who-can-reach-it problem, or a how-exposed-are-we problem? A stolen laptop and a service principal with too much reach are Part I, worked with the vault and the audit. A vulnerable package and a public storage account are Part II, worked with the scanners and the score. Naming the half first is what turns a vague alarm into a five-minute fix instead of a week of guessing.
Examination
Four drills, then two situations. These test the judgement the two-part track is built on; the hands and the labs live in 31a and 31b. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored.
B. An estate this size gets hurt in one of two ways — someone reaches something they should not, or something it depends on turns out not to deserve the trust it was given — and the two parts are built one apiece to answer them. 31a's vault, its pipeline audit, and PIM all answer "who can reach what, and for how long." 31b's secure score, its four scanners, and its Zero Trust vocabulary all answer "how exposed are we, and what have we quietly inherited." C and D invent splits neither part actually uses; A confuses this class with Thirty-Two entirely. Naming which half a problem belongs to is the first move in triage, not an academic distinction.
# review: storefront security posture, Q3
1. Storefront DB password lives in Key Vault; the app's
managed identity holds Secrets User on it.
2. Dependabot, secret scanning, and image scanning are
all enabled on the repository.
3. The secure score sits at 91%, so this quarter's
pipeline least-privilege audit was skipped.
4. Production Owner is an eligible PIM role, activated
on demand — not a standing grant.
Line three — the two halves answer different questions, and one rising number cannot stand in for the other's check. The secure score is a Part II measurement: it reads the estate's configuration against a checklist — public access, encryption, patch state. Defender does carry a few identity recommendations — it flags a service principal holding an administrative role at subscription or resource-group scope, and it flags privileged roles held permanently rather than activated on demand. It has no view into the rest of the audit: whether a subject claim now matches pull_request instead of environment:production, whether the GITHUB_TOKEN's permissions crept upward after a "temporary" fix six months ago, or whether anyone reviews the workflow files that grant all of it. A 91-percent score reads as "well configured," which says very little about "well governed." Lines one, two, and four are exactly what each half should look like when it is working. Skipping an audit because an unrelated number looks good is the single most common way an estate's privilege drifts unnoticed.
The vault's split is a feature, the scanners know only what is known, and the two Part I mechanisms are one question asked twice. The two rejects are the cross-halves trap this drill is built to catch. A high score is not a statement about governance. Defender does raise permanent privileged access at subscription and resource-group scope as a recommendation, but the score is a weighted total, not a gate: a subscription can read 95 percent with that very finding still open, and nothing in the score speaks to the audit's remaining questions at all — which runs can become a principal, what the GITHUB_TOKEN can do, who reviews the files that grant it. And an eligible PIM role nobody has activated is the safe state, not a gap — it is what PIM is for — so no posture recommendation raises it as a finding. Confusing "the scanner didn't flag it" with "it isn't a problem" is exactly the mistake this whole class is built to train out of you.
B. The posture story has four legs — where the secrets live, how you know your standing, what watches the code, what bounds the blast radius — and the fourth one is answered entirely by Part I: the quarterly audit subtracting power from pipelines, and PIM subtracting it from people. A, C, and D are all real and all useful, but they answer different legs of the same story — what watches the supply chain, whether the posture would survive an audit, and whether a bad deploy can happen at all. The story only holds together if you can say which half backs which sentence; reciting all four without knowing where each comes from is exactly the product-list answer the interview question is designed to catch.
Name the half first: this is a Part I incident, and the score is nearly irrelevant to it. An 81-percent secure score describes the estate's configuration — public exposure, patch state, encryption — and nothing in it tells you that a live Owner grant is currently in the hands of a stolen device. The single fact that matters in the first minute is in the report itself: this Owner grant is standing, not eligible. That is precisely the failure PIM exists to prevent, and its absence here is the whole incident.
The first hour, in order. Disable the compromised account's sign-in immediately — this alone stops anything active on the laptop from reaching production as that identity. Revoke its refresh tokens and active sessions, because disabling sign-in does not end a session already in progress. Rotate every secret that identity could have read directly — not just ones it definitely used, since you cannot yet tell which — starting with anything in Key Vault it held Secrets User or Officer on. Then check the activation and sign-in logs for anything done under that Owner grant in the hours before the report, because a standing role gives an attacker a much longer runway than an eligible one ever would.
What comes after the hour. The score does eventually matter, just not in the emergency: once the incident is contained, the fix is structural — this Owner grant becomes eligible-only, with a time box and, for a role this powerful, an approver. That is also the postmortem's actual headline: not "a laptop was stolen" but "a laptop being stolen was allowed to matter this much." A high score never substitutes for that fix; it was never designed to.
Credit what the number is actually measuring, so the correction lands as an addition and not a dismissal. Ninety-one percent is a genuinely good number — it means Defender's continuous checklist against known-good configuration is mostly satisfied: encryption on, public access closed off, patching current, identity findings largely cleared. That is real work, and telling a teammate they are wrong to be pleased about it would be both unkind and inaccurate.
Then name precisely what the score was never built to see — most of it Part I territory. Be exact here, because the score is not blind to identity: Defender recommends that privileged roles not be held permanently at subscription and resource-group scope, and it flags service principals carrying administrative roles at those scopes. What it does not do is answer the audit. It does not know whether a workflow's subject claim now matches pull_request instead of environment:production. It does not know what the GITHUB_TOKEN can write, or who reviews the files that grant it. It does not know whether last quarter's pipeline audit actually ran, or slipped because the last review looked fine. And a score is a weighted total, not a gate: a subscription can sit at 91 percent with a standing-Owner finding still open inside it, which is exactly how one stolen laptop hands an attacker the whole estate.
What to check before agreeing. Ask the pipeline audit's questions of people, not just principals: who is eligible for what, is anything standing that should not be, and when did the access review last run. Ask when the quarterly audit last happened and what it found. Only once both halves check out does "the estate is secure" become a claim worth repeating to leadership — and even then, the honest version of that sentence still ends with the residual risk, named.
Five things worth carrying out of this hub
- Two questions, two parts: who can reach the estate and for how long (31a); how exposed it already is and what it depends on (31b). Take them in that order — the second leans on the first.
- Every mechanism in this class replaces a habit that depended on a human remembering with something that runs and reports: a vault instead of good intentions, an audit instead of trust, a score instead of a shrug, a scanner instead of hope.
- A high secure score and a clean pipeline audit are two different claims. Neither one answers the other's question, and the posture story you tell in an interview needs both legs, not one.
- Defence in depth's premise carries the whole class: every layer will eventually fail, so stack enough of them that the failure of any one gets caught by the next.
- The strong answer to "what could an attacker do with a credential from your estate?" is the same shape from either half: less than they could a quarter ago — and the honest version always ends with the residual risk, named.