PCA — Google Cloud Professional Cloud Architect 2026 Exam Blueprint

How to Use This Exam Blueprint

Use this checklist as a practical study map for the Google Cloud Professional Cloud Architect 2026 exam from Google Cloud, exam code PCA. It is designed for final review and gap analysis, not as an official scoring guide.

Work through it in three passes:

1. Recognition pass: Can you recognize the Google Cloud service, pattern, or control being tested?
2. Decision pass: Can you choose between plausible options based on requirements, tradeoffs, constraints, and risk?
3. Justification pass: Can you explain why the selected architecture is more appropriate than the alternatives?

For each topic, mark yourself ready only when you can apply it to a scenario with business requirements, operational constraints, security needs, and cost pressure.

Topic-Area Readiness Table

Architecture and Requirements Framing

The PCA exam commonly rewards architectural judgment. Before selecting a service, extract the requirement behind the service choice.

Can You Do This?

• Separate business requirements from technical requirements.
• Identify hard constraints: compliance, data residency, latency, RTO, RPO, skills, budget, and timeline.
• Detect when a simple managed service is better than a custom-built platform.
• Explain tradeoffs among cost, performance, reliability, security, portability, and operational effort.
• Choose regional, multi-regional, hybrid, or multi-environment patterns based on actual requirements.
• Recognize when requirements conflict and propose a practical compromise.
• Use labels, tags, folders, and projects to support chargeback, ownership, policy, and lifecycle management.
• Recommend phased implementation when a “big bang” migration or redesign is too risky.

Scenario Cues

Google Cloud Resource Hierarchy and Governance

A strong PCA candidate can design the management structure, not just the application architecture.

Checklist

• Explain the purpose of organization, folders, projects, and billing accounts.
• Design project boundaries around environment, application, team, data sensitivity, or lifecycle.
• Use folders to apply policies consistently across departments, environments, or compliance zones.
• Distinguish IAM allow policies from broader governance controls such as organization policies.
• Use labels and tags for cost allocation, automation, and policy targeting.
• Recognize when Shared VPC helps centralize network control while allowing service-project autonomy.
• Plan separate projects for production, nonproduction, shared services, security tooling, and logging when appropriate.
• Identify when centralized logging, monitoring, and security visibility are required.
• Avoid granting broad roles at the organization level unless there is a clear administrative need.
• Design guardrails that let teams move quickly without bypassing security or compliance requirements.

Governance Decision Points

Identity, IAM, and Access Design

PCA scenarios often test whether you can enforce least privilege without making the environment unmanageable.

Can You Do This?

• Choose predefined roles when they match the job function.
• Use custom roles only when predefined roles are too broad or too narrow.
• Grant permissions to groups or service accounts rather than individual users where practical.
• Distinguish user identities, workload identities, and service accounts.
• Avoid using long-lived service account keys unless there is a justified need.
• Use service account impersonation where it improves control and auditability.
• Apply IAM at the narrowest practical resource scope.
• Recognize when IAM Conditions can limit access by context.
• Design access for CI/CD systems without overprivileged deployment accounts.
• Use Cloud Audit Logs to investigate who did what, where, and when.

Common IAM Traps

Network Architecture

Networking questions often combine service selection with routing, security, hybrid connectivity, and availability.

Core Network Checklist

• Design VPCs, subnets, and IP ranges for growth and isolation.
• Distinguish regional subnets from global VPC concepts.
• Use firewall rules or firewall policies to control ingress and egress.
• Explain when private IP connectivity is required between services.
• Use Cloud NAT for outbound internet access from private resources when appropriate.
• Use Private Google Access for private access to Google APIs from supported private resources.
• Use Private Service Connect when private service access or producer-consumer patterns are required.
• Select appropriate Google Cloud load balancing patterns for global, regional, internal, external, HTTP(S), TCP, or UDP needs.
• Design DNS resolution for cloud, hybrid, and multi-project environments.
• Compare Cloud VPN and Cloud Interconnect for hybrid connectivity requirements.
• Recognize when network peering, Shared VPC, or private connectivity patterns are more suitable than public exposure.
• Include network observability and logging in production designs.

Networking Decision Table

Network Decision Flow

    flowchart TD
	    A[Workload needs connectivity] --> B{User-facing?}
	    B -->|Yes| C{HTTP or HTTPS app?}
	    C -->|Yes| D[External HTTP(S) load balancing, TLS, Cloud Armor as needed]
	    C -->|No| E[Choose appropriate external TCP/UDP load balancing pattern]
	    B -->|No| F{Hybrid with on-premises?}
	    F -->|Yes| G{Dedicated/private capacity required?}
	    G -->|Yes| H[Cloud Interconnect design with redundancy]
	    G -->|No| I[Cloud VPN design with dynamic routing as needed]
	    F -->|No| J{Private Google/service access needed?}
	    J -->|Yes| K[Private Google Access or Private Service Connect pattern]
	    J -->|No| L[Internal load balancing, VPC routing, firewall controls]

Compute and Application Platform Selection

A professional cloud architect should choose compute based on workload characteristics and operational model, not preference.

Compute Selection Matrix

Can You Do This?

• Choose between VMs, containers, and serverless based on operations, portability, startup time, scaling, and runtime control.
• Design stateless application tiers for horizontal scaling.
• Identify when a stateful workload needs persistent disks, managed databases, or externalized session state.
• Explain managed instance group health checks and rolling update behavior.
• Compare GKE and Cloud Run for container workloads.
• Use queues, Pub/Sub, or task patterns to decouple bursty workloads.
• Plan blue-green, canary, and rolling release patterns.
• Recognize when specialized legacy requirements justify Compute Engine instead of a higher-level managed service.
• Include logging, metrics, error reporting, and tracing in the application design.

Compute Scenario Cues

Storage and Database Selection

Storage questions often hinge on data model, latency, consistency, query pattern, availability needs, and operational burden.

Storage and Database Matrix

Can You Do This?

• Distinguish object, block, file, relational, document, wide-column, cache, and warehouse storage.
• Select Cloud Storage classes and lifecycle policies based on access pattern and retention requirements.
• Choose between Cloud SQL, AlloyDB, and Spanner for relational needs.
• Recognize when BigQuery is for analytics rather than serving low-latency transactional application reads.
• Identify when Bigtable key design affects performance and hotspotting.
• Design backups, snapshots, retention, and restore tests.
• Plan encryption using Google-managed keys, customer-managed keys, or other appropriate controls.
• Avoid placing state on ephemeral compute resources.
• Account for data migration, replication, downtime, and cutover risk.

Database Scenario Cues

Data, Analytics, and AI/ML Workflows

PCA candidates do not need to become data engineers, but they should understand architecture patterns for ingestion, processing, governance, analytics, and machine learning.

Data Platform Checklist

• Choose Pub/Sub for asynchronous messaging and event ingestion.
• Use Dataflow for managed stream and batch processing when Apache Beam-style pipelines fit.
• Use Dataproc when managed Spark/Hadoop ecosystem compatibility is important.
• Use BigQuery for analytics, warehousing, SQL analysis, and BI workloads.
• Use Cloud Composer when workflow orchestration across services is required.
• Recognize when Data Fusion can help with visual data integration patterns.
• Include data governance, cataloging, lineage, and access control using appropriate Google Cloud services.
• Design data lakes with Cloud Storage and analytics layers where appropriate.
• Plan schema evolution, data quality checks, and replay/reprocessing needs.
• Separate operational databases from analytical workloads when query patterns conflict.
• Account for batch versus streaming latency requirements.
• Use Vertex AI when ML training, deployment, or model operations are part of the architecture.
• Protect sensitive data with IAM, encryption, masking/tokenization patterns, and audit logging.

Data Pipeline Decision Table

Security Architecture

Security readiness means layering controls across identity, network, data, application, supply chain, and operations.

Security Checklist

• Apply least privilege with IAM and service account design.
• Use organization policies to prevent risky configurations where appropriate.
• Protect secrets with Secret Manager rather than embedding them in code or images.
• Use Cloud KMS and customer-managed keys when key control is required.
• Understand when hardware-backed key options or external key management patterns may be relevant.
• Use Cloud Armor for web application and DDoS-related edge protection patterns.
• Use VPC Service Controls for reducing data exfiltration risk around supported services.
• Use Security Command Center for security visibility and findings.
• Enable and route audit logs for security review and incident investigation.
• Protect container supply chains with secure image storage, scanning, Binary Authorization, and policy checks where appropriate.
• Segment networks and workloads based on trust boundaries.
• Plan secure administrative access without exposing management interfaces unnecessarily.
• Include incident response, alerting, forensics, and evidence retention in the design.

Security Control Selection

Reliability, SLOs, and Operations

A PCA-ready architecture includes failure handling, observability, deployment safety, and operational ownership.

Reliability Checklist

• Convert availability goals into SLOs and operational requirements.
• Identify single points of failure in compute, network, database, and deployment processes.
• Design across zones or regions when business requirements justify it.
• Match disaster recovery design to RTO and RPO.
• Use health checks and autoscaling where appropriate.
• Plan backup, restore, and failover tests.
• Use managed services to reduce operational risk when suitable.
• Design graceful degradation for partial outages.
• Include retry, timeout, circuit breaker, and idempotency patterns for distributed systems.
• Use queues or event-driven designs to absorb bursts and isolate failures.
• Ensure monitoring covers symptoms users experience, not only resource utilization.
• Define alert policies that are actionable and routed to the right team.
• Use Cloud Logging, Cloud Monitoring, Error Reporting, Trace, Profiler, and audit logs appropriately.

Useful SLO Formulas

Allowed unavailable time can be estimated from the SLO target and the measurement period.

Error budget is the portion of unreliability allowed by the SLO.

Use these formulas for reasoning about tradeoffs, not as a substitute for official exam instructions.

Failure-Mode Checklist

Migration and Modernization

Migration questions often require balancing risk, speed, cost, and business continuity.

Migration Checklist

• Assess application dependencies before choosing a migration strategy.
• Identify data gravity, network constraints, downtime tolerance, and cutover complexity.
• Choose rehost, replatform, refactor, replace, retain, or retire based on business value and risk.
• Use phased migration when dependency or downtime risk is high.
• Plan identity, networking, logging, monitoring, and security before moving workloads.
• Select data transfer methods based on data volume, timeline, network capacity, and sensitivity.
• Use database migration tooling or replication patterns where appropriate.
• Validate performance and reliability after migration.
• Plan rollback or coexistence during transition.
• Modernize only where there is a clear business or operational benefit.
• Avoid refactoring everything during a time-sensitive migration unless required.
• Include training and operational readiness for teams moving to Google Cloud.

Migration Decision Table

DevOps, Delivery, and Implementation Planning

The architect role includes designing how systems are built, deployed, secured, and operated.

Delivery Checklist

• Use source control and automated build pipelines.
• Store artifacts in Artifact Registry or an appropriate managed repository.
• Use Cloud Build, Cloud Deploy, or compatible CI/CD tooling based on organizational standards.
• Use infrastructure as code for repeatable environments.
• Separate duties between developers, deployers, operators, and security reviewers where required.
• Include automated testing, policy validation, and security scanning.
• Use canary, blue-green, or rolling deployments based on risk and platform support.
• Define rollback procedures before production release.
• Avoid manual production changes except through controlled break-glass processes.
• Design environment promotion from dev to test to staging to production.
• Ensure deployment service accounts have only required permissions.
• Capture release metrics and operational signals.

Artifacts and Commands to Recognize

PCA is primarily architecture-focused, but you should recognize the purpose of common operational artifacts and commands.

gcloud projects get-iam-policy PROJECT_ID
gcloud compute firewall-rules list
gcloud logging read 'severity>=ERROR' --limit=50
kubectl describe pod POD_NAME
terraform plan

Be ready to explain what each helps inspect:

Cost Optimization and Financial Governance

Cost questions usually test whether you can reduce waste while preserving required reliability and performance.

Cost Checklist

• Use budgets, alerts, and cost reporting for visibility.
• Apply labels and project structure for attribution.
• Right-size compute resources based on observed utilization.
• Prefer autoscaling where demand varies.
• Choose storage classes and lifecycle policies based on access patterns.
• Avoid overprovisioned always-on resources for bursty workloads.
• Use committed use or similar planning only when usage is predictable enough to justify it.
• Optimize BigQuery queries with partitioning, clustering, and query discipline where applicable.
• Delete unattached, stale, or abandoned resources.
• Consider managed services when operational savings outweigh service cost.
• Include cost review in architecture decisions, not only after deployment.

Cost Trap Table

Scenario-Based Decision Checks

Use this section to test whether you can make PCA-style architecture decisions quickly.

Workload Placement

• Is the workload stateless or stateful?
• Does it require a specific OS, runtime, or network agent?
• Does it need Kubernetes APIs or just container execution?
• Is traffic steady, spiky, event-driven, or batch?
• Who will operate the platform: app team, platform team, or Google-managed service?
• What is the rollback strategy?
• What monitoring proves the workload is healthy?

Data Placement

• Is the workload transactional, analytical, streaming, or archival?
• What consistency model does the application need?
• What are the dominant queries and access paths?
• What latency is acceptable?
• How will data be backed up, restored, archived, or deleted?
• Who can access sensitive data?
• Does the data need to stay in a particular location or security boundary?

Security and Access

• Who are the human administrators?
• Which workloads call which APIs?
• Are service account keys avoidable?
• Are secrets stored outside code and images?
• Are public endpoints required?
• Are logs sufficient for investigation?
• Is there a break-glass process?

Reliability and Operations

• What happens if a zone fails?
• What happens if a region fails?
• What happens if the database is unavailable?
• What happens if a deployment is bad?
• What happens if traffic doubles suddenly?
• What alerts wake someone up?
• What runbook tells them what to do?

Common Weak Areas

Final-Week Checklist

Architecture Review

• Review the main Google Cloud compute, storage, database, networking, security, and operations services.
• Make a one-page service selection matrix from memory.
• Practice explaining tradeoffs out loud: “I choose this because…”
• Revisit every missed practice question and classify the miss: service knowledge, requirement reading, or tradeoff judgment.
• Review high-availability and disaster recovery patterns without memorizing unsupported numeric guarantees.
• Review IAM scope and service account patterns.
• Review hybrid networking and private access patterns.
• Review database selection scenarios.
• Review logging, monitoring, alerting, and incident response design.

Scenario Practice

• For each scenario, write the top three requirements before choosing an answer.
• Identify the constraint that eliminates each wrong option.
• Watch for answers that are technically possible but operationally excessive.
• Watch for answers that are cheap but fail reliability, security, or compliance needs.
• Practice choosing the most managed option when it satisfies requirements.
• Practice choosing more control when the scenario explicitly requires it.
• Time yourself on long scenario questions so you do not overanalyze.

Exam-Day Readiness Signals

You are close to ready when you can:

• Choose between similar services without relying on keyword matching.
• Justify architecture decisions using business and technical requirements.
• Recognize overengineered and undersecured answers.
• Design identity, network, data, and operations together rather than separately.
• Handle unfamiliar details by returning to first principles.
• Explain why a managed service reduces operational risk.
• Explain when a lower-level service is justified by control, compatibility, or migration constraints.

Practical Next Step

Use this Exam Blueprint to score your readiness by area. Pick the three weakest rows in the readiness table, review those topics, then answer scenario-based practice questions focused only on those gaps before doing another mixed review.