The Miniature Landing Zone

Plate I focused on one application. This project looks at some of the shared rules and services that can support several applications. You will create a small example with scoped policies, a shared network pattern, central logging, and written access rules. It helps you practice platform-engineering ideas; it is not a complete cloud foundation for a real company.

Microsoft's Azure landing zone guidance describes how to prepare Azure for an organisation's applications. This project borrows selected ideas from that guidance, at a much smaller scale. It does not implement every design area or replace Microsoft's full architecture.¹

Azure organises resources into scopes. From higher to lower, these are management groups, subscriptions, resource groups, and resources. A tenant has a root management group, with any groups you create beneath it. The example diagram shows a possible Platform group and Landing Zones group. Some policies and access roles can inherit from a parent scope to its children, subject to their settings and exclusions. If these terms are new, start with Class 7 — Entra ID, Subscriptions & Resource Groups, then read Management groups, explained.

A few terms before the checklist

Policy

A rule Azure checks against resources. Audit reports a mismatch; Deny can block a matching deployment.

Hub & spoke

A shared network (the hub) connected to one or more workload networks (the spokes). Peering connects them, but does not automatically configure every route or firewall rule.

Private DNS

A name lookup that lets a connected network find a private service address without using its public address.

Log Analytics

An Azure workspace that collects supported logs so you can search and review them later.

Deliverable

A project folder or repository with the templates you completed and a README. The README should describe what you deployed, what you tested, what is represented only in a diagram, and which full-scale landing-zone features are outside this exercise. Share publicly only after removing secrets, credentials, and personal information.

Use this checklist to plan your work. Build only in the dedicated test environment described above. If account permissions prevent one step, write down the limit and complete the safe alternative in Note 2.

Write down the rule. Test where it applies.

Keep the scope honest. Full enterprise landing zones can include separate subscriptions for shared platform services, additional network security, identity controls, policy, and operational processes. This project covers selected ideas only. Use the README to list what you built, what you simulated, and what you left out; a diagram should not imply that an unbuilt control is active.

Use the Well-Architected Framework as a set of review questions, not a score awarded by Microsoft or an employer. For each relevant pillar, describe one choice and one limit of your small exercise.

Operational excellenceWAF review prompt

Can another learner follow your deployment steps? Note which parts are automated and which still need a person.

SecurityWAF review prompt

Do your policy and access examples have a defined scope? Show the test and say what it does not protect.

ReliabilityWAF review prompt

What happens if a shared network or logging resource is unavailable? Separate your design expectation from any failure test you actually ran.

Cost optimisationWAF review prompt

Which networking and logging resources may create charges? Check current prices, clean up the test resources, and review Cost Management.

Performance efficiencyWAF review prompt

Did you measure traffic or test capacity? If not, describe scale as an open question rather than a demonstrated result.

Do not describe a policy as enforced until you have checked its assigned scope and effect and tested it in the isolated environment. An audit policy reports; a deny policy can block a deployment. Both can be useful, but they do different jobs.

Use these questions to explain your decisions. Answer from what you deployed and checked; label proposed or simulated parts clearly.

"Why put rules on a parent scope?"

A parent assignment can apply to child scopes, which can reduce repeated setup. Show the exact scope and any exclusions in your diagram; inheritance depends on the assignment and its settings.

"What does your management-group diagram show?"

Describe the scopes you actually created. If you drew a Platform and Landing Zones group but did not deploy them, call them a proposed design rather than live Azure resources.

"When would you use Deny instead of Audit?"

Audit reports matching resources without blocking them. Deny blocks matching create or update requests. Test a Deny policy in the isolated project scope before relying on it, because it can also block your own deployment.

"How would a new workload receive the rules and logs?"

Explain which policies and role assignments apply at its scope. A DeployIfNotExists policy may deploy a related setting after evaluation, but it needs an assignment identity with the right permissions; existing resources may need a remediation task. Do not promise immediate logging unless you verified the setup.

"What did you leave out?"

Use your README to name the enterprise features this exercise does not build, such as separate platform subscriptions, broader security operations, or high-availability controls. Say which of those matter for the scenario you are discussing.