Design Lab — Put each control at the scope that owns it
AZ-305 › Unit 1 › Design governance
Design Lab — Put each control at the scope that owns it
Lab brief
- 1 — Identity, governance, monitoring
- 25–30%
- 20 minutes
- $0 — no subscription needed
- Foundational
Governance questions are scope questions. Azure gives you a hierarchy — management groups, subscriptions, resource groups, resources — and almost every wrong answer applies the right control at the wrong level: a policy per subscription that should have been assigned once, or a tag asked to do a job tags cannot do.
Read the brief, commit before you reveal, then check.
The brief
Contoso Manufacturing — landing zone review
Forty subscriptions today, growing by roughly ten a year as business units onboard. Two regulatory groups: EU-only workloads and everything else. Three environments per unit: prod, non-prod, sandbox.
Commit before you reveal
▶What this lab is really testing — open after committing
Not whether you know what a management group is. Whether you place a control where inheritance does the work for you — including for resources that do not exist yet. The engineer in this brief made the classic error, and the giveaway is that their design has a checklist step at all.
Question 1 — the rule that must reach the future
The EU region restriction must apply to every EU subscription, including ones onboarded next year, with no manual step. Where should the policy be assigned?
Question 2 — the shape of the hierarchy
The team wants to know whether their hierarchy can survive doubling. Which statements are true? Select all that apply.
Select all that apply
Question 3 — access nobody can override
The break-glass requirement says a specific action must be blocked for everyone, including subscription Owners. What mechanism does that?
Question 4 — the order that removes the checklist
Order the governance method so that controls are inherited rather than repeated.
Put the steps in order
- 1Assign policy and access at the highest scope that is still correct
- 2Choose the ONE axis the hierarchy will express, since each child has a single parent
- 3Use tags for cost reporting and search — never as the grouping a control depends on
- 4Identify the boundaries that must never be crossed: regulatory, then environment
Why the runner-up loses
Four ways to group things, and what each can actually enforce
| Attribute | Recommended | |||
|---|---|---|---|---|
| Carries inherited policy and RBAC | Yes — to every descendant | Yes — within itself | Yes — within itself | No |
| Applies to things created later | Yes, including new subscriptions | Only inside that subscription | Only inside that group | Only if someone tags them |
| Structural limit | per directory, six levels deep | One parent only | One subscription, one region record | Applied to resources individually |
| Best used for | Regulatory and environment boundaries | Billing and hard isolation | Lifecycle — deploy and delete together | Cost reporting and search |
| Failure mode | Choosing the wrong single axis | Policy repeated per subscription | Controls too low to inherit | Treated as a grouping it cannot be |
The row that decides most questions is the second. A control at a management group governs subscriptions that do not exist yet; every other scope governs only what is already there. Whenever a requirement mentions growth, onboarding, or "all future", it has told you the scope.
The shape of the answer
The traps that catch people
The method, for any question of this shape
How to attack a governance question in 90 seconds
Look for the word 'future'
'New subscriptions', 'as we onboard', 'all existing and future' — every one of these means management-group scope, because only inheritance reaches what does not exist yet.
Before you move on
Come back cold after the Unit 1 lessons. If you can explain why the engineer's forty assignments were wrong without using the word "tedious" — the real reason is the unprotected window before the rule arrives — the pattern has transferred.