Designing & Planning Architecture

A case-study question hands you a business in motion (Altostrat streaming media, Cymbal retail, EHR Healthcare, KnightMotives automotive) and asks for the architecture that fits. The reliable move is to turn each sentence of the scenario into a requirement first, then choose the service that satisfies it, never the reverse. Functional requirements say what the system must do; non-functional requirements (an availability target, a latency ceiling, a recovery objective, a residency rule) say how well, and it is the non-functional ones that usually decide the answer. The lens that keeps this honest is the Google Cloud Well-Architected Framework, the reference model the exam expects you to apply, with its six pillars: operational excellence; security, privacy, and compliance; reliability; cost optimization; performance optimization; and sustainability. Every requirement in this domain maps to one of those six pillars, and the classic trap is reaching for a service you recognize before you have stated which requirement, and therefore which pillar, it is meant to serve.

This is the design phase, and it runs as a sequence you can follow top to bottom. You start with Business Requirements, where business goals become functional and non-functional requirements, continuity becomes a recovery time objective (RTO, tolerable downtime) and a recovery point objective (RPO, tolerable data loss), and each workload gets a disposition: build, buy, modify, or deprecate. You then read those needs as Technical Requirements through the six pillars, turning targets into availability, scalability, and disaster-recovery patterns. Next, Network, Storage and Compute Design picks the concrete resources: a global VPC with regional subnets, the lightest compute rung the workload tolerates, and storage matched to how the data is accessed. When existing systems must come along, Migration Planning sequences the move in four phases (assess, plan, deploy, optimize) and assigns each workload a path on the effort-versus-benefit ladder. Finally, Future Improvements treats the launched design as a living thing, using Google's own recommenders to keep tuning it. Read in order, the five subtopics are the through-line of the whole exam: requirements set the targets, the next three steps build to them, and the last step never lets the design stand still.

Scenario questions usually leave two or three options that would technically function, and the architect's instinct is what the exam rewards. First, eliminate any option that violates a hard requirement, a residency rule, a compliance mandate like HIPAA, a stated RTO or RPO, because a design that breaks a non-negotiable is wrong no matter how elegant the rest. Among what survives, prefer the choice the framework favors: the cheapest pattern that still meets the recovery objective, the most-managed compute rung the workload tolerates, the design that scales horizontally rather than by growing one bigger machine. Cost optimization and operational excellence reward not running what a managed service could run for you, so when nothing else separates two answers, the lower operational burden tends to win.