Design Studio — Design solutions for backup and disaster recovery
AZ-305 › Unit 3 › Design solutions for backup and disaster recovery
Design Studio — Design solutions for backup and disaster recovery
This studio turns the topic into an architecture exercise. Produce a recommendation that another engineer could challenge, implement, and validate. There is no credit for a list of Azure products without flows, constraints, failure behaviour, and trade-offs.
Studio brief
- 3
- Design business continuity solutions
- 4
- 45–60 minutes
Client brief
Fabrikam is modernising a production workload in this domain: Map each dependency to a recovery mechanism that can meet tested RTO/RPO and compliance requirements. The workload serves internal teams and external customers, carries regulated data, and must remain supportable by a small platform team. The client has supplied incomplete requirements; part of the exercise is to state assumptions and identify questions that would materially change the recommendation.
The initial requirements are:
- The design must address recover deleted/corrupted data with explicit assumptions and measurable acceptance evidence.
- The design must address fail over machines with explicit assumptions and measurable acceptance evidence.
- The design must address database continuity with explicit assumptions and measurable acceptance evidence.
- The design must address whole-workload recovery with explicit assumptions and measurable acceptance evidence.
- The solution must use Microsoft Entra identities, private connectivity where justified, infrastructure as code, and observable health signals.
- The design must state a recovery path, operational owner, cost driver, and one deliberate compromise.
Candidate decision anchors
| Requirement thread | Candidate starting point | Qualification rule |
|---|---|---|
| Recover deleted/corrupted data | Azure Backup or service-native backups | Design vault, policy, retention, immutability, and restore path |
| Fail over machines | Azure Site Recovery | Replicate, test failover, sequence recovery plans, and design failback |
| Database continuity | Service-native PITR, geo restore, replicas, failover groups | Choose from data-loss and recovery-time targets |
| Whole-workload recovery | Recovery plan and runbook | Sequence identity, network, data, compute, validation, and traffic |
These are starting points, not an answer key. You may select a different service when a stated assumption or constraint justifies it. Every deviation must identify the requirement it serves and the new operational cost it introduces.
Studio workflow
Clarify
Write five questions whose answers could change the architecture. Mark hard constraints separately from preferences.
Required submission
- A one-page architecture diagram with a text equivalent.
- A decision record containing context, decision, alternatives, consequences, and validation evidence.
- A requirement-to-control matrix that maps every hard constraint to a component or operating process.
- A failure table covering component, zone, region, identity, network, and operator-error failures where applicable.
- Three validation tests: one functional, one reliability/security, and one operational or cost test.
Review traps
- Backup and replication solve different failures.
- A recovery plan must include dependencies.
- Untested restore time is not an RTO.
Assessment rubric
| Dimension | 0 — Missing | 1 — Partial | 2 — Release quality |
|---|---|---|---|
| Requirements | Products chosen before constraints | Some constraints mapped | Hard constraints, assumptions, and change-driving questions are explicit |
| Architecture | Component list | Main flow shown | Identity, traffic/data, dependencies, and failure boundaries are coherent |
| Trade-offs | No alternative | Alternative named | Strongest alternative rejected using a stated requirement |
| Operability | Monitoring mentioned | Some runbook detail | Health, capacity, deployment, recovery, ownership, and cost evidence defined |
| Currency | No sources | Secondary/undated source | Current Microsoft primary source linked and reviewed date recorded |
Reflection
- Which requirement eliminated the most attractive alternative?
- Which assumption creates the greatest residual risk?
- What would you test in a pilot before approving production deployment?
- How would the recommendation change if the operations team doubled in size or the recovery objective tightened?
Source and freshness
Grounded in the current AZ-305 skills outline and both attached course sources. Current service contracts must be verified in Microsoft Learn during the studio. Reviewed 2026-08-02.