The Google Cloud Professional Cloud Architect (PCA) exam validates your ability to design, develop, and manage robust, secure, scalable, and cost-effective solutions on Google Cloud that drive business objectives. It is a scenario-heavy exam organized around six areas, weighted from solution design and planning (the largest, at roughly 25%) through provisioning, security and compliance, process optimization, implementation, and operations excellence. Unlike a pure product-recall test, it grades architectural judgment: given a business and technical context, you must choose the trade-off Google's Well-Architected Framework would endorse, not merely an option that works. This sheet maps every exam area to the concrete Google Cloud services, patterns, and decision cues you need to reason like an architect under exam conditions.
What This Cheat Sheet Covers
This topic spans 41 focused tables and 470 indexed concepts, 326 flashcards, 13 practice tests with 566 questions. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Business Requirements and Solution StrategyTable 2: Cost Optimization on Google CloudTable 3: Business Continuity and Disaster RecoveryTable 4: High Availability, Scalability and Performance DesignTable 5: Google Cloud Well-Architected Framework and Operational ExcellenceTable 6: Cloud Migration PlanningTable 7: VPC Design and Network SegmentationTable 8: Private Connectivity and Service AccessTable 9: Cloud Load BalancingTable 10: Hybrid and Multicloud ConnectivityTable 11: Network Security and ProtectionTable 12: Choosing Compute PlatformsTable 13: Compute Engine and Machine TypesTable 14: GKE and Container OrchestrationTable 15: Serverless Computing on Google CloudTable 16: Infrastructure Orchestration and Specialized ComputeTable 17: Choosing Storage Types: Object, File and BlockTable 18: Choosing Database ServicesTable 19: Data Processing and AnalyticsTable 20: Data Lifecycle, Transfer and ProtectionTable 21: API Management and Integration PatternsTable 22: Vertex AI ML WorkflowsTable 23: AI Hypercomputer and AcceleratorsTable 24: Google Cloud AI APIs and Generative AITable 25: Identity and Access ManagementTable 26: Resource Hierarchy and Organization PolicyTable 27: Data Security, Encryption and Key ManagementTable 28: Security Controls and AuditingTable 29: Secure Access and Software Supply ChainTable 30: Securing AI WorkloadsTable 31: Regulatory Compliance and Data PrivacyTable 32: Industry Certifications and Audit LoggingTable 33: SDLC, CI/CD and Service CatalogTable 34: Troubleshooting, Testing and ValidationTable 35: Business Processes and Change ManagementTable 36: Google Cloud SDK, CLI and Programmatic AccessTable 37: Infrastructure as Code with TerraformTable 38: Cloud Observability: Monitoring and LoggingTable 39: Reliability, SLOs and AlertingTable 40: Deployment and Release ManagementTable 41: Production Support and Quality Control
Quick IndexSubscribe to unlock
A jump-to index of every table row in this cheat sheet.
Mind MapSubscribe to unlock
An interactive map of every table and concept in this topic.
Table 1: Business Requirements and Solution Strategy
PCA Exam Section 1.1 / 1.5: designing a cloud solution that meets business requirements and envisioning future improvements. These concepts turn business goals into measurable technical requirements, choose how each workload moves to the cloud, and weigh the trade-offs Google's Well-Architected Framework asks an architect to balance.
| Concept | Example | Description | |
|---|---|---|---|
"99.99% availability, p95 latency < 200ms" are NFRs; "users can reset a password" is functional | • The quality attributes (the "-ilities") a system must meet: availability, performance, security, cost, operational efficiency. • Define HOW WELL the system works, not WHAT it does • NFRs drive the architecture, so capture them early | ||
Add item to cart, process a payment, email a receipt | • The specific behaviors and features the system must perform • Not to be confused with NFRs: functional = what it does, non-functional = how well it does it • Both belong in an architecture decision record | ||
Legacy VM, no change needed → RehostMove to GKE containers → Replatform | • Six strategies for moving each workload: rehost, replatform, refactor, re-architect, rebuild, repurchase • Choose per workload by business value vs effort, not one strategy for everything | ||
Move a VM as-is to Compute Engine | • Move a workload with minor or no changes • Fastest, lowest effort, reuses existing skills • Trade-off: does not gain cloud-native benefits like horizontal scalability or managed services | ||
Self-hosted PostgreSQL → Cloud SQL | • Lift the workload then make targeted optimizations for the cloud (containers, managed DB). More effort than rehost, but gains elasticity, redundancy, and performance • Sits between rehost and refactor | ||
Break a monolith into microservices on Cloud Run | • Re-engineer the code to be cloud-native • Refactor improves the code • re-architect changes how it functions • Highest effort and risk, but unlocks scalability and removes technical debt | ||
On-prem email → Google Workspace (SaaS) | • Replace a purchased on-premises product with a cloud-hosted SaaS equivalent • Low resourcing effort • Trade-off: can cost more and you lose granular control of the environment | ||
Add a 2nd region → reliability up, cost up | • Six pillars covering the non-functional focus areas: operational excellence, security, reliability, cost optimization, performance, sustainability • Architecture is a balance of trade-offs across them | ||
Pub/Sub vs Cloud Tasks → record the why in an ADR | • An architecture decision record captures the options, the requirements driving the choice, and the accepted decision • Designs trade reliability, cost, performance, and complexity • there is rarely one universally best answer | ||
SLO = 99.95% availability over 30 days | • A precise numerical target for a non-functional attribute • Set it to the lowest reliability users actually need, since more reliability costs more • Measured by an SLI • an SLA is the external promise | ||
SLI 99.97% measured → SLO 99.95% target → SLA 99.9% promise | • SLI measures behavior, SLO is the internal target, SLA is the customer promise with a penalty • The SLA target is usually looser than the internal SLO. "Your SLA is not your SLO." | ||
Map spend to "cost per transaction" KPI | • Maximizing the business value of cloud spend, not just minimizing raw cost • Tie costs to KPIs so teams see how spending affects business outcomes • Success is value delivered, not the smallest bill | ||
3-year TCO and ROI from a migration assessment | • Measure success with KPIs, return on investment, and total cost of ownership, not raw price alone • Cloud shifts spending from CapEx (large upfront) to OpEx (ongoing, usage-based). | ||
Commit to steady Compute Engine usage for 1 to 3 years | • Significant price reductions in exchange for committing to a usage level over 1 to 3 years • Best for predictable, steady workloads • Not the right fit for bursty or fault-tolerant batch jobs (use Spot VMs). | ||
IaaS: most security is yoursSaaS: most is Google's | • Security duties split between you and Google by service type • The provider always owns the network and infrastructure • you always own your data and access policies • More managed service shifts more duty to Google | ||
Secure landing zone + opinionated blueprints | • Google's preferred evolution of shared responsibility: an active partnership where Google provides secure defaults, blueprints, and guidance • Goes beyond just drawing a line of where each party's duty ends | ||
GDPR data kept in EU regions; PCI DSS for payments | • Regulatory frameworks (PCI DSS, HIPAA, GDPR) define required controls, shared between you and Google • Data residency rules can dictate which regions you deploy to, so capture them as requirements up front | ||
Choose a managed service before self-managing | • Default to managed and cloud-native services rather than self-managing infrastructure • Simplify the design and use fully managed services to cut operational burden • Cloud-first is not "migrate everything as-is." | ||
Tactical → Strategic → Transformational | • Assesses readiness across Learn, Lead, Scale, Secure and three maturity phases • Frames how business needs and technology evolve over time so the architecture can grow with them | ||
Reassess SLOs after launching a premium tier | • No system is static • build for evolving business needs and reassess requirements periodically • Pair with managed services and decoupled, stateless components so the design can adapt without a rewrite |