Cloud Service Design and Transition
Domain 3 tests design of cloud services and their safe transition into live use.
Core rules
- Start from outcomes and nonfunctional requirements: availability, performance, security, compliance, recoverability, observability, and cost.
- A service design package should cover SLAs, OLAs, underpinning contracts, architecture, data flows, support model, and acceptance criteria.
- Design for failure: redundancy across zones or regions, graceful degradation, backup and restore, and tested RTO/RPO.
- Transition includes planning, build, test, release, deployment, validation, and handover. Migration is a transition, not a one-off copy.
- Change, configuration, and knowledge management must be updated before go-live; otherwise operations inherits hidden risk.
Worked example
An order service must meet RTO 1 hour and RPO 15 minutes. Design uses synchronous replication across two availability zones and point-in-time recovery for the database. A failover test measures 38 minutes to restore service and 9 minutes of data loss. It passes, but only after the runbook and monitoring alerts are validated. Reasoning: the acceptance test must prove the stated objectives, not just show that resources exist.
Traps
Designing only functional features; skipping nonproduction parity; assuming multi-zone equals backup; treating provider SLAs as your customer SLA; migrating without rollback; and handing over without updated CMDB entries and runbooks.