Why requirements come first
Every design question on the Professional Cloud Architect exam starts with requirements, whether it says so or not. Section 1.1 of Google's exam guide lists business use cases and product strategy and identifying functional and non-functional requirements as the first things to consider when you design an infrastructure that meets business requirements. If you get the requirements wrong, you will pick the wrong product even when you know the product well.
At Associate Cloud Engineer level, someone handed you the requirements and you built to them. At Architect level you have to pull them out of a business story yourself. This lesson shows you how.
Step 1: Separate functional from non-functional requirements
Sort every statement in a scenario into one of two groups.
- Functional requirements say what the system must do. They are features and behaviours.
- "Customers can search the catalogue in natural language."
- "Ingest data from new insurance providers."
- "Generate image variations from product photos."
- Non-functional requirements (NFRs) say how well the system must do it, and under what limits. They are qualities and constraints.
- Availability: "99.9% available for customer-facing systems."
- Latency and performance: "Page loads under 200 ms for European users."
- Scalability: "Handle 10x traffic on launch day."
- Security and compliance: "Patient records must stay in the EU."
- Cost and operations: "Reduce administration overhead."
Quick test: if you could tick the statement off as a feature in a demo, it is functional. If it describes a level, a limit, a rule or a budget, it is non-functional.
The Google Cloud Well-Architected Framework, which the exam guide calls a key requirement for this role, is organised around these non-functional concerns. Its six pillars are operational excellence; security, privacy and compliance; reliability; cost optimization; performance optimization; and sustainability. When you label an NFR, name the pillar it belongs to.
Step 2: Turn product strategy into architectural constraints
Business people rarely write "RTO 15 minutes". They describe a strategy, and you translate it. Practise this mapping:
| Business statement (strategy) | Architectural constraint (NFR) |
|---|---|
| "Expand into Asia next year" | Multi-region design, low latency for APAC users, possible data-residency rules |
| "Our brand depends on never being down at checkout" | High availability for the checkout path, failover across zones or regions |
| "We serve hospitals" | Health-record privacy regulation, audit logging, encryption controls |
| "Launch fast and validate the idea" | Managed and serverless services, minimal operations, pay-per-use cost |
| "Cut data-centre spend" | Cost optimisation, retire self-managed infrastructure |
What to DO: for each business sentence, ask "what would break this goal?" The answer is usually the constraint. Global expansion fails if latency is poor, so latency becomes a constraint. Selling to hospitals fails without compliance, so compliance becomes a constraint.
Step 3: Apply it to a case study
The exam's current case studies (Altostrat Media, Cymbal Retail, EHR Healthcare and KnightMotives Automotive) are written as business stories. The case-study documents are Google's own, and you can get them free from the certification page. Take EHR Healthcare as an example. It is a SaaS provider of electronic health record software that is moving out of colocation facilities onto Google Cloud.
- List functional needs: onboard new insurance providers quickly, ingest data from new provider sources, derive trends and insights from that data.
- List non-functional needs: at least 99.9% availability for customer-facing systems, secure high-performance hybrid connectivity to legacy on-premises systems, centralised monitoring and alerting, lower administration overhead, healthcare privacy regulation.
- Tag each one with a pillar: availability goes to reliability, administration overhead to operational excellence, privacy to security, privacy and compliance.
- Rank the hard constraints: regulation and availability targets are non-negotiable. "Reduce overhead" is a preference.
The ranking matters. A regulatory or numeric requirement is a hard constraint, and any option that breaks it is wrong. Aims like "simpler" or "cheaper" are soft goals: use them to choose between the options that are still valid.
Step 4: Find the requirement that decides the answer
Most exam questions include several plausible options that all meet the functional need. The answer depends on one non-functional detail in the question. Work through it like this:
- Read the last sentence first to see what is being asked.
- Underline the qualifiers: globally, minimal latency, must remain in, without managing infrastructure, lowest cost, strongly consistent.
- Confirm that every option meets the functional need. Usually they all do, so the functional need does not decide the answer.
- Remove any option that breaks a hard constraint.
- If more than one option is left, use the soft goal to choose, such as least operational effort or lowest cost.
Example: "A retailer needs a relational database for orders. Customers on three continents must see consistent stock levels with low write latency worldwide." Several databases can store orders. The words three continents and consistent are what decide it. They point to a globally distributed, strongly consistent relational database (Spanner) rather than a single-region option. Later levels cover the product choices in depth. For now, practise spotting the words that decide the answer.
What the exam asks about this
- Scenario questions hide the deciding NFR in an adjective or a number. Questions that test you on this skill are hard to recognise as such.
- Case-study questions expect you to remember the company's stated requirements, such as EHR Healthcare's availability target, and to reject designs that ignore them.
- Distractors often meet the functional need perfectly but break a constraint, or they over-engineer past what the business asked for.
Key takeaways
- Functional means what the system does. Non-functional means how well, and under what limits.
- Translate product strategy into constraints by asking what would break the goal.
- Map NFRs to the Well-Architected Framework pillars.
- Hard constraints (regulation, stated SLAs) remove options. Soft goals (cost, simplicity) choose among the options left.
- In every question, find the one qualifier that decides the answer before you look at the options.