What's changed: Created Professional Cloud Architect Chapter 1 (Domain 1 "Design and plan" part 1: requirements to architecture = business/technical requirements, resource hierarchy, organization policies, KPIs/SLOs; choosing compute/storage/data = CE/GKE/Cloud Run/Functions, Cloud Storage/PD/Filestore, Cloud SQL/Spanner/Firestore/Bigtable/BigQuery).
1.1From requirements to architecture
Understand eliciting business and technical requirements and translating them into a Google Cloud architecture, designing the resource hierarchy (Organization → Folder → Project), reflecting stakeholder expectations and compliance constraints, and making design decisions based on success metrics (KPIs/SLOs).
A Professional Cloud Architect translates business goals into a robust architecture on Google Cloud. The first job is not technology but capturing requirements correctly—misread them and every later design decision is off.
1.1.1Business and technical requirements
The architect first elicits business requirements (cost reduction, time to market, availability targets, regulatory needs) and technical requirements (performance, scalability, latency, migration constraints). Quantify them as success metrics (KPIs and SLOs) to judge design tradeoffs (cost vs. availability, speed vs. governance). The flow "requirements → metrics → design decision" recurs throughout Architect questions.
1.1.2Resource hierarchy and project design
Governance in Google Cloud follows the resource hierarchy (Organization → Folder → Project → resources). A project is the basic billing/permission unit, and policies (IAM and organization policies) inherit down the hierarchy. Separate folders/projects by environment (prod/dev) or department to design least privilege and compliance boundaries. Map "separate environments/departments = folders/projects" and "enforce consistent rules = inherited organization policies."
Common: requirement → design. E.g., "fastest time to market" = lean managed/serverless; "strict regulation" = data residency, organization policies, compliance boundaries; "separate prod and dev" = split folders/projects; "org-wide consistent constraints" = inherited organization policies; "quantify goals" = KPIs/SLOs.
Watch the mix-ups: (1) The project is the basic billing/permission unit—do not cram everything into one. (2) Organization policies differ from IAM grants (they enforce constraints). (3) Capture both business and technical requirements—missing one leads to a wrong solution.
1.1.3Section summary
- Elicit business and technical requirements; quantify as KPIs/SLOs to drive design decisions
- Resource hierarchy = Org → Folder → Project; the project is the basic billing/permission unit
- Separate environments/departments via folders/projects; enforce consistent constraints via inherited organization policies
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. What should be prioritized first in architecture design?
Q2. Which is the basic unit of billing and permissions in Google Cloud?
Q3. To separate prod and dev and inherit different policies per environment, which best fits?
Q4. Which is the best basis for judging design tradeoffs (e.g., cost vs. availability)?
Q5. Which correctly describes organization policies vs IAM?
Q6. For a business requirement prioritizing "time to market," which design direction is most appropriate?