Cert-Pass
Log in Sign up
arrow_back Cert

Google GCP Professional Cloud Architect

🔥 0 streak
0%
timer Mock lock Pro menu_book Course download Free
menu_book

GCP Professional Cloud Architect

Compressed Course

GCP Professional Cloud Architect Exam Course

1. Exam Overview

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:

  1. Read the domain sections in order.
  2. Memorize the service-selection tables.
  3. Practice eliminating wrong answers using the trap patterns.
  4. 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 ~17.5% 184 VPC, hybrid connectivity, storage configuration, compute provisioning, GKE/serverless, AI/ML infrastructure
3 Designing for security and compliance ~17.5% 184 IAM, organization policy, VPC Service Controls, KMS, secrets, audit, data protection, zero trust
4 Analyzing and optimizing technical and business processes ~15% 158 SDLC, CI/CD, cost, change management, DR, stakeholder alignment, process optimization
5 Managing implementation ~12.5% 131 Deployment, APIs, testing, migration tooling, IaC, CLI/SDK/API usage
6 Ensuring solution and operations excellence ~12.5% 131 Observability, SRE, reliability, release management, incident response, quality controls

Priority notes

  • 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.

3. Start-to-Finish Study Path

Foundation phase: build the mental map

Focus on what each service is for.

  • Compute: Compute Engine, managed instance groups, GKE, Cloud Run, Cloud Run functions.
  • Storage and databases: Cloud Storage, Filestore, Persistent Disk, Cloud SQL, Spanner, Firestore, Bigtable, Memorystore, BigQuery.
  • Networking: VPC, subnets, routes, firewall rules, Cloud NAT, load balancing, Cloud CDN, Cloud VPN, Cloud Interconnect, Shared VPC, VPC peering, Private Service Connect.
  • Security: IAM, service accounts, organization policy, Cloud KMS, Secret Manager, VPC Service Controls, Cloud Armor, IAP, Workload Identity Federation.
  • Operations: Cloud Monitoring, Cloud Logging, Error Reporting, Trace, Profiler, SLOs, alerting, incident response.
  • Delivery: Cloud Build, Cloud Deploy, Artifact Registry, Terraform, CI/CD, blue-green/canary releases.

Intermediate phase: learn service tradeoffs

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.

Core concepts

  • Requirement analysis: functional requirements, non-functional requirements, KPIs, ROI, regulatory constraints, operational constraints.
  • Architecture tradeoffs: managed vs self-managed, regional vs global, synchronous vs asynchronous, relational vs NoSQL, serverless vs Kubernetes.
  • High availability: multi-zone, multi-region, load balancing, autoscaling, health checks, failover design.
  • DR planning: RTO, RPO, backup/restore, pilot light, warm standby, active-active.
  • Migration planning: discovery, dependency mapping, migration waves, testing, rollback, licensing, network readiness.
  • Cloud-first design: prefer managed and scalable services unless the scenario requires explicit control.
  • Data movement: batch vs streaming, migration transfer tools, private connectivity, replication strategy.
  • AI architecture: use Gemini/Vertex AI/Agent Builder/Model Garden for managed AI capabilities where appropriate.

Key services

  • Compute: Cloud Run, GKE, Compute Engine, managed instance groups, Cloud Run functions.
  • Storage and data: Cloud Storage, BigQuery, Cloud SQL, Spanner, Firestore, Bigtable, Filestore, Memorystore.
  • Integration: Pub/Sub, Dataflow, Cloud Scheduler, Workflows, Eventarc.
  • Networking: Cloud Load Balancing, Cloud CDN, Cloud Armor, Cloud NAT, Cloud VPN, Interconnect, Private Service Connect, Shared VPC.
  • Migration: Migration Center, Migrate to Virtual Machines, Storage Transfer Service, Database Migration Service.

Frequently tested patterns

  • Stateless web app: Cloud Run or GKE/managed instance group behind global external Application Load Balancer. Use Cloud CDN for static content.
  • Petabyte analytics: BigQuery, not self-managed databases.
  • Event streaming: Pub/Sub + Dataflow + BigQuery/Cloud Storage.
  • Global relational consistency: Spanner.
  • Simple relational app: Cloud SQL with HA and backups.
  • Low-latency key-value or document app: Firestore.
  • Wide-column high-throughput time-series: Bigtable.
  • Private managed service access: Private Service Connect.
  • Enterprise migration: assess first, map dependencies, migrate in waves, validate, rollback.

Traps

  • 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

  1. Is the workload stateless and HTTP-based? Think Cloud Run first.
  2. Does it require Kubernetes APIs, custom controllers, service mesh, or portability? Think GKE.
  3. Does it require legacy OS, custom agents, or full VM control? Think Compute Engine.
  4. Is it analytics SQL at huge scale? Think BigQuery.
  5. Is it globally distributed relational OLTP with strong consistency? Think Spanner.
  6. Is it a managed MySQL/PostgreSQL/SQL Server workload? Think Cloud SQL.
  7. Is it event-driven or decoupled? Think Pub/Sub.
  8. Is it streaming or batch transformation? Think Dataflow.
  9. 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.

Core concepts

  • VPC design: custom mode VPCs, subnet planning, routes, firewall rules, hierarchical firewall policies.
  • Hybrid and multicloud: Cloud VPN, Dedicated Interconnect, Partner Interconnect, HA VPN, Cloud Router, BGP.
  • Load balancing: global vs regional, external vs internal, HTTP(S) vs TCP/UDP, health checks.
  • Private connectivity: Private Google Access, Private Service Connect, VPC peering, Shared VPC.
  • Compute provisioning: machine types, managed instance groups, autoscaling, Spot VMs, custom machine types, GPUs/TPUs.
  • Container orchestration: GKE Standard vs Autopilot, Workload Identity, Binary Authorization, network policies.
  • Serverless networking: VPC connectors, ingress/egress controls, Cloud Run service-to-service patterns.
  • Storage provisioning: lifecycle management, retention, backup, replication, latency, growth planning.
  • AI/ML infrastructure: Vertex AI pipelines, Model Garden, Gemini, GPUs/TPUs, AI Hypercomputer concepts.

Key services

  • Network: VPC, Cloud Router, Cloud VPN, Dedicated/Partner Interconnect, Cloud NAT, Cloud Load Balancing, Cloud CDN, Cloud Armor, Private Service Connect.
  • Compute: Compute Engine, MIGs, Spot VMs, GKE, Cloud Run, Cloud Run functions.
  • Storage: Cloud Storage, Persistent Disk, Hyperdisk, Filestore, Cloud SQL, Spanner, Bigtable, Firestore.
  • AI/ML: Vertex AI, Vertex AI Pipelines, Model Garden, Gemini, GPUs, TPUs.

Frequently tested patterns

  • Outbound internet from private VMs: Cloud NAT.
  • Inbound global HTTP app: global external Application Load Balancer.
  • Static global content: Cloud Storage + Cloud CDN, or backend buckets.
  • Private services across VPC/projects: Private Service Connect.
  • Shared enterprise network: Shared VPC with host and service projects.
  • Hybrid high-throughput low-latency: Dedicated Interconnect.
  • Hybrid encrypted lower-cost connectivity: HA VPN.
  • 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.
  • Resource hierarchy: organization, folders, projects, resource-level IAM.
  • Separation of duties: split admin, deployer, auditor, security, and runtime identities.
  • Service accounts: use dedicated service accounts, avoid long-lived keys, prefer impersonation or Workload Identity Federation.
  • Data protection: default encryption, CMEK with Cloud KMS, key rotation, key separation.
  • Secrets: Secret Manager for secrets, not source code, environment variables, or Cloud Storage files.
  • Perimeter security: VPC Service Controls for data exfiltration risk around supported services.
  • Edge security: Cloud Armor for WAF/DDoS controls, IAP for identity-aware access to apps, reCAPTCHA Enterprise for bot/fraud signals.
  • Auditability: Cloud Audit Logs, logging sinks, retention, BigQuery exports, immutable storage where required.
  • Compliance: data residency, data sovereignty, PII/PHI handling, PCI, SOC2, audit evidence.
  • Secure software supply chain: Artifact Registry, Binary Authorization, vulnerability scanning, provenance, policy enforcement.
  • Secure AI: protect prompts/data, use Sensitive Data Protection, Model Armor, restricted access, logging and governance.

Key services

  • IAM, service accounts, IAM Conditions, Recommender.
  • Organization Policy Service, Policy Controller, hierarchical firewall policies.
  • Cloud KMS, Cloud HSM, Secret Manager.
  • VPC Service Controls, Private Service Connect, Private Google Access.
  • Cloud Armor, IAP, BeyondCorp/Chrome Enterprise Premium concepts.
  • Security Command Center, Cloud Audit Logs, Cloud Logging sinks.
  • Workload Identity Federation, service account impersonation.
  • Binary Authorization, Artifact Registry, Cloud Build provenance.

Frequently tested patterns

  • 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.

Core concepts

  • SDLC maturity: source control, code review, automated tests, CI/CD, release gates.
  • Infrastructure validation: policy checks, Terraform plan review, automated security scans.
  • Troubleshooting: use metrics, logs, traces, profiling, error reports, and root-cause analysis.
  • DR and business continuity: define RTO/RPO, test failover, document runbooks, improve after tests.
  • Change management: staged rollout, rollback, stakeholder communication.
  • Cost optimization: right-size, autoscale, committed use discounts, budgets, labels, lifecycle policies, storage class optimization.
  • Resource governance: folders, projects, labels, quotas, billing export, service catalog.
  • Team readiness: skills assessment, training, operating model, support responsibilities.
  • Customer success: align KPIs, SLOs, cost, adoption, and business outcomes.

Key services and tools

  • Cloud Monitoring, Cloud Logging, Cloud Trace, Profiler, Error Reporting.
  • Cloud Billing export to BigQuery, budgets, cost reports, Recommender.
  • Cloud Build, Cloud Deploy, Artifact Registry, Terraform, Policy Controller.
  • Backup and DR, snapshots, managed database backups, lifecycle policies.
  • Cloud Asset Inventory, IAM Recommender, Security Command Center.

Frequently tested patterns

  • Need cost visibility: labels/tags + billing export to BigQuery + dashboards.
  • Need reduce waste: Recommender + rightsizing + autoscaling + scheduling non-prod shutdown.
  • 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.
  • Programmatic access: gcloud, bq, gsutil/gcloud storage, SDKs, API client libraries, Cloud Shell.
  • Local testing: emulators for services such as Pub/Sub, Spanner, Firestore, Bigtable where applicable.

Key services

  • Cloud Build, Cloud Deploy, Artifact Registry, Binary Authorization.
  • Terraform, Cloud Shell, Cloud Code, Google Cloud SDK, client libraries.
  • Apigee, API Gateway where simpler API fronting is enough.
  • Database Migration Service, Storage Transfer Service, Migrate to Virtual Machines.
  • Cloud Deploy rollout strategies, GKE/Cloud Run deployment targets.

Frequently tested patterns

  • Provision many environments consistently: Terraform/IaC.
  • Build and deploy containers: Cloud Build + Artifact Registry + Cloud Deploy.
  • Control container deployment policy: Binary Authorization.
  • Expose and manage enterprise APIs: Apigee.
  • Move databases with minimal downtime: Database Migration Service where supported.
  • Move large object data: Storage Transfer Service or Transfer Appliance depending scale/connectivity.
  • Test locally against managed services: use emulators where available.

Traps

  • Manual console clicks for repeatable production environments.
  • Pushing containers directly from developer laptops to production.
  • No rollback strategy.
  • No load/performance testing before migration cutover.
  • Using API keys or user credentials where service accounts and IAM are required.
  • Choosing Apigee for a simple internal HTTP endpoint when Cloud Endpoints/API Gateway may be enough.

Domain 6: Ensuring solution and operations excellence

What this domain tests

This domain tests whether you can keep solutions reliable, observable, supportable, and continuously improving in production.

Core concepts

  • Operational excellence: runbooks, automation, ownership, incident response, continuous improvement.
  • Observability: metrics, logs, traces, profiles, errors, dashboards.
  • SLOs/SLIs: define user-centered reliability goals and error budgets.
  • Alerting: alert on symptoms and SLO burn, not every noisy metric.
  • Release management: canary, blue-green, progressive rollout, rollback.
  • Production readiness: load testing, chaos testing, failover testing, penetration testing where appropriate.
  • Support model: escalation paths, on-call, incident severity, postmortems.
  • Quality control: policy checks, test coverage, monitoring coverage, security scanning.

Key services

  • Cloud Monitoring, Cloud Logging, Cloud Trace, Error Reporting, Cloud Profiler.
  • Managed Service for Prometheus, Cloud Operations suite.
  • Cloud Deploy, Cloud Build, Artifact Registry.
  • Security Command Center, Cloud Armor logs, Cloud Audit Logs.
  • Uptime checks, alerting policies, log-based metrics.

Frequently tested patterns

  • Need debug latency: Cloud Trace and Profiler.
  • Need debug app errors: Error Reporting + logs.
  • Need service health dashboards: Cloud Monitoring dashboards with SLIs.
  • Need alert on reliability: SLO burn-rate alerts.
  • Need improve incidents: postmortem + action items + automation.
  • Need test resilience: chaos testing and failover testing in controlled environments.

Traps

  • Alerting only on CPU when user experience is the requirement.
  • Not defining SLOs before creating alerts.
  • Ignoring logs/traces and guessing root cause.
  • Treating postmortems as blame instead of learning.
  • Deploying directly to all users with no progressive release.
  • Monitoring infrastructure but not business/user KPIs.

5. Service Selection Guide

Compute services

Requirement Best fit Use when Avoid when
Stateless HTTP app, low ops, autoscaling Cloud Run Containers, request-driven scaling, minimal infrastructure Need Kubernetes APIs, daemonsets, custom networking control
Event/function-driven lightweight code Cloud Run functions Simple event handlers, glue code Long-running complex services or custom runtime control
Kubernetes platform GKE Need Kubernetes ecosystem, custom controllers, service mesh, portability Team lacks Kubernetes skills or wants minimal ops
Full VM control Compute Engine Legacy apps, custom OS/agents, licensing constraints Managed/serverless meets requirements
Autoscaled VM fleet Managed instance group VM workloads needing autohealing/autoscaling Single VM is enough for dev/test only
Fault-tolerant cheap batch Spot VMs Jobs can be interrupted/retried Critical stateful or non-interruptible workloads

Compute decision rule

Cloud Run first for simple stateless services. GKE for Kubernetes-specific control. Compute Engine for VM-specific requirements.

Storage and database services

Requirement Best fit Why Common wrong answer
Object storage, backups, static assets Cloud Storage Durable, scalable, lifecycle policies Filestore if no POSIX file need
Shared POSIX file system Filestore Managed NFS Cloud Storage if app needs file locking/POSIX
Managed relational database Cloud SQL MySQL/PostgreSQL/SQL Server compatibility Spanner if global scale not required
Global relational OLTP, strong consistency Cloud Spanner Horizontal scale + consistency Cloud SQL single-zone
Document/mobile/web app data Firestore Serverless document DB Cloud SQL if flexible document model is required
Wide-column, high-throughput, low-latency Bigtable Time-series/IoT/adtech scale Firestore for huge analytical write patterns
In-memory cache Memorystore Redis/Memcached managed cache Cloud SQL read replica for caching-only need
Petabyte SQL analytics BigQuery Serverless warehouse, separates storage/compute Self-managed PostgreSQL/Hadoop

Data processing and analytics

Scenario Choose Why
Event ingestion and fanout Pub/Sub Durable decoupling and replay patterns
Stream/batch processing pipelines Dataflow Managed Apache Beam execution
Managed Spark/Hadoop Dataproc Existing Spark/Hadoop jobs, ecosystem compatibility
SQL analytics and BI BigQuery Serverless, scalable, native ML/geospatial/BI integration
Orchestrating workflows Workflows / Cloud Composer Workflows for service orchestration; Composer for Airflow DAGs
Transfer object data Storage Transfer Service Managed data movement into Cloud Storage

Networking services

Requirement Best fit Trap to avoid
Outbound internet from private instances Cloud NAT NAT does not provide inbound access
Global HTTP(S) application Global external Application Load Balancer Regional/internal LB when global internet app is needed
Static content acceleration Cloud CDN Bigger VM is not a CDN
DDoS/WAF protection Cloud Armor Firewall rules alone do not provide WAF features
Private access to producer services Private Service Connect Public IP allowlists are not private connectivity
Shared enterprise network Shared VPC One project for all teams breaks isolation
Hybrid encrypted connectivity HA VPN Not ideal for guaranteed high bandwidth
Hybrid predictable high-throughput Dedicated/Partner Interconnect More complex/costly than VPN, but better for strict needs

Security services

Requirement Best fit Why
Least privilege access IAM predefined/custom roles Narrow permissions at correct scope
Enforce org-wide restrictions Organization Policy Prevents unsafe configurations
Manage encryption keys Cloud KMS / Cloud HSM CMEK and key control
Store secrets Secret Manager Rotation, IAM, auditability
Data exfiltration perimeter VPC Service Controls Reduces risk for supported services
Private admin app access IAP Identity-aware access without public bastions
External identity without keys Workload Identity Federation Avoids long-lived service account keys
Container deployment trust Binary Authorization Enforces signed/approved images
Security posture management Security Command Center Central findings and risk visibility

AI and ML services

Requirement Best fit Notes
Build/use managed generative AI apps Gemini / Vertex AI / Agent Builder Prefer managed platforms over training from scratch
Discover/use foundation models Model Garden Evaluate models and deployment options
Automate ML lifecycle Vertex AI Pipelines Orchestrates training, evaluation, deployment
Need GPUs/TPUs for large training Vertex AI custom training / AI Hypercomputer concepts Match accelerator to workload
Protect AI input/output Sensitive Data Protection, Model Armor, IAM, logging Secure data and prompts

6. Architecture Patterns

Pattern 1: Global customer-facing web application

Recommended architecture:

  • Global external Application Load Balancer.
  • Cloud CDN for static/cacheable content.
  • Cloud Armor for WAF/DDoS controls.
  • Cloud Run for stateless containers if minimal ops is required.
  • GKE if Kubernetes control is required.
  • Cloud SQL HA or Spanner depending database scale/consistency needs.
  • Cloud Monitoring, Logging, Error Reporting, Trace.

Why alternatives are wrong:

  • A single VM is not highly available.
  • Snapshots are recovery aids, not active HA.
  • Regional-only load balancing may not satisfy global latency/availability requirements.
  • Public buckets without controls violate security requirements.

Pattern 2: Enterprise landing zone

Recommended architecture:

  • Organization node with folders by environment/business unit.
  • Projects for isolation and blast-radius control.
  • Shared VPC for centralized networking.
  • IAM groups mapped to roles; avoid user-by-user grants.
  • Organization policies to restrict risky configurations.
  • Centralized logging, billing export, labels, and security posture monitoring.

Why alternatives are wrong:

  • One project for everything creates IAM, billing, quota, and blast-radius problems.
  • Granting Owner broadly violates least privilege.
  • No folder/project structure makes compliance and chargeback harder.

Pattern 3: Hybrid migration

Recommended approach:

  1. Assess with Migration Center or equivalent discovery.
  2. Map dependencies.
  3. Classify workloads: rehost, replatform, refactor, retire, retain, replace.
  4. Plan networking: VPN/Interconnect, DNS, identity, firewall.
  5. Migrate in waves.
  6. Test performance, security, failover, rollback.
  7. Optimize after migration.

Why alternatives are wrong:

  • Big-bang migration ignores hidden dependencies.
  • Refactoring everything first may delay business value.
  • Migrating without rollback increases risk.

Pattern 4: Event-driven analytics

Recommended architecture:

  • Pub/Sub for ingestion and decoupling.
  • Dataflow for streaming/batch processing.
  • BigQuery for analytics.
  • Cloud Storage for raw landing/archive.
  • Cloud Composer/Workflows for orchestration where needed.
  • Monitoring for lag, errors, throughput, and data freshness.

Why alternatives are wrong:

  • Direct writes to local VM disk lose durability and decoupling.
  • Email/CSV batch files are not near real time.
  • Synchronous APIs between all services create tight coupling.

Pattern 5: Regulated healthcare or finance workload

Recommended architecture:

  • Organization/folder/project hierarchy by environment and data sensitivity.
  • Least privilege IAM and separation of duties.
  • CMEK where customer key control is required.
  • Secret Manager for secrets.
  • VPC Service Controls for supported data services.
  • Private connectivity and restricted ingress/egress.
  • Audit logs exported to secured retention targets.
  • Data classification, retention, and residency controls.

Why alternatives are wrong:

  • Encryption alone is not a compliance architecture.
  • Public IP allowlists are weak when private connectivity is required.
  • Primitive roles fail separation of duties.

Pattern 6: Reliable deployment pipeline

Recommended architecture:

  • Source repository with branch controls.
  • Cloud Build for build/test/scan.
  • Artifact Registry for image/package storage.
  • Binary Authorization for deployment policy.
  • Cloud Deploy for progressive delivery.
  • Terraform for infrastructure.
  • Monitoring-based rollback for failed canary/blue-green releases.

Why alternatives are wrong:

  • Manual deployments are not repeatable.
  • Deploying from laptops breaks auditability.
  • No rollback means high release risk.

Pattern 7: AI assistant over enterprise data

Recommended architecture:

  • Use Gemini/Vertex AI/Agent Builder or Gemini Enterprise-style managed capabilities where possible.
  • Connect to governed enterprise data sources with least privilege.
  • Apply data loss prevention/sensitive data controls.
  • Log and monitor access and model behavior.
  • Use grounding/retrieval instead of training from scratch unless there is a strong requirement.

Why alternatives are wrong:

  • Training an LLM from scratch is usually too costly and unnecessary.
  • Public buckets or unauthenticated APIs violate enterprise security.
  • A generic chatbot without grounding will not satisfy enterprise accuracy requirements.

7. Exam Traps

Misleading wording patterns

Wording in question What it usually signals
“Minimal operational overhead” Prefer managed/serverless services
“Global scale” + “relational” + “strong consistency” Cloud Spanner
“Petabyte SQL analytics” BigQuery
“Replay” + “decouple” + “events” Pub/Sub
“Streaming transformation” Dataflow
“Private access to managed services” Private Service Connect / Private Google Access depending context
“Outbound internet from private VMs” Cloud NAT
“No public IP administrative access” IAP, bastionless access, private connectivity
“Regulated data exfiltration risk” VPC Service Controls + IAM + logging
“External identity without service account keys” Workload Identity Federation
“Consistent environments” Terraform/IaC
“Reduce deployment risk” Canary/blue-green + monitoring + rollback
“Cost optimization without reducing availability” Rightsize/autoscale/CUD/lifecycle, not removing HA

Wrong-but-plausible answers

  • Single VM + snapshots: recovery possible, but not highly available.
  • Cloud SQL single-zone: fine for non-critical workloads, wrong for HA production.
  • Public IP allowlist: may be acceptable for simple cases, wrong when private connectivity is required.
  • Primitive IAM roles: easy but too broad.
  • Service account keys: familiar but risky; prefer federation/impersonation.
  • GKE for everything: powerful but overkill when Cloud Run satisfies requirements.
  • BigQuery for OLTP: excellent analytics, not transactional app database.
  • Firestore for analytics: good operational document DB, not petabyte analytics warehouse.
  • Cloud NAT for inbound: NAT is outbound only.
  • Backups as DR: backups are part of DR, but RTO/RPO, failover, and testing are required.

Elimination strategy

  1. Remove answers that violate explicit requirements.
  2. Remove answers with unnecessary operational burden when managed alternatives fit.
  3. Remove answers that are single-zone/single-instance for high-availability scenarios.
  4. Remove answers that grant overly broad permissions.
  5. Remove answers that expose public IPs when private access is required.
  6. Remove answers that solve only one part of the requirement but ignore security, cost, or operations.
  7. For multi-select, each selected answer must be independently correct and jointly complete.

8. Quick Memory Rules

Fast service mapping

  • Stateless container + minimal ops -> Cloud Run.
  • Kubernetes-specific requirement -> GKE.
  • Legacy OS or full VM control -> Compute Engine.
  • Autoscaled VM fleet -> Managed instance group.
  • Cheap interruptible batch -> Spot VMs with retries.
  • Object storage/static assets/backups -> Cloud Storage.
  • Shared NFS -> Filestore.
  • Managed relational regional app -> Cloud SQL HA.
  • Global relational consistency -> Spanner.
  • Documents/mobile sync -> Firestore.
  • Huge wide-column/time-series -> Bigtable.
  • In-memory cache -> Memorystore.
  • Petabyte SQL analytics -> BigQuery.
  • Events/replay/decoupling -> Pub/Sub.
  • Streaming/batch ETL -> Dataflow.
  • Existing Spark/Hadoop -> Dataproc.
  • Outbound private internet -> Cloud NAT.
  • Global web frontend -> Global external Application Load Balancer.
  • Static acceleration -> Cloud CDN.
  • WAF/DDoS -> Cloud Armor.
  • Private producer/consumer service access -> Private Service Connect.
  • Enterprise shared network -> Shared VPC.
  • Hybrid encrypted -> HA VPN.
  • Hybrid high throughput/predictability -> Interconnect.
  • Secrets -> Secret Manager.
  • Keys/CMEK -> Cloud KMS.
  • Exfiltration perimeter -> VPC Service Controls.
  • Identity-aware private access -> IAP.
  • External identity no keys -> Workload Identity Federation.
  • IaC -> Terraform.
  • Build containers -> Cloud Build.
  • Store artifacts -> Artifact Registry.
  • Progressive delivery -> Cloud Deploy.
  • API management -> Apigee.
  • Observe metrics/logs/traces -> Cloud Monitoring/Logging/Trace.

Reliability rules

  • HA usually means multi-zone, not just backups.
  • DR means RTO/RPO + tested failover + documented runbooks.
  • Global users often need global load balancing and CDN.
  • Stateful systems require careful replication, backup, and consistency decisions.
  • Alert on user impact and SLOs, not only CPU.

Security rules

  • Least privilege beats convenience.
  • Avoid primitive roles in production.
  • Avoid service account keys when federation/impersonation works.
  • Secrets belong in Secret Manager.
  • CMEK is for customer key control; default encryption is not the same as customer-managed keys.
  • Compliance requires auditability, retention, access control, and process evidence.

Cost rules

  • Use autoscaling for variable demand.
  • Use Spot VMs only for interruptible workloads.
  • Use lifecycle policies for object storage.
  • Use committed use discounts for predictable compute/database spend.
  • Use billing export and labels for cost attribution.
  • Do not reduce redundancy below stated availability requirements.

9. Final Revision Notes

Highest-yield review points

  • Domain 1 is the highest-weight domain: service choice, migration, architecture tradeoffs, HA/DR, AI architecture.
  • Know Cloud Run vs GKE vs Compute Engine cold.
  • Know Cloud SQL vs Spanner vs Firestore vs Bigtable vs BigQuery cold.
  • Know Pub/Sub + Dataflow + BigQuery for event analytics.
  • Know Cloud NAT vs load balancer vs Private Service Connect.
  • Know IAM least privilege, service accounts, Workload Identity Federation, and VPC Service Controls.
  • Know how to design landing zones using org/folder/project hierarchy and Shared VPC.
  • Know how to reduce release risk using CI/CD, IaC, canary/blue-green, and rollback.
  • Know observability: Monitoring, Logging, Trace, Error Reporting, Profiler, SLOs.
  • Know how to reason from RTO/RPO to DR design.

Last-day rapid review

  1. Read every table in this guide.
  2. Practice identifying the signal words in questions.
  3. Review wrong answer traps.
  4. Memorize the service mapping list.
  5. Review case-study style thinking: business goals first, then technical constraints, then service choice.
  6. For every answer, ask: Is it secure? Is it reliable? Is it cost-aware? Is it operationally simple? Does it satisfy the stated requirement?

10. Exam-Day Checklist

Must-know topics

  • Official six exam domains and their approximate weights.
  • Google Cloud Well-Architected pillars.
  • Case-study strategy: extract business and technical requirements first.
  • Cloud Run, GKE, Compute Engine selection.
  • Managed instance groups, autoscaling, autohealing, health checks.
  • Cloud Storage, Filestore, Persistent Disk/Hyperdisk basics.
  • Cloud SQL, Spanner, Firestore, Bigtable, Memorystore, BigQuery selection.
  • Pub/Sub, Dataflow, Dataproc, Composer/Workflows selection.
  • VPC, subnets, firewall rules, routes, Cloud Router.
  • Cloud NAT, Cloud Load Balancing, Cloud CDN, Cloud Armor.
  • Cloud VPN vs Interconnect.
  • Shared VPC, VPC peering, Private Service Connect, Private Google Access.
  • IAM least privilege, service accounts, IAM Conditions.
  • Organization policy, resource hierarchy, separation of duties.
  • Cloud KMS, Secret Manager, VPC Service Controls.
  • IAP, Workload Identity Federation, service account impersonation.
  • Audit logging, log sinks, retention, compliance evidence.
  • Security Command Center and secure software supply chain.
  • Terraform/IaC, Cloud Build, Artifact Registry, Cloud Deploy.
  • Binary Authorization and deployment policy.
  • Apigee/API management basics.
  • Migration Center, migration waves, dependency mapping, rollback.
  • RTO/RPO, backup, failover, DR testing.
  • Monitoring, Logging, Trace, Error Reporting, Profiler.
  • SLOs, SLIs, alerting, incident response, postmortems.
  • Cost optimization: labels, billing export, Recommender, lifecycle, CUDs, autoscaling.
  • 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:

  1. Meets the explicit requirement.
  2. Uses managed services appropriately.
  3. Preserves least privilege and private access.
  4. Supports HA/DR according to RTO/RPO.
  5. Is observable and automatable.
  6. Optimizes cost without breaking reliability.
lock_open

Unlock the full course

All 41 modules with detailed explanations, code examples, and exam tips.

upgrade Get Full Access auto_stories View Full Course
workspace_premium
You've answered 0 of 35 free questions 972 questions locked : these will appear on exam day.
0/35
rocket_launch Unlock All
event_available
Day 1 of 14 72 questions/day Finish by Jun 10, 2026
Go to Day 1
Question 8 of 1007
Designing and planning a cloud solution architecture · 25%

PharmaTrust has fault-tolerant image rendering jobs that can restart from checkpoints. Management wants the lowest compute cost. Which compute option should you use? Choose the option that best meets the requirement with the least operational overhead.

arrow_back
0 correct
0 wrong
1007 left
1% done