Business Requirements
From business goal to requirement to service
EHR Healthcare tells you "clinicians must reach patient records during a regional outage." That single sentence is the whole job of this subtopic: turn it into requirements you can architect against. It splits into a functional requirement (the records API returns a patient chart) and several non-functional requirements (it stays available through the loss of one region, it answers within a latency budget, it never loses a committed write). Functional requirements describe what the system does; non-functional requirements describe how well it must do it, and on the Professional Cloud Architect[1] exam the non-functional requirement is almost always the thing the question turns on.
Read the case study for the requirement, not the feature
The exam case studies (Altostrat Media, Cymbal Retail, EHR Healthcare, KnightMotives Automotive) bury the real requirement inside a business narrative. A stem may describe a feature ("a global storefront") when the testable constraint is a non-functional one ("single-digit-millisecond reads in every region with strong consistency"). The correct Google Cloud service follows from that constraint: strong global consistency at scale points to Spanner[2], not to a regional database that merely also serves a storefront. Train yourself to underline the numbers and the must/never clauses, because those are the requirements; the prose around them is context.
Non-functional requirements are the architecture drivers
Every major architectural choice traces back to a non-functional requirement: availability and recovery targets drive the redundancy topology, throughput and latency drive compute and storage selection, and regulatory rules drive where data may live and who may touch it. The Google Cloud Well-Architected Framework[3] organizes these concerns into six pillars, operational excellence; security, privacy, and compliance; reliability; cost optimization; performance optimization; and sustainability, and the framework is named in the exam guide as a key requirement for the role. Mapping each business goal onto the pillar it stresses is a fast way to surface the non-functional requirements you might otherwise miss.
Continuity: turn 'we can't lose orders' into RTO and RPO
A business continuity plan reduces to two numbers, and the design follows the tighter of the two. Define them precisely. RTO (recovery time objective) is the maximum acceptable length of time that your application can be offline; RPO (recovery point objective) is the maximum acceptable length of time during which data might be lost from your application due to a major incident, as Google's disaster-recovery planning guide[4] defines them. RTO is about downtime, RPO is about data loss, and they are independent: a system can tolerate hours of downtime (loose RTO) yet zero data loss (tight RPO), which is a common point of confusion the exam exploits.
The number sets the cost
Google states the rule directly: "the smaller your RTO and RPO values are... the more your application will cost to run." That is the lever for every continuity question. A relaxed target is satisfied by the cold pattern (resources are provisioned only on disaster, recovery is slow and cheap); a moderate target by the warm pattern (a scaled-down standby is already running and is scaled up on failover); a near-zero target by the hot pattern (a fully running second deployment serves immediately). The planning guide frames exactly these three. Do not over-engineer: matching a hot, multi-region active-active design to a workload whose business owners accept a few hours of downtime spends money the business never asked for.
Map the disposition to the target
The practical move on a case study is to read the stated tolerance, place it on the cold/warm/hot scale, and name the architecture that fits. A nightly analytics job that can rerun tomorrow takes cold backup-and-restore. A regional storefront that can lose a few minutes of orders takes a warm standby in a second region. A payment ledger that must never lose a committed transaction takes a hot configuration with synchronous replication. The art is reading which tier the business actually requires, then resisting the urge to upgrade everything to the strictest one.
Cost, disposition, and success measurement
Cost is a first-class requirement, and the cloud changes its shape: most cloud spend is OpEx (you pay as resources are consumed) rather than the up-front CapEx of buying hardware, so the comparison you put in front of a business owner is total cost of ownership over time, not a sticker price. The Well-Architected Framework's cost optimization pillar[5] is built on four principles: align cloud spending with business value, foster a culture of cost awareness, optimize resource usage, and optimize continuously. "Align spending with business value" is the one the exam leans on: a cheaper option that misses a non-functional requirement is not the cost-optimal choice, because it fails the requirement it was meant to satisfy.
Workload disposition: build, buy, modify, deprecate
For each existing system, choose a disposition. Build a cloud-native service only when no managed option meets the functional requirement. Buy a managed service or SaaS when one already meets it, because that offloads the operational work an architect would otherwise have to design and staff. Modify (refactor or containerize) an application that has business value but does not fit the cloud as-is. Deprecate a capability the business no longer needs, which is the cheapest outcome of all. The default lean is toward buy and modify over build; net-new custom code is justified by a requirement no managed product satisfies, not by preference.
Define the KPI before you launch
An architecture is judged against success measurements the business already tracks: key performance indicators (KPIs) such as conversion rate, cost per transaction, or p99 latency, and return on investment (ROI). Agree the KPI and capture its baseline before launch, otherwise there is no way to prove the design delivered value, and design in observability from the start so the KPI signals are actually collected. A solution that meets its functional spec but reports no agreed metric tends to lose its budget at the next review.
Integration, data movement, and the exam pattern
A solution rarely lives alone, so two more business requirements shape it early: how it integrates with external systems, and how data moves. Name the integration pattern explicitly. A synchronous request/response over an API suits a low-latency, immediately-needed answer and is governed with an API management layer such as Apigee[6]; asynchronous messaging decouples a fast producer from slower consumers and absorbs spikes, which is the job of Pub/Sub[7]; a scheduled batch transfer fits large, periodic, latency-tolerant data loads. The pattern you pick is itself a requirement that constrains the network, the messaging service, and the storage choice downstream, so deciding it during requirements analysis, not during build, avoids an expensive rework.
Movement of data
Data-movement requirements (volume, frequency, one-time versus ongoing, on-premises source versus cloud-native) feed directly into later subtopics: a one-time bulk ingest of petabytes is a transfer-appliance decision, while an ongoing low-latency event stream is a Pub/Sub-to-Dataflow pipeline. At the requirements stage your job is to surface the volume and the latency tolerance so those downstream choices are made against a real constraint rather than a guess.
What the question stem looks like
The recognizable shape is a case-study paragraph that states a business outcome and a constraint, then asks for the option that best meets the requirements. The right answer satisfies the binding non-functional requirement (the availability target, the data-residency rule, the latency ceiling) at acceptable cost; the wrong answers usually each break one requirement: one is cheaper but misses the RTO, one is technically elegant but violates a compliance rule, one over-provisions for a need the business never stated. Work the requirements first, eliminate any option that breaks a hard one, then choose the cheapest survivor. "Cheapest that still meets every stated requirement" is the through-line of this domain.
Workload disposition: build / buy / modify / deprecate
| Decision axis | Build (cloud-native) | Buy (managed / SaaS) | Modify (refactor) | Deprecate |
|---|---|---|---|---|
| When to choose | No managed option meets the functional requirement | A managed service or SaaS already meets the requirement | Existing app has value but does not fit the cloud as-is | The business no longer needs the capability |
| Operational load on you | Highest: you design, run, and staff it | Lowest: provider runs the platform | Medium: you re-architect once, then run it | None after retirement |
| Time to value | Slowest | Fastest | Medium | Immediate cost saving |
| Typical Google Cloud fit | Custom service on GKE or Cloud Run | Cloud SQL, BigQuery, Pub/Sub, Workspace | Containerize and move to Cloud Run / GKE | Turn off; redirect users to a replacement |
Decision tree
Sharp facts the exam loves — give these one last read before exam day.
Cheat sheet
Sharp facts the exam loves — scan these before test day.
- Split every business goal into a functional and a non-functional requirement
A business goal becomes architectable only when you separate what the system must do (the functional requirement) from how well it must do it (the non-functional requirements: availability, latency, recovery, compliance). The non-functional requirement is what drives the service choice, so on a case study the binding constraint is usually a non-functional one even when the stem leads with a feature. Name it first, then the right Google Cloud product follows from it.
Trap Picking the service from the stated feature instead of the non-functional constraint; a global storefront that needs strong global consistency is a Spanner question, not just any regional database that also serves storefronts.
- Read the exam case study for the requirement, not the surface feature
Altostrat, Cymbal, EHR Healthcare, and KnightMotives stems wrap the testable constraint in a business narrative. Underline the numbers and the must/never clauses, because those are the requirements; the surrounding prose is context. The correct answer is the one that satisfies the binding constraint, so extracting it is the first move on any case-study question.
- The tighter the RTO and RPO, the more the architecture costs
Recovery targets set the cost: Google states that the smaller the RTO and RPO, the more the application costs to run, because faster recovery needs warmer, more-replicated infrastructure. Use the stated tolerance to pick the cheapest pattern that still meets it, and resist gold-plating a workload to a stricter tier than the business asked for.
Trap Defaulting every workload to a hot, multi-region active design; a workload whose owners accept a few hours of downtime is over-provisioned and over-billed by that choice.
- Choose a disposition per workload: build, buy, modify, or deprecate
Each existing system gets a disposition. Build a cloud-native service only when no managed option meets the functional requirement; buy a managed service or SaaS when one already does, because it offloads operational work; modify (refactor or containerize) an app that has value but does not fit as-is; deprecate a capability the business no longer needs, which is the cheapest outcome. The default lean is buy and modify over build.
Trap Reaching for a custom build when a managed service already meets the requirement; building adds the run-and-staff burden a buy decision avoids and is justified only when no managed product fits.
- Prefer buying a managed service to cut operational load
A managed or SaaS service that meets the requirement carries the lowest operational load, because Google runs the platform while you run only your data and configuration. That offload is itself a design goal: it frees the team you would otherwise have to staff to operate a self-built equivalent. Build custom only when the functional requirement has no managed answer.
- Deprecating an unneeded capability is the cheapest disposition
Before deciding how to move a workload, ask whether the business still needs it at all. Retiring a capability nobody uses removes its entire run cost immediately, which beats any migration of it. Disposition analysis starts with the still-needed question, not with how to rehost.
- Cloud spend is mostly OpEx, so compare on total cost of ownership
Most cloud resources are billed as OpEx (you pay as you consume) rather than the up-front CapEx of buying hardware. The decision-grade comparison you put to a business owner is therefore total cost of ownership over time, not a one-time sticker price. This shift is what lets a pay-as-you-go option beat owned hardware once utilization and lifecycle are counted.
- The cost-optimization pillar's first principle is align spend with business value
Google's cost optimization pillar rests on four principles: align cloud spending with business value, foster a culture of cost awareness, optimize resource usage, and optimize continuously. "Align spending with business value" is the exam's favourite: a cheaper option that misses a non-functional requirement is not cost-optimal, because it fails the requirement it existed to satisfy. Cost-optimal means cheapest among the options that actually meet the requirements.
Trap Picking the lowest-price option that breaks a stated requirement; cost optimization means cheapest that still meets every requirement, not cheapest overall.
- The Well-Architected Framework has exactly six pillars
The Google Cloud Well-Architected Framework defines six pillars: operational excellence; security, privacy, and compliance; reliability; cost optimization; performance optimization; and sustainability. The exam guide names familiarity with this framework as a key requirement for the role, so mapping each business goal to the pillar it stresses surfaces the non-functional requirements behind it.
Trap Counting five pillars or dropping sustainability; sustainability is a full, named pillar of the framework alongside the other five.
- Agree the KPI and its baseline before launch, and instrument for it
An architecture is judged against success measurements the business already tracks, such as key performance indicators (conversion rate, cost per transaction, p99 latency) and return on investment. Define the KPI and capture its baseline before launch so there is a measurable target, and design observability in from the start so the signal is actually collected. A solution that meets its functional spec but reports no agreed metric cannot prove value.
Trap Bolting on metrics after launch with no pre-launch baseline; without the baseline you cannot show the change a KPI is supposed to measure.
- Name the integration pattern: synchronous API, async messaging, or batch
How a solution exchanges data with external systems is a requirement that constrains the network, messaging, and storage choices downstream, so decide it during requirements analysis. A synchronous request/response API suits an immediately-needed answer and is governed with an API management layer such as Apigee; asynchronous messaging with Pub/Sub decouples a fast producer from slower consumers and absorbs spikes; a scheduled batch transfer fits large, periodic, latency-tolerant loads.
Trap Reaching for a synchronous API to connect a fast producer to a slow or bursty consumer; that couples their rates, so asynchronous messaging is the pattern that absorbs the spike.
- Surface data-movement volume and latency tolerance during requirements
Data-movement needs (volume, frequency, one-time versus ongoing, on-premises source versus cloud-native) feed directly into later design choices, so capture the volume and latency tolerance early. A one-time bulk ingest of very large data is a transfer-appliance decision, while an ongoing low-latency event stream is a streaming-pipeline decision. The requirements stage's job is to make those numbers explicit, not to pick the tool.
- Treat security, compliance, and data residency as hard requirements from the first decision
Regulatory rules (HIPAA for health records, PCI DSS for card data, data sovereignty for a region-bound business) are non-functional requirements that constrain the design from the start, exactly like an availability target. Fold them in at requirements time rather than retrofitting, because a residency or compliance rule can rule out an entire region or service that an otherwise-cheaper answer relied on.
Trap Choosing the cheapest or most elegant option and adding compliance later; a data-residency rule can invalidate the region or service that option depended on, forcing a redesign.
- Work case-study options by eliminating any that break a hard requirement
The recognizable stem states a business outcome plus a constraint and asks for the option that best meets the requirements. Distractors typically each break one requirement: one is cheaper but misses the RTO, one is elegant but violates a compliance rule, one over-provisions for a need never stated. Eliminate every option that breaks a hard requirement, then pick the cheapest survivor.