# Case Study Workbook: Google Cloud Professional Cloud Architect ([Candidate or study group])

> Preparation workbook for the Google Cloud Professional Cloud Architect
> exam. It maps the six sections of the official exam guide (with their
> published weights) to your own evidence, gives a reusable frame for
> analysing any case study (business requirements, technical
> requirements, constraints, current state, proposed architecture,
> service choices, Well-Architected pillar check, security and
> compliance, migration, cost, trade-offs) and works that frame through
> once on a fictional company written for this template. It follows the
> exam guide linked from the certification page as checked on
> 2026-10-23 (successor to guide v6.1, October 2025) and the Google
> Cloud Well-Architected Framework (six pillars). It does not contain
> any text from the official case studies: read them at the source.
> Replace every `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Keep one workbook per candidate or study group. Download the current
  exam guide and the four official case studies from the certification
  page, and record the date you read them in section 3.
- Work through section 2 first: rate yourself against every guide
  subsection, then spend study time in proportion to weight times gap.
- Apply the frame in sections 4 to 12 to each official case study in
  your own words. Do not paste case text into this file; summarise it.
- The worked rows marked *Example* use Halden Cold Chain, a fictional
  company invented for this template. Replace them with your analysis.
- Section 13 is your own practice question log. Write questions
  yourself; never record questions seen in a live exam (the candidate
  agreement forbids it).
- Related library templates: Google Cloud Well-Architected Review
  (`architecture/google-well-architected-review`), Landing Zone Design
  (`architecture/landing-zone-design`), Network Architecture Design
  (`architecture/network-architecture-design`), IAM Solution Design
  (`security/iam-solution-design`), Data Platform Architecture
  (`architecture/data-platform-architecture`).
-->

## Document control

<!-- Guidance: Record which exam guide and which case study versions you studied. Google revises the guide and product names; a workbook built on an old guide misdirects study time. -->

| Field | Value |
|---|---|
| Document ID | [PCA-WB-001] |
| Candidate or study group | [Name] |
| Exam | Google Cloud Professional Cloud Architect (standard exam) |
| Exam guide version studied | [Guide linked on certification page, downloaded YYYY-MM-DD] |
| Case studies studied | Altostrat Media, Cymbal Retail, EHR Healthcare, KnightMotives Automotive |
| Target exam date | YYYY-MM-DD |
| Delivery mode | [Online proctored / Test centre] |
| Version | [0.1] |
| Status | [Draft / In progress / Exam ready / Archived] |
| Owner | [@candidate] |
| Approvers/reviewers | [@mentor], [@study-partner] |
| Last updated | YYYY-MM-DD |
| Classification | [Personal / Internal] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Candidate | [@candidate] | [Ready to book / Not ready] | YYYY-MM-DD |
| Mentor or reviewer | [@mentor] | [Agree / Revise plan] | YYYY-MM-DD |
| Training budget owner | [@manager] | [Approve exam fee / Defer] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@candidate] | First self-assessment against the exam guide |
| 0.2 | YYYY-MM-DD | [@candidate] | *Example:* Frame applied to two official case studies |
| 1.0 | YYYY-MM-DD | [@candidate] | *Example:* All four case studies analysed; readiness gate passed |

## Contents

<!-- Guidance: Keep this list aligned with the headings below. -->

1. [Purpose and exam facts](#1-purpose-and-exam-facts)
2. [Exam guide coverage map](#2-exam-guide-coverage-map)
3. [Case study register](#3-case-study-register)
4. [Analysis frame and worked company](#4-analysis-frame-and-worked-company)
5. [Business and technical requirements](#5-business-and-technical-requirements)
6. [Current state and constraints](#6-current-state-and-constraints)
7. [Proposed architecture and service choices](#7-proposed-architecture-and-service-choices)
8. [Well-Architected pillar check](#8-well-architected-pillar-check)
9. [Security, compliance and AI safeguards](#9-security-compliance-and-ai-safeguards)
10. [Migration plan](#10-migration-plan)
11. [Cost view](#11-cost-view)
12. [Trade-offs and decision log](#12-trade-offs-and-decision-log)
13. [Practice question log](#13-practice-question-log)
14. [Readiness tracker and exam-day plan](#14-readiness-tracker-and-exam-day-plan)
15. [Glossary and references](#15-glossary-and-references)

## 1. Purpose and exam facts

<!-- Guidance: Copy the facts from the certification page on the day you book, because format, price and languages change. The values below were checked on 2026-10-23. -->

This workbook turns the exam guide into a study plan and turns each case study into a structured architecture analysis. The exam rewards candidates who read a business situation, separate what the business needs from what the technology must do, and pick the Google Cloud service that satisfies the stated requirement with the least operational burden. The frame in this workbook trains exactly that habit.

### 1.1 Exam facts as published

| Item | Value as stated on the certification page (checked 2026-10-23) |
|---|---|
| Length | 2 hours (standard exam); 1 hour (renewal exam) |
| Questions | 50 to 60 (standard); 25 (renewal) |
| Question types | Multiple choice and multiple select |
| Case study share | Case study questions are 20 to 30 percent of the standard exam and 90 to 100 percent of the renewal exam |
| Case studies available | 4 available for the standard exam (2 appear in each exam), 2 available for the renewal exam (1 per exam), named in the exam guides |
| Delivery | Online proctored, or onsite at a test centre |
| Fee | USD 200 plus tax (standard); USD 100 plus tax (renewal) |
| Languages | English, Japanese |
| Recommended experience | 3 or more years in industry, including 1 or more years designing and managing solutions on Google Cloud; no prerequisites |
| Validity | 2 years; check the renewal options on the certification page |

### 1.2 How the workbook fits a study cycle

Repeat the loop until the readiness gate in section 14 is met; each pass should shrink the weighted gaps found in section 2.

```mermaid
flowchart LR
  A[Download guide and case studies] --> B[Self-rate every subsection]
  B --> C[Study gaps by weight x gap]
  C --> D[Apply frame to each case study]
  D --> E[Write and answer own practice questions]
  E --> F{Readiness gate met?}
  F -- No --> C
  F -- Yes --> G[Book and sit exam]
```

### 1.3 Rules for this workbook

- Summarise the official case studies in your own words. Keep the official PDFs beside the workbook; do not paste their text here, and do not share copies of them.
- Write every practice question yourself. Do not record or share real exam questions; that breaches the exam agreement and invalidates the certification.
- When a product name in your notes differs from the current guide, use the current guide name and note the old one in brackets. Example: the guide linked in October 2026 uses Gemini Enterprise Agent Platform where guide v6.1 used Vertex AI.

## 2. Exam guide coverage map

<!-- Guidance: Rate yourself 1 (never used) to 5 (designed it in production) per subsection, then compute priority = weight x (5 - rating). Spend the first study weeks on the highest priority rows. The common pitfall is studying favourite products rather than weighted gaps. -->

The guide linked from the certification page on 2026-10-23 gives six sections with approximate weights. The earlier guide v6.1 (October 2025) used slightly different weights and is shown for comparison so that you can spot which version a course was built on.

| Section | Title (short form) | Weight, current guide | Weight, guide v6.1 | Library templates that practise it |
|---|---|---|---|---|
| 1 | Designing and planning a cloud solution architecture | ~25% | ~25% | Google Cloud Well-Architected Review (`architecture/google-well-architected-review`), Application Migration Assessment (`architecture/application-migration-assessment`), Build vs Buy Analysis (`architecture/build-vs-buy-analysis`) |
| 2 | Managing and provisioning a cloud solution infrastructure | ~17.5% | ~18% | Landing Zone Design (`architecture/landing-zone-design`), Network Architecture Design (`architecture/network-architecture-design`), Data Platform Architecture (`architecture/data-platform-architecture`) |
| 3 | Designing for security and compliance | ~17.5% | ~19% | IAM Solution Design (`security/iam-solution-design`), Cloud Security Reference Patterns (`security/cloud-security-reference-patterns`), Data Residency and Sovereignty Assessment (`compliance/data-residency-sovereignty-assessment`) |
| 4 | Analyzing and optimizing technical and business processes | ~15% | ~15% | Disaster Recovery Plan (`ops/disaster-recovery-plan`), FinOps Cost Review (`ops/finops-cost-review`), Stakeholder Register (`project/stakeholder-register`) |
| 5 | Managing implementation | ~12.5% | ~11% | API Management Platform Design (`architecture/api-management-platform-design`), Deployment Runbook (`ops/deployment-runbook`), Migration Wave Plan (`project/migration-wave-plan`) |
| 6 | Ensuring solution and operations excellence | ~12.5% | ~12% | Observability Spec (`ops/observability-spec`), Chaos Experiment (`ops/chaos-experiment`), Error Budget Policy (`ops/error-budget-policy`) |

### 2.1 Subsection self-assessment

Subsection topics are summarised in original short wording. Check the exact scope in the guide.

| ID | Guide subsection (topic in short) | Rating 1 to 5 | Weight x gap | Evidence or study action |
|---|---|---|---|---|
| 1.1 | Infrastructure that meets business requirements: use cases, requirements, continuity, cost, integration, data movement, disposition, success measures | [3] | [50] | [Action] |
| 1.2 | Infrastructure that meets technical requirements: Well-Architected Framework, high availability, scaling, latency, backup, Gemini Cloud Assist | [ ] | [ ] | [Action] |
| 1.3 | Network, storage and compute choices, including AI and ML services | [ ] | [ ] | [Action] |
| 1.4 | Migration plan: integration, assessment with Migration Center, dependencies, licensing impact | [ ] | [ ] | [Action] |
| 1.5 | Future improvements and cloud-first evolution | [ ] | [ ] | [Action] |
| 2.1 | Network topologies: hybrid, multicloud, protection, VPC and load balancing | [ ] | [ ] | [Action] |
| 2.2 | Storage systems: allocation, access, transfer, lifecycle, growth, protection | [ ] | [ ] | [Action] |
| 2.3 | Compute systems: provisioning, Spot versus standard, networking, orchestration, serverless | [ ] | [ ] | [Action] |
| 2.4 | End-to-end ML workflows on Gemini Enterprise Agent Platform (formerly Vertex AI), AI Hypercomputer | [ ] | [ ] | [Action] |
| 2.5 | Prebuilt solutions and APIs with Agent Platform; Model Garden models | [ ] | [ ] | [Action] |
| 3.1 | Security design: IAM, hierarchy, keys and secrets, separation of duties, perimeter controls, remote access, supply chain, securing AI | [ ] | [ ] | [Action] |
| 3.2 | Compliance design: regulation, sensitive commercial data, certifications, audit logs | [ ] | [ ] | [Action] |
| 4.1 | Technical processes: SDLC, CI/CD, root cause analysis, testing, service catalogue, disaster recovery | [ ] | [ ] | [Action] |
| 4.2 | Business processes: stakeholders, change, skills, decisions, customer success, CapEx and OpEx, continuity | [ ] | [ ] | [Action] |
| 5.1 | Advising delivery teams: deployment, API management, test frameworks, migration tooling | [ ] | [ ] | [Action] |
| 5.2 | Working with Google Cloud programmatically: Cloud Shell, SDKs, emulators, Terraform, client libraries | [ ] | [ ] | [Action] |
| 6.1 | Operational excellence pillar principles | [ ] | [ ] | [Action] |
| 6.2 | Observability: monitoring, logging, profiling, alerting | [ ] | [ ] | [Action] |
| 6.3 | Deployment and release management | [ ] | [ ] | [Action] |
| 6.4 | Supporting deployed solutions | [ ] | [ ] | [Action] |
| 6.5 | Quality control measures | [ ] | [ ] | [Action] |
| 6.6 | Reliability in production: chaos, penetration and load testing | [ ] | [ ] | [Action] |

*Example:* subsection 1.1 rated 3 gives 25 x (5 - 3) = 50; subsection 6.3 rated 2 gives 12.5 x 3 = 37.5, so 1.1 is studied first.

## 3. Case study register

<!-- Guidance: Record only the name, the date and version you read, and where your own summary lives. Re-download before the exam: Google replaces case studies when it revises the guide. -->

| Case ID | Official case study | Sector (from the name) | Read on | Own summary written | Frame applied (sections 4 to 12) | Practice questions written |
|---|---|---|---|---|---|---|
| CS-01 | Altostrat Media | Media | YYYY-MM-DD | [Yes / No] | [Yes / Partly / No] | [n] |
| CS-02 | Cymbal Retail | Retail | YYYY-MM-DD | [Yes / No] | [Yes / Partly / No] | [n] |
| CS-03 | EHR Healthcare | Healthcare | YYYY-MM-DD | [Yes / No] | [Yes / Partly / No] | [n] |
| CS-04 | KnightMotives Automotive | Automotive | YYYY-MM-DD | [Yes / No] | [Yes / Partly / No] | [n] |
| CS-EX *(Example)* | Halden Cold Chain (fictional, this template) | Refrigerated logistics | 2026-10-23 | Yes | Yes | 5 |

For each official case study, write a half-page summary in your own words under four headings: what the company sells and to whom, what is broken today, what leadership wants within which time frame, and which rules bind it (regulation, contracts, data location). Then copy only the requirement IDs into the tables in section 5.

## 4. Analysis frame and worked company

<!-- Guidance: Apply the same eleven steps to every case study so that, in the exam, you recognise which step a question is testing. The pitfall is jumping to products before you have listed the requirements and constraints. -->

### 4.1 The eleven-step frame

```mermaid
flowchart TD
  S1[1 Business requirements] --> S2[2 Technical requirements]
  S2 --> S3[3 Constraints]
  S3 --> S4[4 Current state]
  S4 --> S5[5 Proposed architecture]
  S5 --> S6[6 Service choices with rationale]
  S6 --> S7[7 Well-Architected pillar check]
  S7 --> S8[8 Security and compliance]
  S8 --> S9[9 Migration]
  S9 --> S10[10 Cost]
  S10 --> S11[11 Trade-offs]
  S11 -.revisit if a pillar fails.-> S6
```

| Step | Question to answer | Where in this workbook | Typical exam signal |
|---|---|---|---|
| 1 | What outcome does the business pay for? | Section 5 | Words about growth, new markets, customer experience, time to market |
| 2 | What must the system do and how well? | Section 5 | Latency, availability, scale, recovery targets |
| 3 | What cannot change? | Section 6 | Regulation, contract dates, existing licences, skills |
| 4 | What exists today and what hurts? | Section 6 | Data centre, legacy databases, manual operations |
| 5 | What is the target shape? | Section 7 | Diagram questions, "which design best" |
| 6 | Which managed service fits each component? | Section 7 | Choosing between two similar products |
| 7 | Does the design hold up against all six pillars? | Section 8 | Reliability or cost distractors |
| 8 | How is data, identity and AI protected? | Section 9 | Least privilege, perimeter, keys, audit |
| 9 | How do we get there safely? | Section 10 | Order of moves, tooling, cutover |
| 10 | What does it cost and how is cost controlled? | Section 11 | Discounts, Spot, licensing |
| 11 | What did we give up? | Section 12 | "Most cost-effective" versus "most resilient" |

### 4.2 Worked company brief (fictional)

*Example:* Halden Cold Chain is a fictional refrigerated freight company invented for this template. It runs 4,000 temperature-controlled trucks across the European Union and the United States, serving food and pharmaceutical shippers. It operates from two leased data centres; the lease on the larger one ends in 18 months and will not be renewed. Dispatch runs on a containerised Java application on a self-managed Kubernetes cluster; billing and contracts run on an Oracle database on VMware virtual machines; truck telemetry (position, reefer temperature, door events) arrives every 30 seconds through a message broker that drops data at peak. Shippers complain that the tracking portal is slow and that temperature excursion alerts arrive late. The board wants a shipper self-service portal with predicted arrival times and a natural-language assistant that answers "where is my load and is it within temperature". Pharmaceutical customers require audit evidence of temperature history for seven years, and EU shipper data must stay in the EU. The IT team of 25 knows VMware, Java and SQL well and has little cloud experience.

## 5. Business and technical requirements

<!-- Guidance: Write each requirement as one testable sentence with an ID. Mark each as stated (in the case text) or inferred (your reading). Exam answers almost always satisfy a stated requirement; inferred ones break ties. -->

### 5.1 Business requirements

| ID | Requirement | Stated or inferred | Success measure | Priority |
|---|---|---|---|---|
| BR-001 *(Example)* | Exit the larger data centre before the lease ends in 18 months | Stated | Data centre empty by month 18 | Must |
| BR-002 *(Example)* | Give shippers a self-service tracking portal with predicted arrival times | Stated | 70% of status calls deflected to the portal within 6 months of launch | Must |
| BR-003 *(Example)* | Offer a conversational assistant over load status and temperature history | Stated | Assistant answers rated correct in 95% of sampled conversations | Should |
| BR-004 *(Example)* | Reduce late temperature excursion alerts that cause spoiled loads | Stated | Alert raised within 60 seconds of an excursion | Must |
| BR-005 *(Example)* | Keep the IT team productive without a large hiring wave | Inferred | No more than 3 new hires; training plan funded | Should |
| [BR-NNN] | [Requirement] | [Stated / Inferred] | [Measure] | [Must / Should / Could] |

### 5.2 Technical requirements

| ID | Requirement | Traces to | Target | Verification |
|---|---|---|---|---|
| TR-001 *(Example)* | Ingest truck telemetry without loss at peak | BR-004 | 4,000 trucks x 1 message per 30 s, about 133 messages per second average; design for 10x bursts | Load test at 1,400 messages per second |
| TR-002 *(Example)* | Detect temperature excursions in a streaming path | BR-004 | Under 60 s from reading to alert | End-to-end synthetic excursion test |
| TR-003 *(Example)* | Serve the portal with high availability in each geography | BR-002 | 99.9% monthly availability, p95 page under 2 s | Uptime checks and real user monitoring |
| TR-004 *(Example)* | Retain temperature history for pharmaceutical loads for 7 years, immutable | BR-004, CN-002 | Retention lock, audit trail of access | Retention policy review and restore test |
| TR-005 *(Example)* | Ground assistant answers in load and telemetry data only | BR-003 | No answer without a cited record | Evaluation set of 300 questions |
| TR-006 *(Example)* | Recover billing within 4 hours with no more than 15 minutes of data loss | BR-001 | RTO 4 h, RPO 15 min | Annual DR exercise |
| [TR-NNN] | [Requirement] | [BR-NNN] | [Target] | [Method] |

*Example:* 4,000 trucks x 2,880 messages per day (one every 30 seconds) = 11,520,000 messages per day. At about 1 KB per message that is about 11.5 GB per day and about 4.2 TB per year of raw telemetry, so seven years of pharmaceutical history is a storage-class and lifecycle decision, not a database sizing problem.

## 6. Current state and constraints

<!-- Guidance: List what exists and what binds the design. Constraints eliminate answer options faster than requirements do: an option that breaks a constraint is wrong even if it is elegant. -->

### 6.1 Current state

| ID | Component | Today | Pain point | Disposition candidate |
|---|---|---|---|---|
| CUR-001 *(Example)* | Dispatch application | Java containers on self-managed Kubernetes | Cluster upgrades lag; on-call fatigue | Move to managed Kubernetes (replatform) |
| CUR-002 *(Example)* | Billing and contracts | Oracle on VMware virtual machines | Licence cost; DBA bottleneck | Rehost first, then refactor database |
| CUR-003 *(Example)* | Telemetry broker | Self-managed message broker on two servers | Drops messages at peak | Replace with managed messaging |
| CUR-004 *(Example)* | Tracking portal | Monolithic web app polling the dispatch database | Slow at peak; couples portal load to dispatch | Rebuild as stateless services |
| CUR-005 *(Example)* | Reporting | Nightly batch to a reporting database | Data a day old | Replace with a warehouse fed by streams |
| [CUR-NNN] | [Component] | [Today] | [Pain] | [Retain / Rehost / Replatform / Refactor / Replace / Retire] |

### 6.2 Constraints

| ID | Constraint | Source | Effect on the design |
|---|---|---|---|
| CN-001 *(Example)* | Data centre lease ends in 18 months | Business | Speed beats elegance for the first move; rehost what cannot be refactored in time |
| CN-002 *(Example)* | EU shipper data stays in the EU | Contracts and data protection law | Separate EU and US regional deployments; organisation policy restricts resource locations |
| CN-003 *(Example)* | Seven-year immutable temperature history for pharmaceutical loads | Customer quality agreements | Object storage with retention lock; access logged |
| CN-004 *(Example)* | Team skills: VMware, Java, SQL | Organisation | Prefer managed services close to current skills; fund training |
| CN-005 *(Example)* | Existing Oracle licences run for 2 more years | Commercial | Licence impact assessed before any rehost onto new hosts |
| [CN-NNN] | [Constraint] | [Source] | [Effect] |

## 7. Proposed architecture and service choices

<!-- Guidance: Draw the target, then justify each managed service against the requirement IDs. In the exam, the right option usually uses the most managed service that meets every stated requirement; options that add self-managed components without a requirement are distractors. -->

### 7.1 Target architecture

*Example:* the target for Halden Cold Chain separates the telemetry path from the portal path so that a burst of truck messages cannot slow shipper pages, and keeps one deployment per geography to satisfy CN-002.

```mermaid
flowchart LR
  subgraph Edge[Trucks and shippers]
    T[Truck telematics]
    U[Shipper browser and assistant]
  end
  subgraph GC[Google Cloud, one deployment per geography]
    LB[External Application Load Balancer and Cloud Armor]
    RUN[Cloud Run portal and APIs]
    PS[Pub/Sub telemetry topic]
    DF[Dataflow streaming jobs]
    BT[Bigtable latest state per truck]
    BQ[BigQuery history and analytics]
    GCS[Cloud Storage archive with retention lock]
    GKE[GKE dispatch]
    DB[AlloyDB billing after refactor]
    AP[Agent Platform model and grounding]
    VM[Google Cloud VMware Engine for interim Oracle]
  end
  subgraph DC[Remaining data centre until month 18]
    ORA[Oracle source during migration]
  end
  T --> PS --> DF
  DF --> BT
  DF --> BQ
  DF --> GCS
  U --> LB --> RUN
  RUN --> BT
  RUN --> AP
  AP --> BQ
  GKE --> DB
  GKE -.interim.-> VM
  ORA -.HCX migration over Interconnect.-> VM
```

### 7.2 Service choices with rationale

| ID | Component | Chosen service | Alternatives considered | Reason (trace) |
|---|---|---|---|---|
| SVC-001 *(Example)* | Telemetry ingestion | Pub/Sub | Self-managed broker on Compute Engine; Managed Service for Apache Kafka | Fully managed, scales with bursts, no broker operations (TR-001, CN-004); Kafka kept as an option only if partners require the Kafka protocol |
| SVC-002 *(Example)* | Excursion detection | Dataflow streaming | Cloud Run functions per message | Windowed, stateful stream processing with exactly-once semantics for alerts (TR-002) |
| SVC-003 *(Example)* | Latest truck state | Bigtable | Firestore; Memorystore | Low-latency key lookups at high write rates keyed by truck ID (TR-003) |
| SVC-004 *(Example)* | History and analytics | BigQuery | Cloud SQL reporting replica | Serverless analytics over billions of rows, feeds arrival-time models (BR-002) |
| SVC-005 *(Example)* | Seven-year archive | Cloud Storage with Bucket Lock retention policy and Archive class through lifecycle rules | Keep everything in BigQuery | Immutable retention at low cost (TR-004, CN-003) |
| SVC-006 *(Example)* | Portal and APIs | Cloud Run behind the External Application Load Balancer | GKE; Compute Engine managed instance groups | Stateless, scales to zero overnight in each geography, least operations (TR-003) |
| SVC-007 *(Example)* | Dispatch | GKE (Autopilot) | Cloud Run | Existing Kubernetes manifests and long-running workers; managed control plane removes upgrade lag (CUR-001) |
| SVC-008 *(Example)* | Billing database, interim | Google Cloud VMware Engine | Bare Metal Solution; immediate refactor | Fastest exit for Oracle on VMware within 18 months (CN-001); licence review in CN-005 |
| SVC-009 *(Example)* | Billing database, target | AlloyDB for PostgreSQL via Database Migration Service | Cloud SQL for PostgreSQL; Spanner | PostgreSQL skills fit the team; Oracle to PostgreSQL-compatible migration path (confirm the supported source and destination pairs in Database Migration Service documentation); Spanner not justified without global writes (TR-006) |
| SVC-010 *(Example)* | Assistant | Gemini models on Gemini Enterprise Agent Platform, grounded on BigQuery and Bigtable data through an API layer | Self-hosted open model on GKE GPUs | Managed model serving and grounding, no GPU fleet to run (BR-003, TR-005) |
| SVC-011 *(Example)* | Partner APIs | Apigee | Plain load balancer | Shipper API keys, quotas and analytics (BR-002) |
| SVC-012 *(Example)* | Hybrid connectivity | Partner Interconnect with HA VPN as backup | HA VPN only | Bandwidth and stable latency for replication during migration (section 10) |
| [SVC-NNN] | [Component] | [Service] | [Alternatives] | [Reason and trace IDs] |

## 8. Well-Architected pillar check

<!-- Guidance: Test the proposed design against each of the six pillars of the Google Cloud Well-Architected Framework. A design that fails a pillar sends you back to section 7. For a full review use the Google Cloud Well-Architected Review template (`architecture/google-well-architected-review`). -->

| Pillar | Question to ask of the design | Finding | Status | Action |
|---|---|---|---|---|
| Operational excellence | Can the team deploy, observe and roll back each component with automation? | *Example:* Cloud Deploy pipelines for Cloud Run and GKE; dashboards and SLO alerts in Cloud Monitoring | Pass | Write runbooks for the streaming jobs |
| Security, privacy, and compliance | Is access least privilege, is data protected in transit and at rest, are perimeters and audit logs in place? | *Example:* VPC Service Controls around data projects; CMEK in Cloud KMS for the archive; Data Access audit logs on | Pass with action | Add Model Armor screening for the assistant (section 9) |
| Reliability | Does each tier meet its availability and recovery target, including regional failure? | *Example:* Cloud Run is regional and a single-cluster Bigtable instance sits in one zone; a region loss takes the portal down in that geography | Gap | Add a second region per geography for the portal tier, Bigtable replication across two regions |
| Cost optimization | Is each component right-sized, and are discounts and lifecycle rules used? | *Example:* Archive class after 90 days; committed use discounts planned after 3 months of usage data | Pass | Review in section 11 |
| Performance optimization | Do latency and throughput targets hold at 10x load? | *Example:* Bigtable key design by truck ID avoids hotspots only if IDs are not sequential | Pass with action | Hash or reverse truck IDs in the row key |
| Sustainability | Are regions and resources chosen with carbon in mind, and is idle capacity avoided? | *Example:* Cloud Run scales to zero overnight; region choice considers carbon-free energy data | Pass | Check the Carbon Footprint report quarterly |

The framework also offers cross-pillar perspectives (AI and ML, Financial services). Apply the AI and ML perspective to any case study that includes generative AI, as the worked assistant does.

## 9. Security, compliance and AI safeguards

<!-- Guidance: Name the control, the Google Cloud capability that implements it and the requirement or constraint it satisfies. The exam favours preventive, centrally enforced controls (organisation policy, perimeters, least-privilege roles) over per-project manual settings. For detailed design use IAM Solution Design (`security/iam-solution-design`) and Landing Zone Design (`architecture/landing-zone-design`). -->

| ID | Control objective | Implementation | Satisfies | Evidence |
|---|---|---|---|---|
| SEC-001 *(Example)* | Separate EU and US data and keep resources in permitted regions | Folder per geography; organisation policy restricting resource locations; consider Assured Workloads for the EU folder | CN-002 | Policy export, audit of resource locations |
| SEC-002 *(Example)* | Least-privilege human access | Groups from the corporate identity provider federated to Cloud Identity; predefined roles granted to groups at folder level; no basic roles | SEC baseline | Quarterly access review |
| SEC-003 *(Example)* | No long-lived keys in CI | Workload Identity Federation from the CI system; service account impersonation for operators | Supply chain | IAM policy and key inventory showing zero user-managed keys |
| SEC-004 *(Example)* | Exfiltration protection for data projects | VPC Service Controls perimeter around BigQuery, Bigtable and Cloud Storage | CN-002, CN-003 | Perimeter dry-run log, then enforced |
| SEC-005 *(Example)* | Customer-controlled encryption for the archive | CMEK in Cloud KMS, key rotation, separate key admin group | CN-003 | Key usage logs |
| SEC-006 *(Example)* | Admin access to internal tools without VPN | Identity-Aware Proxy with context-aware access | SEC baseline | Access logs |
| SEC-007 *(Example)* | Trusted container images only | Artifact Registry with vulnerability scanning; Binary Authorization on GKE | Supply chain | Admission logs |
| SEC-008 *(Example)* | Prompt and response screening for the assistant | Model Armor templates for prompt injection and sensitive data; Sensitive Data Protection on grounding sources | BR-003, TR-005 | Screening logs, red-team results |
| SEC-009 *(Example)* | Audit trail for pharmaceutical customers | Cloud Audit Logs routed to a locked log bucket in a dedicated project | CN-003 | Log retention configuration |
| [SEC-NNN] | [Objective] | [Implementation] | [Trace] | [Evidence] |

Compliance note: record which laws and certifications the case study names (health records, children's privacy, card data, sovereignty, SOC 2) and which Google Cloud compliance offerings support them. Shared responsibility still applies: the provider's certification does not certify your workload.

## 10. Migration plan

<!-- Guidance: Order the moves by risk and deadline, name the tooling, and plan dependencies, testing and network capacity before the first wave. The exam tests sequencing: assess, build the foundation, migrate low-risk workloads, then the hard ones. -->

| Wave | Scope | Strategy | Tooling | Entry criteria | Exit criteria |
|---|---|---|---|---|---|
| W0 *(Example)* | Discovery and foundation | Assess | Migration Center for inventory and cost estimates; landing zone through Terraform | Sponsor sign-off | Landing zone live, interconnect tested |
| W1 *(Example)* | Telemetry pipeline | Replace | Pub/Sub, Dataflow; dual-publish from trucks during transition | W0 done | 14 days of parallel run with no message loss |
| W2 *(Example)* | Portal and APIs | Refactor | Cloud Run, Apigee | W1 done | Load test at 10x passed; shipper pilot accepted |
| W3 *(Example)* | Dispatch | Replatform | GKE Autopilot; container images rebuilt in Cloud Build | W0 done | Cutover rehearsal passed |
| W4 *(Example)* | Billing interim | Rehost | Google Cloud VMware Engine with VMware HCX | Licence review done (CN-005) | Data centre empty, before month 18 |
| W5 *(Example)* | Billing target | Refactor database | Database Migration Service, Oracle to AlloyDB | W4 stable for 3 months | Reconciliation clean; VMware Engine decommissioned |

Plan cutovers with the Cutover Plan (`project/cutover-plan`) and the Migration Wave Plan (`project/migration-wave-plan`), and reconcile data with Data Migration Reconciliation (`project/data-migration-reconciliation`).

## 11. Cost view

<!-- Guidance: Do not chase exact prices in the exam; know which levers apply. Record the lever, the component it applies to and the condition. Use the FinOps Cost Review (`ops/finops-cost-review`) for a real estimate. -->

| ID | Lever | Applies to | Condition | Expected effect |
|---|---|---|---|---|
| COST-001 *(Example)* | Committed use discounts | GKE nodes, AlloyDB, VMware Engine nodes | Stable baseline after 3 months of data | Lower unit price for the steady base |
| COST-002 *(Example)* | Spot VMs | Nightly model retraining and batch reprocessing | Work can be interrupted and retried | Large discount on interruptible capacity |
| COST-003 *(Example)* | Scale to zero | Cloud Run portal in each geography | Traffic falls overnight | No idle instance cost |
| COST-004 *(Example)* | Storage lifecycle rules | Telemetry archive | Objects older than 90 days rarely read | Archive class price for most of the seven years |
| COST-005 *(Example)* | BigQuery partitioning and clustering | Telemetry history tables | Queries filter on date and truck | Less data scanned per query |
| COST-006 *(Example)* | Licence portability review | Oracle on VMware Engine | Contract terms allow it | Avoid buying new licences during the interim |
| COST-007 *(Example)* | Budgets and alerts per project | All projects | Labels applied by the landing zone | Early warning on overspend |

Business case framing: compare data centre exit costs (lease, hardware refresh avoided, staff time) with the cloud run rate in CapEx and OpEx terms, and state the success measures from section 5 that justify the spend.

## 12. Trade-offs and decision log

<!-- Guidance: State what each decision gave up. Exam questions often contrast "most cost-effective", "least operational overhead", "fastest to implement" and "most resilient"; record which of those each decision optimises. Long-lived decisions belong in an Architecture Decision Log (`architecture/architecture-decision-log`). -->

| ID | Decision | Optimises | Gives up | Revisit when |
|---|---|---|---|---|
| DEC-001 *(Example)* | Rehost Oracle on VMware Engine first, refactor later | Speed to data centre exit | Pays VMware Engine and Oracle costs for a period | Billing refactor ready (W5) |
| DEC-002 *(Example)* | Pub/Sub instead of managed Kafka | Least operational overhead | Kafka protocol compatibility for partners | A partner requires Kafka |
| DEC-003 *(Example)* | Regional deployments per geography, two regions each for the portal | Residency and resilience | Higher cost than a single region | Shipper SLA changes |
| DEC-004 *(Example)* | Managed Gemini models rather than self-hosted models | Time to market, no GPU operations | Less control over model internals and pricing | Volume makes self-hosting cheaper, or a residency rule blocks the managed model |
| DEC-005 *(Example)* | Cloud Run for the portal, GKE for dispatch | Least operations per workload | Two runtime platforms to support | Team skills converge on one |

| Scale test | At 0.1x load | At 10x load |
|---|---|---|
| *Example:* Telemetry path | Same design; costs fall with Pub/Sub and Dataflow autoscaling | Same design; check Bigtable node count and Dataflow worker limits |
| *Example:* Portal | Cloud Run scales to zero; fine | Check per-region quotas and database connection limits |

## 13. Practice question log

<!-- Guidance: Write your own questions in the style of a case study question: a short scenario, four options, one or more correct. Record why each wrong option is wrong; that reasoning is what transfers to the real exam. The pitfall is memorising answers instead of the elimination logic. -->

| ID | Case | Guide section | Stem (own words) | Options | Answer | Why the others are wrong | Result |
|---|---|---|---|---|---|---|---|
| PQ-001 *(Example)* | Halden | 1.3 | Telemetry from 4,000 trucks must be ingested without loss and processed for alerts within 60 s, with the least operations. Which design? | A: Pub/Sub then Dataflow. B: Broker on Compute Engine then cron jobs. C: Direct writes to Cloud SQL. D: Batch uploads to Cloud Storage hourly | A | B adds operations; C does not scale for writes and has no stream logic; D misses 60 s | Correct |
| PQ-002 *(Example)* | Halden | 3.1 | Prevent data in BigQuery from being copied to projects outside the organisation even by users with valid roles. Which control? | A: More restrictive IAM roles. B: VPC Service Controls perimeter. C: Firewall rules. D: CMEK | B | A does not stop a legitimate user copying data out; C does not apply to Google APIs; D protects keys, not data movement | Correct |
| PQ-003 *(Example)* | Halden | 1.4 | The data centre must be empty in 18 months; Oracle runs on VMware. Fastest low-risk first move? | A: Rewrite billing as microservices. B: Rehost to Google Cloud VMware Engine. C: Export to CSV and load to BigQuery. D: Wait for the lease to end | B | A misses the deadline; C breaks the transactional system; D is not a plan | Incorrect, revisit 1.4 |
| PQ-004 *(Example)* | Halden | 2.3 | Nightly model retraining can restart if interrupted. Which compute option is cheapest? | A: Standard VMs with sustained use. B: Spot VMs. C: Sole-tenant nodes. D: Larger committed machine | B | A and D cost more for interruptible work; C is for licensing or isolation needs | Correct |
| PQ-005 *(Example)* | Halden | 3.1 | CI pipelines in an external CI system need to deploy to Google Cloud without stored keys. Which approach? | A: Service account key in CI secrets. B: Workload Identity Federation. C: Shared user account. D: API key | B | A stores a long-lived key; C breaks accountability; D cannot authorise deployments | Correct |
| [PQ-NNN] | [Case] | [Section] | [Stem] | [Options] | [Answer] | [Reasoning] | [Correct / Incorrect] |

## 14. Readiness tracker and exam-day plan

<!-- Guidance: Set the gate before you start, and book the exam only when every row is met. Track the trend over time rather than a single score. -->

### 14.1 Readiness gate

| Criterion | Target | Current | Met |
|---|---|---|---|
| Every guide subsection rated 3 or higher | 22 of 22 | [n] | [Yes / No] |
| Frame applied to all four official case studies | 4 of 4 | [n] | [Yes / No] |
| Own practice questions written per case study | At least 10 | [n] | [Yes / No] |
| Correct rate on own and official sample questions over the last two weeks | [Target you set, e.g. 80%] | [x%] | [Yes / No] |
| Hands-on labs completed in a sandbox project | [List] | [List] | [Yes / No] |

### 14.2 Exam-day plan

- Re-read your own case study summaries the day before, not the product documentation.
- With 120 minutes for 50 to 60 questions, budget about 2 minutes per question; mark long ones for review and return.
- For a case study question, find the requirement ID or constraint that the question touches before you read the options.
- Eliminate options that break a stated constraint, then options that add self-managed components without need, then choose between the remaining ones on the qualifier in the stem (cheapest, fastest, least operations, most secure).
- For multiple-select items, check the stem for the exact number of answers.

## 15. Glossary and references

<!-- Guidance: Keep definitions short and in your own words. List the date you checked each source. -->

### 15.1 Glossary

| Term | Meaning |
|---|---|
| Case study | Fictitious company description published with the exam guide; some questions refer to it |
| Disposition | Decision on what happens to an existing workload: retain, rehost, replatform, refactor, replace or retire |
| CMEK | Customer-managed encryption keys held in Cloud KMS |
| VPC Service Controls | Perimeter around Google Cloud APIs that limits data movement across the boundary |
| Workload Identity Federation | Lets external workloads obtain short-lived Google Cloud credentials without service account keys |
| Grounding | Constraining a model's answers to supplied enterprise data |
| RTO and RPO | Maximum tolerated downtime and maximum tolerated data loss after a failure |
| Stated versus inferred requirement | Written in the case text, versus concluded by the analyst |

### 15.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| Google Cloud, Professional Cloud Architect certification page, cloud.google.com/learn/certification/cloud-architect | Checked 2026-10-23 | Exam facts in section 1.1 |
| Google Cloud, Professional Cloud Architect exam guide (English), linked from the certification page | Downloaded 2026-10-23; no version number printed | Section names, weights, case study names |
| Google Cloud, Professional Cloud Architect exam guide v6.1 (English) | October 2025 | Earlier weights for comparison |
| Google Cloud Well-Architected Framework, docs.cloud.google.com/architecture/framework | Page updated 2026-10-13 | Six pillars and cross-pillar perspectives |
| Google Cloud product documentation for each service named in section 7 | Check at time of study | Service capabilities |

## Standard and licence note

Structure aligned with the section outline and weights of the Google
Cloud Professional Cloud Architect exam guide (as linked from the
certification page on 2026-10-23, successor to guide v6.1 of October
2025) and with the six pillars of the Google Cloud Well-Architected
Framework. Only section names, weights, pillar names and the names of
the official case studies are used; no case study text, exam guide text
or exam questions are reproduced. The analysis frame, the fictional
company Halden Cold Chain and all practice questions are original text
written for this collection. Check the current exam guide, case studies
and product names on the official certification page before use.
Google, Google Cloud and the product names used here are trademarks of
their owners; this template is not affiliated with or endorsed by them.
Template licence: MIT.