ACE 模擬題練習

選 B：組織政策的 constraints/gcp.resourceLocations 能設定支援服務之新資源可建立的位置，並沿資源階層套用。判斷關鍵是統一限制資源位置，而非授予操作權限。A、C 處理 IAM 授權，D 處理網路流量，都不是這項位置限制的對應機制。此限制不是所有服務都支援，也不會自動搬移既有資源；部署前要確認官方支援清單。

選 A：環境支援時，優先改用無金鑰驗證，例如 Compute Engine 的附加服務帳戶、Workload Identity Federation for GKE，或外部工作負載的 Workload Identity Federation。這能減少長期私密金鑰的儲存與輪換負擔。加密檔案或存入 Secret Manager 都沒有消除金鑰本身；若確實無法改用替代方案，仍需另行管理金鑰的保護與輪換。

選 C：本題的 alerts-only budget 只寄送警示，不會自動暫停資源、阻止建立資源或降級服務。若另外設定 Pub/Sub 通知與自動化處理，才會執行你配置的回應。Google Cloud 也提供適用於部分服務的 spend cap budgets；不能把僅提醒預算的行為概括成所有預算都無法限制支出。

選 D：在指定 bucket 授予 roles/storage.objectUser，提供物件建立、讀取、更新與刪除所需權限，不包含刪除 bucket 或更新 bucket 設定的權限。roles/storage.admin 包含 bucket 管理，objectViewer 無法寫入，基本角色 Editor 的範圍過大。Object Admin 另含物件 IAM 等權限；本題沒有這些需求，選 Object User 即可。

選 A：命名 configurations 可保存不同的專案、區域與帳號等設定，以 gcloud config configurations activate NAME 切換目前使用的設定檔，也可用 --configuration=NAME 指定單次命令的設定檔。只修改 project 或 CLOUDSDK_CORE_PROJECT 不會同時切換整組區域與帳號設定。環境變數可以覆蓋個別設定值，但不能取代本題需要的整組命名設定管理。

選 B：先啟用 Cloud Run API，再部署容器。題目已確認 Billing、權限與服務身分，剩下的必要條件是 API。一般部署不要求先建立 VPC 網路；也不能假設所有專案都有 default 網路或預設服務帳戶。Cloud Build 可用於建置映像，但本題映像已建好，不需要再建置。

選 A：Spanner 可透過適合的多區域設定，提供跨區域複寫的分散式關聯式資料庫，並支援強一致性與水平擴展。不能只建立單區域實例就宣稱具有跨區域保護。Cloud SQL 的讀取副本不是同一種分散式寫入架構；Bigtable 是寬欄式資料模型，Firestore 是文件型模型。Bigtable 也有 GoogleSQL 查詢介面，因此不能用「不支援 SQL」排除它；本題關鍵是關聯式資料模型與所需的部署能力。

選 D：用 Standard 處理第一年的頻繁讀取，再由 Object Lifecycle Management 依物件年齡轉換儲存類別。A、B、C 都只指定單一類別，沒有提供依年齡自動轉換。本題已給定成本試算結果；實務上仍須比較儲存、讀取、操作與最短儲存期間費用，不能只憑「偶爾讀取」就判定 Standard 最便宜。生命週期規則處理類別轉換，不等於防止文件在保留期間被刪除。

全球外部應用程式負載平衡器（global external Application Load Balancer，舊稱 HTTP(S) Load Balancer）提供全球 Anycast IP、自動將流量路由到最近的健康後端、內建 CDN 和 SSL 終止。區域外部應用程式負載平衡器 (A) 只在單一區域運作，不適合全球用戶。內部直通式網路負載平衡器 (B) 只處理 VPC 內部流量，外部用戶無法存取。外部直通式網路負載平衡器 (D) 在第 4 層運作，不支援路徑路由這類第 7 層功能。舊教材裡的 TCP/UDP Network Load Balancer 就是現在的直通式網路負載平衡器。

選 B：主要 IPv4 範圍的前兩個與後兩個位址保留給 Google Cloud。/24 有 256 − 4 = 252 個可用位址，不足 500；/23 有 512 − 4 = 508 個，已足夠。/22 與 /16 也足夠，但不是題目要求的最小範圍。若需要額外成長餘裕，應先明訂需求，再重新計算；不能自行補出題目沒有的條件。這個扣除 4 個位址的規則適用主要 IPv4 範圍，不應套用到所有位址範圍。

選 C：Cloud Run functions（原 Cloud Functions）可搭配 Eventarc，接收 Cloud Storage 物件事件，執行產生縮圖的函式。A 的 VM 與 B 的 GKE 都可實作，但需要額外管理執行環境；D 的 App Engine Standard 不是本題要求的事件函式部署方式。重點是事件來源、觸發設定與函式，而非看到「縮圖」就固定選某個產品。

Cloud Bigtable 專為大規模、低延遲的讀寫工作負載設計，是 IoT 時間序列資料的理想選擇，可處理每秒數百萬次操作。Cloud SQL (B) 在極高寫入量下效能不足且無法水平擴展。Firestore (C) 適合行動/Web 應用的文件資料，不適合高吞吐量時間序列。Memorystore (D) 是記憶體快取，不適合持久化大量時間序列資料。

選 D：Cloud Run 服務支援自動擴展至零，且不必自行管理 VM 或叢集。最低實例數與計費模式要依工作負載設定。縮到零不代表整個專案免費：映像儲存、日誌、網路或其他相依服務仍可能計費。A、C 需要管理 VM 或 GKE 執行環境；B 的 App Engine Flexible 不提供相同的 scale-to-zero 模型。

選 C：GKE Autopilot 由 Google 管理節點配置、擴展及修補等基礎設施工作。團隊仍要管理應用程式、Pod 資源需求、權限與工作負載設定。Standard 的自動升級不會免除所有節點池配置責任；Shielded Nodes 與 Container-Optimized OS 則不是節點自動配置模式。計費依一般用途或特定硬體工作負載而異，不能把所有 Autopilot 工作負載都說成按 Pod 實際用量計費。

gcloud app services set-traffic --splits 可以精確控制各版本的流量分配比例，實現金絲雀部署。先用 --no-promote 部署 v2，再用 set-traffic 分流。--promote (A) 會立即將所有流量切到新版本。--stop-previous-version (C) 會停止舊版本。instances set-traffic (D) 不是有效的指令。

選 C：設定 Pub/Sub 訊息事件的觸發器。Cloud Run functions 的事件觸發透過 Eventarc 設定，仍需確認觸發器、服務身分與呼叫權限。A 是 HTTP 請求來源，B 是 Cloud Storage 物件事件，D 是 Firestore 文件事件；事件來源要符合題目指定的 Pub/Sub 主題。

選 A：Terraform state 將設定中的資源與實際資源及屬性連結，支援規劃與變更管理；它不是每個資源此刻狀態的即時監控畫面。B 的語法驗證、D 的 provider 快取都不是主要用途。C 的憑證儲存不是 state 的主要目的，但 state 可能包含密碼、金鑰或其他敏感屬性，因此仍須保護存取與儲存，不能宣稱「state 不含秘密」。

Managed Instance Group (MIG) 使用 Instance Template 自動建立和管理相同的 VM，提供自動修復、自動擴展和滾動更新。Unmanaged Instance Group (A) 不提供自動管理功能。Sole-Tenant Node (B) 用於獨佔實體主機，不是自動管理。Instance Schedule (D) 用於排程啟停 VM，不是自動擴展。

選 D：在本題指定支援 Live Migration 且政策為 MIGRATE 的情境，平台將 VM 移到另一台主機，避免因主機維護而重開機。這不是所有 VM 的通用行為，也不保證應用完全沒有可察覺的延遲。Spot、某些 GPU 或其他不支援即時遷移的機型，須依其維護政策與支援限制另行設計。

磁碟快照 (Disk Snapshot) 是 GCP 原生的增量備份機制，支援排程備份，適合定期備份開機磁碟。Machine Image (A) 是完整 VM 設定的備份（包含所有磁碟、中繼資料），適合用於複製 VM 而非例行備份。Custom Image (C) 用於建立可重複使用的開機映像，不支援排程。Local SSD (D) 是本地暫存，不適合當耐久備份；stop／suspend 預設丟棄資料，特定保留 Preview 也不能代替備份。

BigQuery 是最佳選擇，因為它同時滿足長期保存和 SQL 分析兩個需求。透過 Log Router 的 Sink 可以將日誌匯出到 BigQuery。Cloud Storage (B) 適合長期保存但不支援直接 SQL 分析（需要額外工具）。Pub/Sub (C) 是即時串流，不適合長期儲存。Cloud Spanner (D) 不是 Log Sink 的支援目的地。

Alerting Policy 配合 metric threshold 條件可以監控 CPU 使用率指標，設定閾值（80%）和持續時間（5 分鐘），超過時觸發通知。Uptime Check (A) 用於監控服務可用性（HTTP/TCP），不是 CPU 指標。Dashboard (C) 只是視覺化顯示，不會發送通知。Log-based Metric (B) 用於從日誌建立指標，CPU 使用率是內建指標不需要從日誌擷取。

Surge Upgrade 在升級時額外建立新版本的節點，將工作負載遷移到新節點後再移除舊節點，最大程度減少中斷。直接升級所有節點 (A) 會造成服務中斷。刪除重建叢集 (B) 會導致長時間停機和設定遺失。停止工作負載 (D) 會導致計劃性停機。

選 B：Google Cloud 可隨時回收 Spot VM，工作負載要能從持久化的 checkpoint 恢復，並處理重試。預設關機處理期間是盡力而為、最多 30 秒，不是保證有完整 30 秒存檔。A 的最低執行時間沒有保證；C 的價格相同不正確，但折扣也不應背成固定百分比；D 不會自動把應用資料存到 Cloud Storage。Spot 與舊式 preemptible VM 的限制不同，不能把兩者當成只是名稱改變。

最小權限原則要求只授予完成任務所需的最低權限。建立專用服務帳戶並只授予 Storage Object Viewer 角色，精確符合需求。預設服務帳戶 + Editor (A) 權限過大。個人帳號 (C) 不適合用於服務驗證，且離開團隊後會有問題。公開存取 (B) 是最大的安全風險，任何人都能存取資料。

信封加密 (Envelope Encryption) 是用一個金鑰 (KEK) 來加密另一個金鑰 (DEK)，DEK 用來加密實際資料。好處是：只需將小的 DEK 傳送到 KMS 加密/解密，不需要將大量資料傳送到 KMS。透明加密 (B) 是由平台自動處理的加密（如 Google default encryption）。客戶端加密 (C) 是在上傳前自行加密，但不特指這種雙層金鑰結構。雙重加密 (D) 不是標準術語。

選 B：VPC Service Controls 以服務邊界及存取規則，降低支援服務經由 API 發生跨邊界資料外洩的風險。它補充 IAM，不取代 IAM，也不是所有外洩路徑的保證。A 的 VPC 防火牆不是這種服務 API 邊界；C 的 Sensitive Data Protection（原 Cloud DLP）著重敏感資料檢查與去識別化；D 的 Binary Authorization 著重部署映像信任。仍須確認支援的操作、例外規則與實際資料流。

Admin Activity 審計日誌記錄所有修改資源設定或中繼資料的 API 呼叫，包括 IAM 政策變更。此日誌預設啟用且免費，不可停用。Data Access (B) 記錄讀取資源資料的操作（如讀取 Cloud Storage 物件）。System Event (C) 記錄 Google 系統自動產生的事件。Policy Denied (D) 記錄因安全政策被拒絕的存取。

VPC 防火牆規則按優先級數字評估，數字越小優先級越高。規則 B（優先級 900）比規則 A（優先級 1000）先被評估，且規則 B 拒絕所有流量，所以 HTTPS 請求會被拒絕。GCP 不會提示衝突 (B)，規則按優先級順序評估。HTTPS 沒有預設允許 (D)。

選 D：Workload Identity Federation for GKE 讓 Pod 使用 Kubernetes 服務帳戶身分取得短效憑證，再依 IAM 授權存取 Google Cloud 資源。可直接將資源權限授予該身分，也可在需要時使用 IAM 服務帳戶模擬，不一定要把每個 KSA 都綁定到 GSA。A 仍需管理長效金鑰；C 的共用節點身分不利於逐個工作負載控管；B 的 ConfigMap 不適合承載秘密。

選 A：資料夾是組織與專案之間的分組層級，建在組織底下，可依部門把專案分組。在資料夾授予的 IAM 角色與設定的組織政策會由底下的專案繼承，之後放進該資料夾的專案也一樣，還能把資料夾的管理角色委派給部門管理員。B 會把公司拆成互不相屬的組織，無法由單一組織集中治理。C 的標籤用於分類資源與拆分費用，不會讓 IAM 角色或組織政策沿階層繼承。D 把資源合併到單一專案後，就無法依部門分別套用組織政策或委派專案管理；網路標記只用來指定防火牆規則與路由的套用對象。

選 D：Billing Account User 的用途就是把專案連結到帳單帳戶，權限範圍很小；與 Project Creator 搭配時，使用者可以建立連結到該帳單帳戶的新專案。A 的 Billing Account Administrator 也能連結專案，但同時能管理付款方式與帳單帳戶上其他人的角色，超出題目限制。B 的 Billing Account Viewer 只能檢視費用與交易資訊，不能連結或取消連結專案。C 的 Billing Account Costs Manager 負責預算與費用資料匯出，同樣不能連結專案。連結時專案端也要有對應權限，例如專案的 Owner 或 Project Billing Manager。

選 C：Cloud Billing 匯出至 BigQuery 會在一天之中自動把用量、費用等明細資料匯出到你指定的 BigQuery 資料集，之後就能用 SQL 查詢並接上報表工具。A 的預算與提醒只在花費達到門檻時通知，不提供可查詢的費用明細。B 是人工作業，不符合自動持續更新的要求。D 匯出的是 Cloud Audit Logs，記錄誰執行了哪些操作，不含費用資料。官方建議在建立帳單帳戶時就啟用匯出，才能取得較完整的資料。

選 B：Cloud NAT 的 Public NAT（閘道設定在 Cloud Router 上）讓沒有外部 IP 的資源能對網際網路發起連線，而且只為已建立連線的回應封包轉譯位址，不允許外部主動連入，符合只出不進的需求。A 的 Private Google Access 只讓沒有外部 IP 的 VM 連到 Google API 與服務，無法連到第三方套件庫。C 的 VPC Network Peering 提供的是兩個 VPC 網路之間的內部 IP 連線，不提供網際網路出口。D 違反不得配置外部 IP 的要求。

選 D：PITR 可以把實例還原到指定的時間點，因此能回到 14:05 事故發生前；PITR 一律會建立新的實例，不會覆寫原本的實例，取回資料後再決定如何切換。A 的 HA 會把所有寫入同步複寫到兩個 Zone，刪除動作在待命實例上一樣生效，容錯移轉只能應付實例或 Zone 故障。B 的讀取副本是主要實例的副本，主要實例上的變更幾乎即時套用過去，升級後資料同樣已被刪除。C 只能回到 02:00，會遺失之後約 12 小時的正常交易，而且還原作業會覆寫目標實例上的所有資料。

選 B：IAP TCP forwarding 可以為沒有外部 IP 的 VM 提供管理連線。防火牆只需允許 35.235.240.0/20（IAP 用於 TCP 轉送的來源範圍）連入，並在 IAM 授予工程師 IAP-secured Tunnel User 角色 (roles/iap.tunnelResourceAccessor)，就能用 gcloud compute ssh --tunnel-through-iap 連線；登入 VM 本身仍需要 SSH 存取權限，建議搭配 OS Login。A 違反不得有外部 IP 的規定，還把 SSH 開放給整個網際網路。C 的 OS Login 是用 IAM 控管誰能登入 VM，並不提供連線路徑，筆電仍然無法從網際網路連到 VM 的內部 IP。D 的 Private Google Access 處理的是 VM 對外的連線，同樣不能讓筆電連進 VM。

選 C：CPU 使用率、網路流量這類基本指標在 VM 建立後就能看到，但記憶體與程序的使用率要安裝 Ops Agent 才有（例外：E2 機型另有 Compute Engine 內建的記憶體用量指標）。Ops Agent 把日誌與指標的收集合在同一個代理程式裡，設定好之後也能把 VM 內的應用程式日誌檔送到 Cloud Logging，一次滿足兩個需求。A 的 Cloud Audit Logs 記錄的是 API 操作，裡面沒有作業系統的記憶體用量，無從計算。B 的 VPC Flow Logs 記錄的是網路流量的取樣資訊，與記憶體或應用程式日誌無關。D 只改變 VM 的記憶體大小，不會多出記憶體使用率指標。

選 C：允許政策會沿資源階層向下繼承，資源的有效允許政策是該資源自身政策與上層繼承政策的聯集。這位工程師從資料夾繼承的 Editor 已經包含 Viewer 的權限，在專案再授予 Viewer 只是多餘的綁定，不會縮小權限。A 把下層的授權當成可以覆蓋上層，這不是允許政策的運作方式；B 所說的角色衝突並不存在；D 也不對，政策的效果不會因資源建立的先後而不同。要讓他在 proj-a 只能唯讀，常見做法是移除資料夾層級的綁定，改在需要的專案個別授權。

選 A：自訂角色只能建立在組織或專案層級。建立在組織層級的自訂角色，可以在該組織及其下的資料夾、專案與資源授予，符合定義一次、整個組織共用的需求。B 不可行：官方說明不能在資料夾層級定義自訂角色，要在資料夾使用自訂角色就得定義在組織層級。C 不可行：專案層級的自訂角色只能在建立它的專案內授予，不能授予到其他專案。D 不可行：預定義角色由 Google 建立與維護，使用者不能修改它的權限內容，只能參考它另建自訂角色。

選 D：要把服務帳戶附加到 VM 這類資源，操作者必須對該服務帳戶擁有 iam.serviceAccounts.actAs 權限；Service Account User 角色 (roles/iam.serviceAccountUser) 包含這項權限，而且只授予在 app-sa 這一個服務帳戶上，範圍最小。A 的 Owner 雖然也能完成操作，但權限遠超過需求。B 把授權方向弄反了：那是讓 app-sa 能管理 VM，而不是讓開發人員能使用 app-sa。C 沒有補上附加服務帳戶所需的權限，還多出一把需要保管與輪換的長效金鑰。

選 B：服務帳戶模擬 (impersonation) 讓已通過驗證的主體取得服務帳戶的短效憑證，不需要金鑰。要模擬服務帳戶，主體必須在該服務帳戶上擁有 Service Account Token Creator 角色 (roles/iam.serviceAccountTokenCreator)，gcloud CLI 再以 --impersonate-service-account 旗標指定要模擬的服務帳戶。A 的 Service Account User 只能把服務帳戶附加到資源，官方說明它不能建立短效憑證，也不能使用 --impersonate-service-account 旗標。C 讓個人帳號直接持有部署權限，違反題目要求。D 仍然建立了長效金鑰，違反禁止金鑰的規定。