Start with access, then look for exposure
A virtual network, deployment pipeline, container image, and database can each be configured well or badly. Security is the continuing work of limiting access, finding weaknesses, and responding when something changes. This class has two parts. The first controls who can do what. The second checks what is exposed or vulnerable. Neither part alone proves the system is secure.
Part I, 31a: secrets and identity. A secret is a credential such as a password or API key. Azure Key Vault can store it, while a managed identity lets an Azure workload authenticate without a secret embedded in its code. A scoped role controls which identity can read which vault data. Review deployment and human roles regularly; use time-limited privileged access where appropriate. A vault cannot undo a credential already leaked in Git history: rotate the credential and remove the exposure too.
Part II, 31b: posture and supply chain. Posture means the current configuration and risks of your resources. Defender for Cloud lists recommendations and a secure score based on selected checks. The score helps prioritize work; it cannot certify that the estate is secure. Supply chain means the packages, build tools, and base images your code depends on. Scanners can identify known issues, but coverage and pricing depend on the repository visibility, service plan, and features enabled. Confirm what each scanner actually checks before relying on a green status.
Shared responsibility changes with the service. Microsoft manages more of the underlying system for App Service than for a virtual machine. You still configure access to your resources and protect the data you put in them. Start a review by naming the actual service model and its access boundaries; do not assume that a managed service also manages your users, secrets, and application permissions.
Automation helps: secret scanning warns about a credential pushed to Git, role reviews expose old grants, and posture checks reveal some configuration drift. Each has blind spots. A scanner detects only what it understands; a recommendation does not apply every fix for you; a managed identity still needs the right role. Use several controls, then test that they work together.
Read 31a first to understand identities, vault permissions, and privilege. Then use 31b to interpret findings and decide which weakness to fix first.
A lock and a lookout, run as mechanisms, not memory.
The track — two parts
Use the two pages in order. Each has its own examples and checks. If a term is new, start with 31a's explanation of identities and roles before reading a posture finding in 31b.
- 31a · Secrets & Identity
- Store secrets in Key Vault, let workloads use managed identity, restrict access with roles, and review privileges that should expire.
- 31b · Posture & Supply Chain
- Read Defender for Cloud findings, inspect repository and image risks, and decide which exposure needs action first.
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 | Rotate the exposed credential; move the replacement to a vault; enable repository secret scanning and push protection where available | 31a | Key Vault + GitHub Secret Protection |
| 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 | Review recommendations, confirm the affected resource, and fix or document the exception | 31b | Defender for Cloud |
| A vulnerable dependency or base image | Scan supported packages and images; route a finding to an owner; rebuild and verify the fix | 31b | Dependabot + configured image scanner |
| A misconfigured resource or pod deployed anyway | Apply an appropriate policy at the resource or cluster scope and test its enforcement | 31b | Azure Policy; Gatekeeper with the AKS add-on |
The first two rows deal with credentials and privilege. The remaining rows deal with configuration and software risk. Notice that each control has a verification step: moving a secret is incomplete until the old credential is rotated; enabling a scanner is incomplete until someone owns and fixes its findings.
Where Campux lands, and why
Campux Retail is a fictional case used throughout the course. Treat its numbers as a scenario, then replace them with measurements from your own environment.
The storefront's security posture, in one page
In the case scenario, a storefront workload uses managed identity to read only the secrets it needs from Key Vault. The team rotates an old exposed credential, reviews the workload's vault role, and checks deployment identities on a schedule. Moving a replacement secret into a vault does not make the old leaked value safe.
An illustrative Defender for Cloud secure score of 43% gives the team a starting list of recommendations, not a security grade. They inspect each affected resource, fix the applicable findings, and record justified exceptions. Repository and image scanners have owners who review new findings. The number of scanners or the score alone cannot establish whether this process works.
Campux does not run AKS in this scenario, so a Gatekeeper policy would add no value here. The team instead reviews the deployment workflow and its permissions, because that workflow can change production. Its security plan follows the resources it actually runs and changes when the estate changes.
Which half is this, actually?
A ticket arrives tagged only "security." First identify the affected resource, what could happen, and who owns it. An over-privileged deployment identity points to 31a. A vulnerable package points to 31b. A public storage account may need both an access review and a posture fix. Use the two parts to choose the next investigation step; do not assume the tag itself tells you the severity or the repair.
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.
Options 2, 4, and 5. With Azure RBAC, managing a vault resource and reading a secret are separate permissions. Scanners find issues within their supported rules and available data; silence is not proof of safety. Review both human privilege and deployment identity permissions. The two false statements treat a secure score as a complete audit and treat an eligible, inactive PIM role as a security failure. Check actual findings and assignments instead of inferring them from a score.
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.
Put security into the pipeline rather than after it, and name the controls that matter most.