Unit 1 Capstone — Design identity, governance, and monitoring solutions

The capstone is a synthesis exercise: design one production workload whose architecture crosses every topic in Unit 1. Your submission should read like a lightweight architecture review package, not an exam answer.

Scenario

Contoso is moving a revenue-generating service onto Azure. It operates across two business regions, processes confidential customer data, has a small central platform team, and must demonstrate recoverability to auditors. Traffic and data volume are expected to grow, but finance requires a design that can start economically. The organisation wants a decision package it can use for a proof of concept and production readiness review.

Turn organisational boundaries, duties, and evidence requirements into an operable control model.

Required topic threads

1. Design solutions for logging and monitoring: Design the signal path from collection to retention, query, alert, and automated response.
2. Design authentication and authorization solutions: Separate who signs in, what they may do, how privilege activates, and how workloads obtain tokens.
3. Design governance: Place boundaries, policy, cost ownership, compliance evidence, and privileged access at the right scope.

The client also requires least-privilege workload identity, private administration paths, infrastructure as code, measurable service objectives, cost allocation, and an exit or migration strategy for any service on a retirement path.

Starting comparison

Deliverables

1. Context and requirements: business goals, measurable non-functional requirements, assumptions, exclusions, and five open questions.
2. Architecture: one system-context diagram and one deployment/data-flow diagram, each with a text equivalent.
3. Decision records: at least one ADR per topic, including alternatives and consequences.
4. Security and governance: identities, permissions, network boundaries, policy, secrets, audit evidence, and data residency.
5. Reliability: dependency inventory, availability calculation assumptions, RTO/RPO allocation, backup/failover/failback, and a test schedule.
6. Operations: deployment strategy, telemetry, alerts with owners, capacity signals, patching/upgrades, and runbook entry points.
7. Economics: primary cost drivers, scaling assumptions, commitment risks, and a method for validating current prices.
8. Pilot plan: success criteria, failure injection, security tests, performance evidence, and a stop/go decision.

Text equivalent: requirements drive the architecture; security, continuity, and operations qualify it; pilot evidence determines the production decision.

Review rubric

Score each dimension from 0 to 3: requirements traceability, cross-topic coherence, least privilege, failure coverage, data semantics, network/DNS completeness, deployability, observability, recovery evidence, cost reasoning, current sources, and clarity. A passing capstone has no zero, no unowned critical risk, and at least 28 of 36 points. A high total cannot compensate for a missing recovery owner or an unsupported product assumption.

Learner self-check

• Can another engineer implement the design without inventing its key decisions?
• Does every critical dependency have a health signal and recovery owner?
• Are current limits, availability, and retirement milestones cited from Microsoft primary sources?
• Does the proof of concept test the riskiest assumption rather than the easiest happy path?
• Can I explain how this design changes if scale, recovery, regulation, or team capability changes?

Source and freshness

Aligned to the current AZ-305 blueprint and grounded in both attached course sources. Current product contracts must be cited during the exercise. Reviewed 2026-08-02.