The brief
A build is not a lab. A lab holds your hand through one concept and tears itself down; a build hands you a client's requirement and walks away. Here is the requirement, phrased the way it arrives at real consultancies: "We are new to Azure. Set up our subscription so that two teams can work without stepping on each other, nothing gets created in the wrong country, every resource has an owner we can bill, and a new hire can understand the arrangement from a document rather than a meeting." Everything in that sentence maps to a class you have already sat. This build is where you prove it.
- Deliverable
- A governed Azure environment — hierarchy, roles, and policies — plus a public GitHub repository containing the README that documents it. The repository is the portfolio artifact; the environment is its evidence.
Work in your own subscription (the free tier suffices — nothing in this build costs more than pennies if you delete promptly). If your subscription cannot create management groups or a second subscription, the brief's spirit survives the substitution the requirements table names: two resource groups standing in for two subscriptions, with everything else unchanged. What matters is not the scale of the estate but that every guardrail in it is deliberate, and that you can say why.1
Requirements — the ledger you build against
Each row names the requirement, the class that taught it, and the evidence a reviewer will look for. Build top to bottom; the order is the dependency order.
| # | Requirement | Taught in | Evidence |
|---|---|---|---|
| R1 | A management group holding the estate, named to a convention you document | Class 7 | Screenshot of the hierarchy; the naming rule written in the README |
| R2 | Two environments — prod and nonprod — as two subscriptions under the group, or two resource groups if your account allows only one subscription | Classes 7–8 | Both visible in the hierarchy; the substitution, if used, stated plainly in the README |
| R3 | An RBAC model: a test user or group holding Contributor on nonprod and Reader on prod, granted at the right scope — and nobody but you holding Owner | Class 8 | The role-assignment list at each scope; one README paragraph on why the scopes were chosen |
| R4 | An allowed-locations policy with a deny effect, assigned once at the management group and inherited downward | Class 8 | A screenshot of a create being refused in a disallowed region — the policy caught in the act |
| R5 | A required-tags policy for owner, env, and cost-center on resource groups | Classes 7–8 | A refused untagged create, and one compliant resource group showing all three tags |
| R6 | A machine identity: one user-assigned managed identity in nonprod, holding one narrow data-plane role — and no service principal with a client secret anywhere | Class 9 | The identity's role assignment; a README sentence on why there is no secret to rotate |
| R7 | The README: what this estate is, the naming convention, the RBAC table, both policies with their reasons, and how a new hire would request access | Classes 7–9 | The repository itself — this is the artifact an interviewer actually reads |
Evidence, not effort, is the deliverable.
Two boundaries keep the build honest. Do not over-build: no VNets, no compute, no pipelines — those are later phases, and adding them here buries the governance story this build exists to tell. Do not under-document: a perfect estate with an empty README scores lower on the rubric than a modest estate whose README explains every choice, because the README is the half a stranger can verify.
The rubric — how a reviewer marks it
Mark yourself before anyone else does. The bands are deliberately blunt, because reviewers are.
- Functional — the floor
- All seven rows exist and the two policies demonstrably refuse what they should. This is a passing build: real, inspectable, honest. Most first attempts land here, and it is a fine place to land.
- Reasoned — the target
- Functional, plus the README defends each decision: why the policy sits at the management group and not the subscription, why Contributor stops at nonprod, why the identity carries no secret. The difference between "I followed the steps" and "I made the choices."
- Professional — the ceiling
- Reasoned, plus the estate would survive a stranger: naming is consistent everywhere, the README's access-request section could actually be followed, and a deliberate mistake test — you try to break your own rules and record what stopped you — appears in the evidence. This is the version you walk an interviewer through.
One deduction applies at every band, and it is the Class Eight lesson in rubric form: any standing Owner assignment beyond your own account caps the build at Functional, whatever else is polished. Governance that leaks its highest privilege has failed at the one job the word names.
What an interviewer will ask
These are the questions this artifact provokes in a real interview, in roughly the order they arrive. Rehearse the answers aloud — the build is only half done until you can narrate it.
- "Walk me through it."
- Sixty seconds, top of the hierarchy downward: the group, the two environments, who can act where, what may exist at all. If your walkthrough follows the README's structure, that is the README doing its job in the room.
- "Why does the policy live at the management group?"
- Because rules set high inherit down — set it per subscription and the next subscription is born ungoverned. This is the scope-inheritance answer from Class 7, and interviewers use it to separate reading from understanding.
- "What stops a developer reaching production?"
- The wall is structural, not behavioural: their Contributor grant ends at nonprod's scope. Bonus marks for naming what does not stop them — social engineering of whoever holds Owner — because knowing a control's limits reads as seniority.
- "Why no service principal secret?"
- The Class 9 ladder, compressed: a stored secret is a leak with a delay, and inside Azure a managed identity removes the credential entirely. If they follow up with "and outside Azure?", the word they are listening for is federation.
- "What would you add next?"
- The honest answer is the curriculum's: a network (Build II), delivery automation (Build III), and eyes on it all (Build IV). Naming what is deliberately absent proves the scope was chosen, not stumbled into.
The estate you already watched being born
Everything in the ledger happened to Campux across three classes: the tenant laid out in Class Seven, the roles and the two policies in Class Eight, the machine identity in Class Nine. The difference is authorship. Campux's estate was built in prose, and prose cannot be inspected; yours will exist, refuse a mis-region resource at the API, and sit in a repository with your name on the commits. When Class Twenty's case file says "the Build I governance that was clicked into place now has a written form," this artifact is what it is talking about — and when you reach that class, converting your own clicked estate to Bicep will land harder than converting a fictional one ever could.
- Free and student subscriptions differ in what they permit — some cannot create management groups without elevation, and most hold a single subscription. Every substitution the requirements allow keeps the graded skills intact: scope, inheritance, least privilege, and enforcement are identical mechanics at resource-group scale. State the substitution in the README; hiding a constraint reads worse than working within one. ↩