8–12 週學習路線圖

先選節奏，不先選考試日期

8、10 或 12 週不是難度等級，也不保證通過。差別只在你需要多少時間補 foundation、做 lab 和修正 decision gap。

Google 對 standard PCA 沒有 prerequisite，但建議有三年以上業界經驗，其中一年以上設計與管理 Google Cloud solution。若實務經驗還少，拉長準備期通常比壓縮閱讀更有效。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

如果工作或家庭讓每週只能投入四小時，就把 10 週計畫拉成 16–20 週。穩定完成「理解 → 實作 → 解釋 → 回想」比趕週數重要。

第 0 週：用診斷找起點

先不要重讀課程，直接做一次 diagnostic：

1. 看官方 standard exam guide，把每個 bullet 標成「能解釋並舉例」「知道名詞」「不熟」。
2. 做官方 sample questions，不查資料；記錄時間、信心和錯因。
3. 選一個你做過的 system，口頭說明它的 requirement、failure mode、identity、network、data、deployment、observability 和 cost。
4. 畫一張簡單架構圖，再寫三個 trade-off 和兩個需要驗證的假設。

最後不是只得到一個分數，而是一張 gap list：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

把最高風險 gap 排進前半段，不必照課號平均分配。

flowchart TB
  D["Diagnostic<br/>Exam guide＋<br/>Sample questions＋<br/>Architecture explanation"] --> G["Gap list<br/>Concept／Boundary／<br/>Operation／Scenario／<br/>Hands-on"]
  G --> R{"Foundation gaps 的<br/>數量與風險？"}
  R -->|"少，已有 GCP<br/>架構／營運經驗"| W8["8-week route<br/>合併<br/>Foundation，<br/>增加 Cases"]
  R -->|"中等，有 Cloud 經驗<br/>但 GCP 不完整"| W10["10-week route<br/>每個 Domain<br/>有 Lab＋<br/>Decision review"]
  R -->|"多，Network／<br/>IAM／Data 尚不穩"| W12["12-week route<br/>前兩週補基礎<br/>並拆開核心 Lab"]
  W8 --> T{"每週可穩定投入<br/>建議時數？"}
  W10 --> T
  W12 --> T
  T -->|"不足"| E["延長週數，不刪掉<br/>Build／Retrieve／Review"]
  T -->|"足夠"| P["把最高風險 gaps<br/>排進前半段"]

每週固定用同一個 learning loop

1. Learn

閱讀本課程對應章節與官方 overview。遇到會變動的 product、quota、SLA、deprecation 和 exam policy，以官方頁面為準。

2. Build

做一個範圍小、能重建的 sandbox exercise。目標不是點完 Console，而是觀察 service behavior、IAM、log、failure 和 cost。

3. Decide

為 lab 寫一份 mini ADR：為何選它、替代方案、限制、驗證結果與 review trigger。

4. Retrieve

關掉筆記，用白紙回答五個 scenario，或向同事解釋「為什麼不選另一個」。Active recall 比重看同一張比較表有效。

5. Review

48 小時後與一週後重做錯題。若只是記得答案字母，不算學會；要能指出動詞、constraint、trade-off 和 evidence。

flowchart TB
  L["Learn<br/>課程＋當期官方文件"] --> B["Build<br/>可重建的小型 Sandbox"]
  B --> D["Decide<br/>Mini ADR＋<br/>Alternatives＋Triggers"]
  D --> R["Retrieve<br/>關筆記回答 Scenarios／<br/>Teach back"]
  R --> V["Review<br/>48 小時＋一週後重做"]
  V --> G{"能說明 Constraint、<br/>Trade-off<br/>與 Evidence？"}
  G -->|"否"| X["分類真正 Gap，<br/>調整下一週比例"]
  X --> L
  G -->|"是"| A["保存 Diagram／ADR／<br/>Runbook／Error log"]
  A --> L

10 週標準路線

這是一份可調整的 base plan。8 週路線可合併第 1／2 週與第 6／7 週；12 週路線則把 network、IAM 和 data 各拆成兩週。

flowchart TB
  W1["Week 1<br/>Requirements／WAF／Migration"] --> W2["Week 2<br/>Compute／Storage／Database"]
  W2 --> W3["Week 3<br/>VPC／Hybrid Network"]
  W3 --> W45["Weeks 4–5<br/>IaC／IAM／Data Security／Compliance"]
  W45 --> W67["Weeks 6–7<br/>Delivery／API／Cost／Performance／SRE"]
  W67 --> W8["Week 8<br/>HA／Backup／DR"]
  W8 --> W9["Week 9<br/>Four Cases＋<br/>Architecture review"]
  W9 --> W10["Week 10<br/>Timed practice＋Error log＋Final gaps"]
  W10 --> G{"Readiness evidence<br/>是否穩定？"}
  G -->|"否"| F["只回補明確 gaps，<br/>必要時延後 Exam"]
  F --> W45
  G -->|"是"| E["Schedule／Take exam"]

第 1 週：需求、WAF 與 migration

閱讀：第 1、2、5、6 課。

交付物：

• 把一個既有系統拆成 business／functional／NFR／constraint／assumption。
• 為兩個 journey 定義 SLI、SLO、RTO 和 RPO。
• 做 dependency map，將 workload 分成 rehost、replatform、refactor、retain／retire 等 disposition；這些是溝通語彙，不是固定模板。
• 寫一個 migration wave、cutover criterion 和 rollback trigger。

通過條件：能說明 WAF 六個 pillar 如何影響同一項決策，而不是每個 pillar 背一個產品。

第 2 週：Compute、storage 與 database

閱讀：第 3、4、9 課。

Hands-on：

• 用相同 container 比較 Cloud Run 與你熟悉的另一種 runtime，觀察 startup、concurrency、identity、network、log 和 scaling。
• 建一個 Cloud SQL sandbox，觀察 connection、backup／PITR 設定和 Query Insights；不需要為練習建立昂貴的跨區資源。

交付物：Compute selection matrix 與 data access／transaction／consistency decision table。

通過條件：給一個 workload 時，能先問 lifecycle、control、protocol、scale 和 team skill，再選 platform；也能說明 replica、backup 和 analytics store 的差異。

第 3 週：VPC 與 hybrid networking

閱讀：第 7、8 課。

Hands-on：在 sandbox 建 VPC、subnet、firewall policy／rule、Private Google Access 與 Cloud NAT 的最小組合，從 VM 或測試 workload 驗證實際 path。若沒有 organization 權限，用 diagram／configuration review 練 Shared VPC 與 hierarchy，不為打卡借用 production 權限。

交付物：

• 一張 north-south／east-west／hybrid data-flow diagram。
• Interconnect、HA VPN、Peering、Private Service Connect 的選型表。
• Route、DNS、firewall、MTU 與 failure test checklist。

通過條件：能清楚區分 Private Google Access、Cloud NAT 和 Private Service Connect 解決的問題。

第 4 週：IaC、resource hierarchy 與 IAM

閱讀：第 11、12 課。

Hands-on：

• 用 Terraform 建立一組低成本 sandbox resource，使用 remote／protected state 的概念，執行 plan、apply、drift observation 和 destroy。
• 建立 test service account，用 impersonation 或 Workload Identity Federation concept 取代下載長效 key；查看 policy troubleshooting／effective access。

交付物：Folder／project／IAM boundary 圖、privileged access workflow 與 Terraform review checklist。

通過條件：能分辨 allow、condition、deny、PAB、organization policy 和 PAM 的用途，也能說明 state／CI identity 如何保護。

第 5 週：Data security、compliance 與 zero trust

閱讀：第 13–15 課。

Hands-on：

• 建 Secret Manager secret，測試 version、rotation workflow 與 audit log。
• 用 test data 練 Sensitive Data Protection inspection，不上傳真實個資。
• 若環境不適合實作 VPC Service Controls，改做 perimeter／ingress／egress threat modeling，避免把自己鎖出 organization。

交付物：Data classification、key／secret lifecycle、control-to-evidence matrix，以及 user／workload／data 三條 access path。

通過條件：不再用「有 CMEK 就合規」或「有 VPC SC 就不會外洩」回答 security scenario。

第 6 週：Delivery、API 與 software supply chain

閱讀：第 16、19 課。

Hands-on：建立一條最小 pipeline，產生 immutable artifact、執行 test／scan，部署到 non-production，做一次 canary 或 controlled rollout，再驗證 rollback 的 application／data 限制。

交付物：

• Trusted source 到 runtime 的 identity／artifact／attestation flow。
• Apigee、API Gateway、Cloud Endpoints／service mesh decision table。
• API contract、authN／authZ、quota、idempotency 和 version policy。

通過條件：能說明 rollout healthy 不等於 user journey healthy，也知道 rollback 不會自動倒轉 database 和 external side effect。

第 7 週：Cost、performance 與 observability

閱讀：第 17、18、20 課。

Hands-on：

• 建一個 latency／error／traffic dashboard 與 actionable alert，讓 log 和 trace 能用 correlation field 串起來。
• 用小型 load test 建 baseline，改一個 cache、query 或 concurrency 參數，記錄 p50／p95／p99、error、saturation 和 cost effect。
• 查看 billing export schema／sample，設計每個 environment 或 business unit 的 allocation query。Budget 是通知機制，不當成硬性支出上限。

交付物：Unit economics、latency budget、SLO／error-budget policy 和 incident runbook。

通過條件：看到 CPU 高不會直接擴機；能從 user symptom 往 trace、log、profile 和 change evidence 調查。

第 8 週：HA、backup 與 DR

閱讀：第 21 課，回顧第 4、7–9 課。

練習：為同一個 application 分別設計 instance、zone、region、corruption 和 credential compromise 的 response。若跨區 lab 成本太高，用 sandbox restore test 加 tabletop failover，仍要量每個步驟時間與缺口。

交付物：Dependency map、backup／replica comparison、failover／failback runbook 和 game-day report template。

通過條件：能說明 Cloud SQL regional HA、cross-region replica、backup vault 各保護什麼，也不使用未測試的固定 RTO／RPO。

第 9 週：四份案例與綜合設計

閱讀：第 22、23 課與四份官方 case PDF。

練習：

• 每份案例做一頁五格筆記，原文 fact 與自己的 hypothesis 分色。
• 每個案例各寫三道不同 action 的題：design、first step、optimize／secure。
• 為 CloudMart 或自己的系統做 15 分鐘口頭 architecture review，讓同事專門挑 assumption 與 failure path。

通過條件：不靠「這家公司就是考某服務」答題，能回到當題 constraint。

第 10 週：計時、錯題與考試準備

閱讀：第 24 課與最新 official exam guide。

安排兩次不同目的的練習：

1. 一次完整計時，校準 pacing、case lookup 和第二輪時間。
2. 一次不計時，逐題寫出其他選項不符合哪個 constraint。

交付物：按 concept／product boundary／operation／reading mistake 分類的 error log，以及最後 gap list。

通過條件不是固定 80% 分數，而是：對高信心題能穩定說明理由；低信心題知道缺哪份 evidence；同一原則換情境後仍答得出來。

Sandbox 的安全與成本規則

Hands-on 不值得拿 production 冒險。開始前先做：

• 使用獨立 sandbox project／billing label，不碰真實 customer data。
• 設 budget alert；記住 budget 通常不會自動封鎖支出。
• 先查 pricing、quota、minimum duration 和 network egress。
• 每個 lab 寫 cleanup list；完成後確認 resource、disk、IP、snapshot、load balancer 和 log sink 是否仍在計費。
• 高成本 GPU、TPU、multi-region database、Interconnect 和 enterprise security feature 可用 architecture review／calculator／small PoC 取代完整部署。
• Terraform destroy 前閱讀 plan，避免共用 state；不要把 credential 寫入 repository 或 shell history。

免費試用與 Free Tier 的額度、產品和條件可能變動，使用前查官方 pricing，不把舊文章中的美元金額當保證。

flowchart TB
  P["建立獨立 Sandbox project<br/>Owner＋Billing label"] --> B["設定 Budget alert<br/>查 Pricing／Quota／Minimum duration"]
  B --> D{"完整 Lab 的成本與權限<br/>是否合理？"}
  D -->|"否"| S["改用 Diagram review／Calculator／<br/>Small PoC／Tabletop"]
  D -->|"是"| I["用 IaC／Cleanup list 部署<br/>不使用真實 Customer data"]
  I --> O["觀察 IAM、Logs、Failure、<br/>Behavior 與 Cost"]
  O --> C["閱讀 destroy plan 後 Cleanup"]
  C --> V["再次檢查 Disk、IP、Snapshot、<br/>Load balancer、Log sink 與 Billing"]
  V --> G{"仍有資源或費用？"}
  G -->|"是"| C
  G -->|"否"| A["保存 Lab evidence 與 Lessons learned"]
  S --> A

推薦資源怎麼用

• Certification page／exam guide：決定範圍、考試規格與四份案例，是優先來源。
• Google Cloud documentation：確認 capability、limitation、deprecation、SLA 和 best practice。
• Google Skills（原 Google Cloud Skills Boost）／official learning path：用 lab 補自己沒有的操作經驗，不必為完成 badge 而全做。
• Well-Architected Framework：用來 review architecture trade-off，不是把六個標題貼到圖旁邊。
• Official sample questions：熟悉題型與文字，不把題數少誤解成完整難度模型。
• 高品質第三方題目：用來找 reasoning gap；若答案與官方文件衝突，以當期官方來源為準。避開 dumps。
• 架構師設計工作坊（站內）：13 個步驟，把自己的案例從情境、SLO 一路寫到 DR 與成本，寫完就是一份 decision artifact。
• PCA 案例研究庫（站內）：四份現行案例各有一頁原創架構分析。先讀官方原文，再把它當成別人的 architecture hypothesis 來對照。
• PCA 雲端架構師之旅（站內）：13 篇系列文，用同一個案例走完整套設計流程，可以搭配工作坊逐步讀。

什麼時候適合預約

可以用以下 readiness evidence 判斷：

• 六個 exam section 都至少有一份可解釋的 decision artifact 或 lab evidence。
• 四份案例能在不看第三方筆記的情況下說出 existing environment、hard constraint 和 business outcome。
• 完整計時練習能做完，還留有檢查未答題與 multiple-select 的時間。
• 最近錯題主要來自少數可列出的 gap，而不是每次換題就換一批盲點。
• 能說明常見 option 為何不適合，不只認得正確產品名稱。

若做不到，就把 exam date 往後移或縮小 gap；這不是退步，而是用 evidence 管理風險。

flowchart LR
  D["六個 Exam sections<br/>都有 Decision artifact／Lab evidence"] --> G["Readiness gate"]
  C["四份 Cases<br/>能說 Existing、Constraint、Outcome"] --> G
  T["Timed practice 做得完<br/>且有第二輪檢查時間"] --> G
  E["Error log 收斂到少數<br/>可命名且可修復 gaps"] --> G
  X["能解釋錯誤選項<br/>違反哪個 constraint"] --> G
  G --> R{"所有 Evidence<br/>最近且穩定？"}
  R -->|"是"| S["Schedule exam<br/>再核對當期 Policy／Delivery"]
  R -->|"否"| F["延後日期或縮小 gap<br/>安排 Build／Retrieve／Review"]
  F --> G

最後 48 小時

• 再次核對官方 exam delivery、身分文件、設備、空間、check-in 與 reschedule 規則。
• 只複習 error log、case 一頁筆記和容易混淆的 product boundary。
• 不在最後一天新開昂貴 lab，也不硬背 quota／SLA 數字；需要記的只有 exam guide 明確要求與穩定原則。
• 準備英文產品詞與題目動詞，避免只是翻譯速度拖慢判斷。
• 正常睡眠，讓注意力能讀完 constraint 和 multiple-select 指示。

通過之後

PCA certification 目前有效兩年。Active certificate holder 在到期前的 renewal eligibility period 可選 shorter renewal exam 或 standard exam；目前 PCA 頁面說明為到期前 60 天起。Renewal 的案例與 GenAI 比重和 standard 很不同，屆時要重新看 renewal guide，不能直接拿這份 standard plan 重刷。

工作上則把這次產出的 ADR、runbook、SLO、cost model 和 threat model 留下來。認證的價值不只是一張證書，而是你已經有一套能把 business goal 轉成 architecture decision、再用 evidence 驗證的方法。

課後檢查

往下看重點之前，先試著回答這幾題；答不出來，括號裡是該回去重讀的那一節。

• 每週的 learning loop 是哪五個動作？只讀不做會少掉哪幾個？（回〈每週固定用同一個 learning loop〉）
• 開 sandbox 之前和做完之後，各要確認什麼？（回〈Sandbox 的安全與成本規則〉）
• 你會用哪些 evidence 判斷可以預約考試了？（回〈什麼時候適合預約〉）

本課重點

• 先做 diagnostic，再選 8／10／12 週；週數可以按生活節奏拉長。
• 每週都包含 learn、build、decide、retrieve 和 review，不只閱讀。
• 用 decision artifact、lab evidence 與錯題原因判斷 readiness，不迷信單一模擬考分數。
• Hands-on 在隔離 sandbox 進行，先看 cost／quota，結束後確認清理。
• 四份案例分開記官方 fact 與自己的 architecture hypothesis。
• 考前重新核對官方規格；價格、語言、policy、Free Tier 與產品能力都可能更新。
• Standard 與 renewal 的內容比例不同，續證時重新依當期 guide 準備。

官方入口

• Professional Cloud Architect certification
• Professional Cloud Architect standard exam guide
• Google Cloud Well-Architected Framework
• Google Skills

完成本課後

先做第 0 週 diagnostic，把前三個 gap 排進行事曆。接著從最影響 architecture decision 的那一項開始，而不是從最容易打勾的章節開始。