Design and Deploy a Multi-Region Cloud Architecture

Proof required

Submit: an architecture design document (at least 600 words) for the multi-region data architecture including: replication topology diagram, consistency model per data type with justification, conflict resolution approach with an example of a conflict and how it would be resolved, and an ADR for the most significant architectural decision. A senior cloud architect or distributed systems engineer must review and confirm the design is coherent and the consistency model choices are justified.

What gets checked

• Design specifies consistency models per data type — not a single consistency model for the entire system
• Conflict resolution approach includes a concrete example showing how a specific conflict would be resolved
• A senior cloud architect or distributed systems engineer has confirmed the design is coherent

Common mistakes

• Design that selects one consistency model for all data without explaining why different data types might need different models
• Conflict resolution approach that describes the strategy without a concrete conflict example

Resources

What a verifier looks for

• Does the design specify consistency models per data type with justification?
• Does the conflict resolution section include a concrete example of a specific conflict?
• Ask: 'what happens to write availability in your design if the cross-region link fails?' — tests CAP understanding

You'll sign in first, then come straight back here.

Proof required

Submit: a public GitHub repository containing the multi-region proof-of-concept (Docker Compose or cloud infrastructure code); a test script that takes down one region and records recovery time and data loss; and a written failover report (200 words) showing measured recovery time and data loss, with an explanation of what determines each. A senior cloud architect or distributed systems engineer must confirm the implementation demonstrates real failover behaviour.

What gets checked

• Two regions are deployed and the failover script actually takes one down — not a simulated description
• Failover report shows measured recovery time and data loss from a real test — not estimated values
• A senior cloud architect has confirmed the implementation demonstrates real failover behaviour

Common mistakes

• Failover test that only describes what would happen without executing the actual region failure
• Failover report with estimated values rather than measured values from the actual test

Resources

What a verifier looks for

• Did the failover test actually execute a region failure — not describe it?
• Are recovery time and data loss measured values — not estimates?
• Ask: 'what tradeoff did you make in your replication strategy that affected the measured data loss?' — tests understanding of the consistency vs availability tradeoff

You'll sign in first, then come straight back here.

Proof required

Submit: a complete architecture document (at least 800 words) with replication topology, failover runbook, cross-region traffic capacity model, and cost analysis; and a recording or transcript of a design review with a senior cloud architect or distributed systems engineer who challenged at least two design decisions.

What gets checked

• Architecture document includes all four components — replication topology, failover runbook, capacity model, and cost analysis
• Failover runbook is step-by-step and operational — not a high-level description
• A senior cloud architect challenged at least two design decisions in the documented review

Common mistakes

• Failover runbook that describes what happens rather than the specific steps an operator must take
• Cost analysis with estimated costs but no source for the estimates

Resources

What a verifier looks for

• Is the failover runbook step-by-step and operational — not descriptive?
• Does the cost analysis cite a source for the estimates?
• Were at least two design decisions challenged in the documented review?

You'll sign in first, then come straight back here.