Unit 2 Capstone — Design data storage solutions

The capstone is a synthesis exercise: design one production workload whose architecture crosses every topic in Unit 2. 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.

Choose data services from workload shape, consistency, scale, recovery, governance, and operating model—not brand familiarity.

Required topic threads

1. Design data storage solutions for relational data: Match engine compatibility, transaction needs, scale topology, administration, and recovery requirements.
2. Design semi-structured and unstructured data storage: Choose object, file, key-value, document, or analytical storage from access pattern and governance.
3. Design data integration: Separate movement, orchestration, transformation, streaming, and business workflow requirements.

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.