The Google Cloud Professional Cloud Architect (PCA) exam tests whether you can design, plan, provision, secure, optimize, implement, and operate Google Cloud solutions that meet business goals. It is not mainly a memorization exam. It is a scenario exam: each question usually gives business constraints, technical requirements, risk tolerance, cost limits, migration context, and operational goals.
The exam expects you to think like an architect:
Start from business requirements, not from favorite services.
Prefer managed services when they reduce operational burden without violating requirements.
Design for reliability, security, cost, performance, operational excellence, and sustainability together.
Choose the simplest service that satisfies the requirements.
Avoid over-engineering unless the scenario explicitly requires extra control.
Recognize tradeoffs: consistency vs latency, cost vs RTO, serverless simplicity vs Kubernetes control, public access vs private connectivity, lift-and-shift speed vs modernization value.
The current standard exam format is approximately 50-60 multiple-choice and multiple-select questions, 2 hours, and includes case studies. Case-study questions commonly test whether you can apply architecture reasoning to a realistic company profile rather than choose a service from a keyword alone.
Use this course as follows:
Read the domain sections in order.
Memorize the service-selection tables.
Practice eliminating wrong answers using the trap patterns.
Revisit the final revision and checklist before exam day.
This guide was synthesized from the provided 1,051-row practice CSV and aligned to the latest official PCA exam domains and weights.
2. Exam Domains
Domain
Official domain name
Official weight
Rows in source bank
What matters most
1
Designing and planning a cloud solution architecture
~25%
263
Requirements, service choice, HA/DR, migration planning, compute/storage/network design, AI architecture
2
Managing and provisioning a cloud solution infrastructure
Domain 1 is the largest and most architecture-heavy. Spend the most time on tradeoffs and end-to-end designs.
Domains 2 and 3 are equally important: infrastructure and security are frequent differentiators between plausible answers.
Domains 4-6 often test process maturity: CI/CD, IaC, observability, SLOs, incident response, and business alignment.
Google Cloud Well-Architected principles appear across all domains: operational excellence, security, reliability, performance, cost optimization, and sustainability.
The latest guide includes modern AI/Gemini-related architecture topics. Know when to use managed AI products instead of building everything yourself.
Practice answering: why this service and not that one?
Cloud Run vs GKE vs Compute Engine.
Cloud SQL vs Spanner vs Firestore vs Bigtable.
Pub/Sub vs direct synchronous API calls.
Dataflow vs Dataproc vs BigQuery SQL.
Cloud VPN vs Dedicated Interconnect.
Shared VPC vs VPC peering vs Private Service Connect.
IAM least privilege vs primitive roles.
Cloud KMS vs default encryption vs Secret Manager.
Advanced phase: architecture scenarios
Work through complete designs:
Global web application with CDN, global load balancing, autoscaling, Cloud Armor, and managed backend.
Hybrid enterprise migration with Migration Center, dependency mapping, private connectivity, phased migration waves, and rollback.
Event-driven analytics pipeline with Pub/Sub, Dataflow, BigQuery, Cloud Storage, and monitoring.
Regulated healthcare/finance architecture with least privilege, CMEK, audit logs, VPC Service Controls, data residency, and separation of duties.
AI solution using Gemini/Vertex AI/Agent Builder where the right answer favors managed services, governance, and secure data access.
Final review phase
Review all service-selection tables.
Drill exam traps: public IP exposure, primitive IAM roles, single-zone designs, unmanaged VMs, no monitoring, no rollback, no RTO/RPO testing.
Practice case studies by extracting business and technical requirements before looking at answers.
For multi-select questions, require each selected option to satisfy the scenario. One correct service plus one bad practice is still wrong.
4. Core Concepts by Domain
Domain 1: Designing and planning a cloud solution architecture
What this domain tests
This is the biggest domain. It tests whether you can translate business and technical requirements into a complete cloud architecture. You must balance availability, scalability, latency, security, cost, migration complexity, operational effort, and future growth.
Choosing a single VM with snapshots for high availability.
Choosing Cloud SQL single-zone for critical production workloads requiring HA.
Choosing GKE when the scenario asks for minimal operations and does not require Kubernetes.
Choosing self-managed PostgreSQL or Hadoop when BigQuery/Dataflow/Dataproc better match scale and operational requirements.
Migrating everything at once without dependency discovery.
Ignoring RTO/RPO and assuming backups alone equal disaster recovery.
Using public IP allowlists when the requirement asks for private connectivity.
Decision framework
Is the workload stateless and HTTP-based? Think Cloud Run first.
Does it require Kubernetes APIs, custom controllers, service mesh, or portability? Think GKE.
Does it require legacy OS, custom agents, or full VM control? Think Compute Engine.
Is it analytics SQL at huge scale? Think BigQuery.
Is it globally distributed relational OLTP with strong consistency? Think Spanner.
Is it a managed MySQL/PostgreSQL/SQL Server workload? Think Cloud SQL.
Is it event-driven or decoupled? Think Pub/Sub.
Is it streaming or batch transformation? Think Dataflow.
Is it a migration question? Think assessment, dependencies, waves, testing, rollback.
Domain 2: Managing and provisioning a cloud solution infrastructure
What this domain tests
This domain tests whether you can configure the infrastructure that supports a solution: networking, storage, compute, container platforms, serverless, hybrid connectivity, and AI/ML infrastructure.
Fault-tolerant batch: Spot VMs with checkpointing/retries.
Kubernetes with lower ops: GKE Autopilot.
Kubernetes with maximum node/control flexibility: GKE Standard.
Traps
Using Cloud NAT for inbound access. NAT is for outbound connections from private resources.
Using VPC peering when transitive routing or centralized service publishing is required.
Choosing VPN for guaranteed high throughput and low latency when Interconnect is required.
Choosing unmanaged instance groups when managed instance groups provide autoscaling and autohealing.
Using Spot VMs for non-interruptible critical workloads.
Choosing Filestore for object storage or Cloud Storage for POSIX file semantics.
Domain 3: Designing for security and compliance
What this domain tests
This domain tests whether your architecture protects identities, data, networks, workloads, APIs, secrets, and audit trails while satisfying regulatory and organizational constraints.
Core concepts
IAM least privilege: grant the minimum role at the narrowest resource scope.
Avoid primitive roles: Owner, Editor, Viewer are usually wrong for production architectures.
External workload needs Google Cloud access without keys: Workload Identity Federation.
App needs to access Google APIs: service account with least privilege.
Human access to private admin app: IAP, not public IP + SSH.
Protect data exfiltration from BigQuery/Cloud Storage: VPC Service Controls.
Store database password/API token: Secret Manager.
Customer-controlled encryption: Cloud KMS CMEK.
Prevent public buckets: organization policy + IAM review.
Regulated audit export: Cloud Audit Logs sink to BigQuery or locked Cloud Storage bucket.
Protect internet app: Cloud Armor + HTTPS load balancer.
Traps
Granting Owner to a service account because it “works.”
Downloading service account keys instead of using federation/impersonation.
Storing secrets in Cloud Storage, Git, container images, or metadata.
Assuming encryption alone satisfies compliance; audit, retention, access control, and data residency also matter.
Using firewall rules as the only control for identity-based app access.
Ignoring separation of duties in regulated scenarios.
Making a bucket public for convenience when signed URLs, IAM, or CDN signed requests would be safer.
Domain 4: Analyzing and optimizing technical and business processes
What this domain tests
This domain checks whether you can improve how teams build, operate, govern, migrate, and optimize cloud solutions. It blends technical architecture with business process maturity.
Need reliable releases: CI/CD with automated tests and staged rollout.
Need reduce deployment risk: canary/blue-green + monitoring + rollback.
Need solve recurring incidents: root-cause analysis and postmortems, not only restart services.
Need business continuity: documented and tested DR plan.
Traps
Choosing a technical tool without fixing the process.
Treating DR as backups only.
Ignoring stakeholder communication in migration/change questions.
Optimizing cost by reducing redundancy below the required availability.
Adding manual approvals everywhere when the better answer is automated policy and testing.
Domain 5: Managing implementation
What this domain tests
This domain tests whether you can guide teams through deployment, migration, API management, testing, automation, and programmatic access to Google Cloud.
Core concepts
Deployment strategy: repeatable, automated, tested, and reversible.
Infrastructure as Code: use Terraform or equivalent IaC for reproducible environments.
CI/CD: build, scan, test, deploy, promote across environments.
Artifact management: Artifact Registry for images and packages.
API management: Apigee for API security, analytics, developer portal, quotas, and lifecycle.
Testing: unit, integration, load, security, performance, failover.
Migration execution: data migration, system migration, cutover, validation, rollback.
AI/Gemini/Vertex AI/Agent Builder high-level service selection and governance.
Final confidence checklist
Before taking the exam, you should be able to answer these without hesitation:
If a workload is stateless and wants minimal ops, why is Cloud Run usually better than GKE?
If a relational database must be global and strongly consistent, why is Spanner better than Cloud SQL?
If analytics is petabyte-scale SQL, why is BigQuery better than a self-managed database?
If systems need decoupling and replay, why is Pub/Sub the first service to consider?
If private VMs need outbound internet, why is Cloud NAT correct and why does it not solve inbound access?
If a company needs private access to services, why is Public IP allowlisting usually a trap?
If external workloads need Google Cloud access, why is Workload Identity Federation safer than service account keys?
If an architecture requires compliance, what controls beyond encryption are required?
If a release must be low risk, what role do canary, monitoring, and rollback play?
If a DR requirement gives RTO/RPO, how does that change architecture choice?
Compact Exam Mindset
The PCA exam rewards architects who choose managed, secure, reliable, cost-aware, and operationally simple solutions that directly satisfy the scenario. The best answer is rarely the most complex answer. It is the answer that meets the business goal, respects constraints, minimizes risk, and follows Google Cloud best practices.
When in doubt, choose the option that:
Meets the explicit requirement.
Uses managed services appropriately.
Preserves least privilege and private access.
Supports HA/DR according to RTO/RPO.
Is observable and automatable.
Optimizes cost without breaking reliability.
lock_open
Unlock the full course
All 41 modules with detailed explanations, code examples, and exam tips.
Designing and planning a cloud solution architecture · 25%
StreamFlow needs to expose private services from a producer VPC to many consumer VPCs without peering all networks or using public IP addresses. What should you design?
