CodePipeline 的跨帳戶與跨區域部署是任何現實企業 CI/CD 架構的核心，且 DOP-C02 對此項目的測試比任何其他認證都更嚴格。考試很少只考單帳戶、單區域的管線。相反地，它會將你置於一個情境中：一個工具帳戶 (tooling account) 託管 CodePipeline，一個開發帳戶產生建置成品 (artifacts)，一個暫存 (staging) 帳戶核准發佈，以及一個分佈在兩個區域以進行災難復原的生產帳戶 —— 並詢問哪些成品儲存桶、KMS 金鑰、IAM 角色和核准門檻的組合能安全地引導建置從提交到全球推出。
本指南專注於專業級機制：CodePipeline 中哪個 IAM 角色執行哪個動作、KMS 授權 (grants) 如何實現跨帳戶成品解密、為什麼管線接觸到的每個區域都必須存在成品儲存桶、何時使用 CloudFormation StackSet 動作與按區域部署動作，以及如何分層手動核准以滿足變更管理政策而不破壞自動化。讀完本指南後，你應該能夠在 30 秒內看穿任何 CodePipeline 跨帳戶問題並識別出缺失的部分 —— 幾乎總是 KMS 金鑰政策、儲存桶政策或 AssumeRole 信任關係之一。
為什麼跨帳戶跨區域管線在 DOP-C02 中佔主導地位
跨帳戶管線不只是學術上的優化。它們是任何具備一定規模的 AWS 組織強制執行職責分離 (separation of duties) 的方式：建置在一個帳戶執行，整合測試在另一個帳戶執行，而生產環境則位於只有少數人可以部署的地方。考試深知這一點，因此 CodePipeline 問題幾乎從不描述單帳戶拓撲。跨區域則增加了災難復原的維度 —— 管線必須原子性地將相同的版本部署到 us-east-1 和 eu-west-1，否則必須以營運人員可以偵測並重新執行的方式失敗。
有三種力量將這些設計推向課程大綱的頂端。第一，最小權限 IAM：只有具備明確 sts:AssumeRole 權限的管線服務角色，以及目標帳戶中匹配的信任政策，才能跨越邊界推送成品。第二，加密的成品傳輸：成品儲存桶使用客戶受管的 KMS 金鑰進行加密，每個消耗成品的帳戶都需要該金鑰的明確授權。第三，區域成品儲存桶：CodePipeline 不會即時跨區域串流成品；它要求在管線涉及的每個區域都有一個成品儲存桶，並按需複寫物件。遺漏其中任何一項，管線都會失敗並出現晦澀的 AccessDenied 錯誤，這正是題目喜歡設下的煙霧彈。
- 工具帳戶 (Tooling account)：擁有 CodePipeline 管線、CodeBuild 專案和中央成品儲存桶的帳戶；有時稱為 CI/CD 帳戶或管線帳戶。
- 目標帳戶 (Target account)：CodePipeline 透過跨信任邊界假定的動作角色部署資源的任何帳戶。
- 管線服務角色 (Pipeline service role)：由 CodePipeline 本身假定的 IAM 角色；控制管線可以列出、啟動和停止哪些動作。
- 動作角色 (Action role)：為特定階段動作假定的 IAM 角色，通常位於另一個帳戶，權限僅限於該動作。
- 成品儲存桶 (Artifact bucket)：每個區域一個 S3 儲存桶，用於存放管線的輸入/輸出成品；使用客戶受管 KMS 金鑰加密以進行跨帳戶讀取。
- KMS 授權 (KMS grant)：KMS 金鑰上的臨時或持久許可，允許另一個委託人 (通常是跨帳戶角色) 解密成品物件。
- 跨區域動作 (Cross-region action)：其
region欄位與管線主區域不同的 CodePipeline 動作；CodePipeline 會將輸入成品複寫到目標區域的成品儲存桶。 - 手動核准動作 (Manual approval action)：一種管線動作類型，會暫停執行，直到具有
codepipeline:PutApprovalResult權限的委託人核准或拒絕。 - 參考：https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-how-it-works.html
白話文解釋 CodePipeline 跨帳戶與跨區域
跨帳戶與跨區域的 CodePipeline 機制比較抽象，因為有太多移動組件 (IAM, KMS, S3, 區域) 同時互動。以下三個類比可以讓你掌握其中的權衡。
類比 1：國際郵政系統
想像一家跨國快遞公司將密封包裹從東京倉庫運送到倫敦和法蘭克福的分支機構。成品儲存桶就是區域分揀中心 —— 東京有一個，倫敦有一個，法蘭克福有一個。CodePipeline 是坐在東京的首席物流規劃師，決定哪些分揀中心接收包裹副本以及按什麼順序接收。KMS 金鑰是包裹上的火漆封印；只有主金鑰已註冊 (KMS 授權) 的分揀中心才能開啟並驗證它。管線服務角色是規劃師的徽章 —— 它讓規劃師可以指示分揀中心移動包裹，但不允許規劃師親自拆封。跨帳戶動作角色是倫敦或法蘭克福的當地快遞員許可證；規劃師短暫遞出許可證 (AssumeRole)，快遞員將包裹遞送給客戶 (目標服務，如 CloudFormation 或 CodeDeploy)。
跨區域複寫就像是海運 vs 空運：當你要求東京在法蘭克福部署時，規劃師會先將包裹副本從東京中心運送到法蘭克福中心，然後派遣當地快遞員。如果你忘記將法蘭克福註冊為分揀中心，包裹就永遠不會到達 —— 管線失敗並顯示 Artifact bucket does not exist in region。
類比 2：連鎖飯店的主金鑰架構
想像一家總部位於紐約、在新加坡和都柏林設有分店的連鎖飯店。中央成品儲存桶是總部在紐約的安全文件庫。KMS 客戶受管金鑰就是主金鑰 (master key)；它保存在總部，但會向特定的分店經理發出授權 (grants)，以便他們讀取密封信封 (成品)。當新的政策備忘錄 (建置成品) 發佈時，總部將其放入文件庫，然後派人 (跨區域複寫) 將密封副本送往新加坡和都柏林。分店經理 (即動作角色) 使用主金鑰副本開啟信封並執行操作 (建立 CloudFormation 堆疊、執行 CodeDeploy 部署)。如果總部撤銷了分店經理的授權，信封在到達時將無法解密 —— 這完美說明了為什麼 KMS 金鑰政策是跨帳戶管線失敗最常見的原因。
手動核准動作是區域總監的加簽 —— 備忘錄已送達，但暫停執行，直到總監簽署。這直接對應到生產環境部署的治理。
類比 3：大使館外交郵袋
外交郵袋從一個國家的使館運送到另一個國家，密封且神聖不可侵犯。CodePipeline 管線是母國的大使館 (工具帳戶)。郵袋的外交豁免權是 KMS 加密加上儲存桶政策 —— 只有具備正確憑證的接收使館才能開啟。AssumeRole 信任是雙邊條約：A 國的管線獲得明確許可 (在 B 國的 IAM 中簽署)，可以踏上 B 國領土並為了有限的目的代表 B 國行事。沒有條約 (信任政策)，就無法遞送外交郵袋。跨區域複寫是目標區域的二級使館 —— 外交郵袋不會直接在首都之間飛行；它們會先經過該國國內的使館。這正是為什麼 CodePipeline 每個區域都需要一個成品儲存桶。
郵政系統類比最適合視覺化複寫和 KMS 授權。連鎖飯店主金鑰類比最能對應 KMS 金鑰政策問題。使館類比則是題目強調信任、手動核准和治理時的正確模型。參考：https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-create-cross-account.html
工具帳戶與目標帳戶拓撲
典型的 DOP-C02 拓撲是一個工具帳戶、多個目標帳戶、多個區域。工具帳戶託管管線定義、中央成品儲存桶、客戶受管 KMS 金鑰以及編譯和測試程式碼的 CodeBuild 專案。目標帳戶託管應用程式基礎設施 (CloudFormation 堆疊、ECS 服務、Lambda 函數)，以及管線在跨越信任邊界時假定的各動作角色。
為什麼要這樣拆分？爆炸半徑：如果工具帳戶受損，攻擊者可以推送惡意成品，但如果動作角色權限嚴密，他們無法直接修改生產環境運行。可稽核性：每次跨帳戶 AssumeRole 都會在兩個帳戶中發出 CloudTrail 事件，提供清晰的稽核追蹤。成本分攤：生產資源帳單會落在生產帳戶，與工具帳戶分開。合規性：職責分離控制 (PCI, SOC2) 要求執行管線的團隊與授權生產變更的團隊不是同一組人。
反模式：將 CodePipeline 直接放在生產帳戶中。對於 5 人的初創公司很方便，但只要題目提到「合規性」或「職責分離」，考試就會將其標記為錯誤。
必要 IAM 角色及其邊界
CodePipeline 的跨帳戶工作由四個不同的 IAM 角色維繫，考試題目喜歡混淆每個角色的功能。
管線服務角色 (Pipeline service role) 位於工具帳戶，由 CodePipeline 本身假定。其職責是協調：叫用 CodeBuild、從 CodeCommit/S3 讀取原始碼、列出管線狀態，以及最重要的一點：假定目標帳戶中的動作角色。其信任政策將 codepipeline.amazonaws.com 列為委託人 (principal)。其權限政策包含對目標帳戶中動作角色 ARN 的 sts:AssumeRole。
動作角色 (Action role) 位於目標帳戶，並信任管線服務角色的 ARN (而不僅僅是帳戶)。它承載範圍狹窄的權限：對於 CloudFormation 部署動作，它具備 cloudformation:CreateStack, cloudformation:UpdateStack 以及範本所需的所有資源權限。對於 CodeDeploy 動作，它具備 codedeploy:CreateDeployment 以及針對 CodeDeploy 服務角色的 iam:PassRole。
CloudFormation 執行角色 (或 CodeDeploy 服務角色) 是第三層 —— 傳遞給部署服務的角色，以便服務可以代表操作員建立資源。其信任委託人是 cloudformation.amazonaws.com (或 codedeploy.amazonaws.com)，而不是管線。
CodeBuild 服務角色授權 CodeBuild 讀取原始碼、編寫日誌和提取基礎映像；這在工具帳戶背景下相關，但容易與管線服務角色混淆。
管線服務角色地位於工具帳戶，授權 CodePipeline 在該帳戶內呼叫 AWS API。動作角色位於目標帳戶，授權單個階段動作。它們的信任關係不同 (codepipeline.amazonaws.com vs 管線服務角色 ARN)。當跨帳戶管線失敗並顯示 User: arn:aws:sts::TOOLING:assumed-role/PipelineServiceRole/... is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::TARGET:role/ActionRole 時，90% 的情況是動作角色的信任政策中缺少管線服務角色 ARN。參考：https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-create-cross-account.html
KMS 金鑰政策與跨帳戶解密
由於成品儲存桶使用客戶受管的 KMS 金鑰加密，每個需要讀取或寫入成品的帳戶都必須被明確授予 KMS 權限。預設的 aws/s3 AWS 受管金鑰無法跨帳戶共享，因此跨帳戶管線必須使用客戶受管金鑰 (CMK)。
CMK 位於工具帳戶。其金鑰政策必須向目標帳戶中的動作角色 (或目標帳戶的根帳戶，配合下游 IAM 過濾) 授予 kms:Decrypt, kms:DescribeKey, 和 kms:GenerateDataKey。未能擴展金鑰政策是第二常見的跨帳戶配置錯誤 —— 成品到達了目標帳戶，但動作角色無法解密它，CloudTrail 會顯示 KMS.AccessDeniedException。
一種簡潔的模式：金鑰政策明確枚舉可以解密的目標帳戶委託人，而動作角色的 IAM 政策則包含對同一個金鑰 ARN 的 kms:Decrypt 允許。雙方都必須同意，就像跨帳戶 S3 存取一樣。
預設的 aws/s3 AWS 受管 KMS 金鑰無法修改，這意味著你無法向跨帳戶委託人授予解密權限。如果題目說「成品儲存桶使用預設的 S3 KMS 金鑰加密」，且管線是跨帳戶的，答案總是「切換到客戶受管的 CMK 並更新金鑰政策」。令人驚訝的是，許多考生記住了 KMS 但忘記了 AWS 受管與客戶受管的區別。參考：https://docs.aws.amazon.com/codepipeline/latest/userguide/concepts-how-it-works.html
跨區域動作機制
當你新增一個其 region 欄位與管線主區域不同的動作時，CodePipeline 不會即時串流成品。它要求你建立一個獨立的目標區域成品儲存桶，並透過管線定義中的 artifactStores 映射進行註冊。CodePipeline 會在叫用動作之前將輸入成品從主區域儲存桶複寫到目標區域儲存桶，然後針對本地副本執行動作。
對設計的影響：管線接觸到的每個區域都需要 (1) 一個成品儲存桶、(2) 一個 KMS 金鑰 (或跨區域共享的多區域 KMS 金鑰)、以及 (3) 將動作角色的信任和權限擴展到這些金鑰和儲存桶。管線定義使用 artifactStores 映射 (每個區域一個項目)，而不是簡單的單一 artifactStore。
在 CodePipeline 發佈後推出的多區域 KMS 金鑰 (Multi-region KMS keys) 簡化了這一點：一個邏輯金鑰複寫到多個區域並具有相同的金鑰 ID，因此你只需編寫一次金鑰政策，並在各處信任相同的 ARN 模式。這是一個常見的 DOP-C02 干擾項模式 —— 考試會問哪種技術能減少多區域管線的營運開銷，多區域 KMS 金鑰通常是正確答案。
CloudFormation StackSets vs 按區域部署動作
對於基礎設施的多帳戶多區域部署，你有兩個主要的管線層級選項。
CloudFormation StackSet 動作 (動作提供者 CloudFormation, 動作模式 CREATE_UPDATE_STACK_SET 或 CREATE_UPDATE_STACK_INSTANCES) 讓單個管線動作在一個步驟中向多個帳戶和區域部署相同的範本。配合服務受管許可和 AWS Organizations，你可以針對整個 OU，當帳戶新增或移除時，StackSets 會自動部署。當相同的範本統一套用於整個機群時 (如 IAM 基準、Config 規則、GuardDuty 啟用)，這是正確的工具。
按區域部署動作是單獨的 CloudFormation 部署動作，每個區域/帳戶組合一個，通常在單個階段中排列為並行動作。當每個區域的參數略有不同 (區域特定的端點 URL、區域特定的 AMI ID、區域特定的核准門檻)，或者當你需要發散到少量目標且 StackSets 難以表達時，這是正確的工具。
當部署在許多目標之間是統一的 (大於約 5 個帳戶/區域) 且理想情況下由 AWS Organizations 驅動時，選擇 StackSets。當部署是非統一的 (不同的參數、不同的核准門檻) 或目標較少且協調複雜性可接受時，選擇按區域動作。考試經常測試邊界情況：1 個帳戶中的 4 個區域使用相同範本 —— StackSets 太過火了，4 個並行動作更簡潔。參考：https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/stacksets-concepts.html
階段之間的手動核准門檻
手動核准是 CodePipeline 內建的動作類型，它會暫停管線，直到具有 codepipeline:PutApprovalResult 權限的委託人提交核准或拒絕。這是控制從暫存到生產環境晉升的標準機制。
核准動作有兩個關鍵屬性。第一，它們可以包含 SNS 通知目標 —— 當動作進入掛起 (pending) 狀態時，會自動觸發電子郵件或聊天通知。第二，它們接受自定義的審查 URL，通常指向儀表板、變更工單或測試報告。
在多帳戶管線中，核准動作本身是工具帳戶的事務 (它位於管線定義中)。被授予核准權限的委託人可以是 CI/CD 負責人、發佈經理或 Lambda 函數 (是的，自動核准是可能的 —— 雖然不常見但合規)。
反模式：將手動核准鏈接到部署之後。核准門檻屬於生產部署階段之前，絕不能在之後。
端到端參考架構
典型的 DOP-C02 跨帳戶管線組裝如下：Source 階段在工具帳戶中從 CodeCommit (或透過 CodeStarConnections 連結 GitHub) 提取。Build 階段執行 CodeBuild 專案，進行編譯、執行單元測試，並產生一個儲存在主區域成品儲存桶中的建置成品。Test 階段使用 CloudFormation 部署動作針對開發帳戶的動作角色部署到開發帳戶。Approval 階段暫停並發出 SNS 通知。Pre-prod 階段使用一組並行的 CloudFormation 部署動作，跨越 us-east-1 和 eu-west-1 區域部署到暫存帳戶，每個動作使用自己的區域成品儲存桶和多區域 KMS 金鑰。Production 階段使用 CloudFormation StackSet 動作部署到生產 OU。
每次跨越邊界的跳轉都由完全相同的原語維繫：動作角色信任政策、KMS 金鑰政策、儲存桶政策。背熟這個形狀，任何跨帳戶管線問題都會變成對題目中缺失原語的快速分級。
對於每個跨帳戶或跨區域動作，驗證這五個部分：
- 目標帳戶中存在動作角色，且信任管線服務角色的 ARN。
- 管線服務角色具備對動作角色 ARN 的
sts:AssumeRole權限。 - KMS 金鑰政策向動作角色授予
kms:Decrypt。 - 成品儲存桶政策向動作角色授予
s3:GetObject。 - 對於跨區域動作，每個目標區域都存在一個成品儲存桶，並已註冊在
artifactStores中。
如果跨帳戶管線問題提到 AccessDenied 錯誤，請在腦中走一遍這個清單，答案幾乎總是這五個之一。參考：https://docs.aws.amazon.com/codepipeline/latest/userguide/pipelines-create-cross-account.html
管線變數、來源動作輸出與參數覆蓋
管線變數讓階段可以將動態值傳遞給後續。來源動作會發出 CommitId, BranchName, RepositoryName 等變數，下游動作可以使用 #{SourceVariables.CommitId} 語法引用。建置動作 (CodeBuild) 可以在 buildspec 中透過 exported-variables 發出自定義變數，並傳遞到後續動作。
對於 CloudFormation 部署動作，管線層級的參數覆蓋 (parameter overrides) 讓你在不修改範本的情況下注入值 —— 典型用法是傳遞區域特定的配置值或帶有建置標籤的映像 URI。典型模式：建置動作匯出 IMAGE_URI，部署動作透過 { "ImageUri": "#{BuildVariables.IMAGE_URI}" } 引用它。
誤用管線變數是一個隱藏陷阱。它們是在管線配置時評估的，而不是運行時，因此變數表達式內的動態 SSM 查找是無效的。對於運行時配置，請在 CloudFormation 範本或 CodeBuild 指令碼中使用 SSM Parameter Store 讀取。
加密、稽核與 CloudTrail 可見性
每次跨帳戶 AssumeRole 都會產生兩個 CloudTrail 事件：一個在工具帳戶中顯示管線服務角色呼叫 sts:AssumeRole；另一個在目標帳戶中顯示動作角色被假定。兩個事件都包含來源身份、目標角色和外部上下文，提供清晰的稽核追蹤。
為了實現端到端的可見性，請配置組織範圍的 CloudTrail 追蹤，將日誌彙整到中央日誌存檔帳戶。CodePipeline 的管線狀態變更也會作為 EventBridge 事件呈現；透過規則將其攝取到 CloudWatch Logs 或 SNS 以進行近乎即時的監控。
務必使用客戶受管 KMS 金鑰加密成品儲存桶，啟用儲存桶版本控制，並套用拒絕未加密 PutObject 的儲存桶政策。考試將「沒有儲存桶層級加密的成品儲存桶」視為安全缺陷。
用於管線生命週期事件的 EventBridge 整合
CodePipeline 會針對階段轉換、動作成功與失敗、手動核准提示和管線執行發出 EventBridge 事件。這些事件驅動了幾種常見的自動化模式：將執行摘要發佈到 Slack 的 Lambda、當生產階段失敗時協調回滾的 Step Functions 工作流程，以及用於值班傳呼的 SNS 主題。
一個微妙的 DOP-C02 模式：生產環境部署失敗應同時觸發 CodeDeploy 自動回滾 (在部署動作層級配置) 以及一條 EventBridge 規則，該規則會建立一個包含值班工程師所需失敗細節的 Systems Manager OpsItem。將原生回滾與 EventBridge 驅動的事故建立相結合，是專業級的預期設計。
常見陷阱模式
考試中會反覆出現幾種配置錯誤。
陷阱 1：忘記 KMS 金鑰政策和 IAM 政策必須達成一致。僅透過 IAM 授予 kms:Decrypt 在跨帳戶時無效；金鑰政策必須明確列出該委託人。
陷阱 2：假設 CodePipeline 可以在沒有目標區域儲存桶的情況下跨區域串流成品。它不能，管線定義將無法通過驗證。
陷阱 3：在跨帳戶管線中對成品儲存桶使用預設的 aws/s3 KMS 金鑰。AWS 受管金鑰無法跨帳戶共享。
陷阱 4：將 CloudFormation 執行角色的信任政策放在管線服務角色上。執行角色信任的是 cloudformation.amazonaws.com，而不是 CodePipeline。
陷阱 5：啟用了來源 S3 儲存桶的跨帳戶存取，但沒有啟用成品 KMS 金鑰的存取。在來源帳戶 S3 中加密的成品在工具帳戶的 CodeBuild 中將無法讀取。
當來源動作是 S3 時，來源儲存桶和成品儲存桶是不同的。成品儲存桶由 CodePipeline 建立 (或由你提供)，存放每個階段的輸出。來源儲存桶位於管線的上游。來源儲存桶上的跨帳戶權限不會自動傳播到成品儲存桶；兩者都需要各自的儲存桶和 KMS 政策。這常讓那些認為「我已經給了來源儲存桶跨帳戶存取權，為什麼部署階段還不成功？」的考生栽跟頭。參考：https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html
常考陷阱（Common Exam Traps）
- 跨帳戶管線中使用 AWS 受管 KMS 金鑰 ——
aws/s3無法共享；必須切換到客戶受管 CMK，並明確在金鑰政策中向目標動作角色授予kms:Decrypt。 - 動作角色信任政策缺少管線服務角色 ARN —— 這是導致
AccessDenied: sts:AssumeRole錯誤最常見的原因；信任列表必須包含管線服務角色，而不僅僅是工具帳戶的根帳戶。 - 目標區域缺少成品儲存桶 —— 跨區域動作要求在
artifactStores中註冊一個區域性的儲存桶；CodePipeline 不會跨區域直接串流成品。 - 核准動作放在生產部署之後 —— 核准門檻應位於部署之前而非之後；放在之後就失去了人工審查的意義。
- 混淆 CloudFormation 執行角色與管線服務角色 —— 執行角色信任
cloudformation.amazonaws.com且是傳遞給 CloudFormation 的；管線服務角色信任codepipeline.amazonaws.com並負責協調管線。委託人與範疇皆不同。
FAQ
Q1：單個管線可以並行部署到 us-east-1 和 eu-west-1 嗎？
可以 —— 在同一個階段內定義兩個區域部署動作，且不重疊 runOrder，CodePipeline 就會並行執行它們。你需要在每個區域都有一個成品儲存桶 (註冊在 artifactStores 中)，且目標帳戶中每個區域都有一個動作角色。
Q2：如何在不破壞運行中管線的情況下輪換客戶受管 KMS 金鑰？ 在 CMK 上啟用自動金鑰輪換；AWS 會每年輪換密碼編譯資料，同時保持金鑰 ARN 穩定。引用該 ARN 的管線、儲存桶政策和 IAM 政策無需更改即可繼續運作。對於手動輪換 (金鑰更換)，在重新加密成品並刪除舊金鑰之前，請先在所有相關政策中授予對新金鑰的存取權。
Q3：CodePipeline 的來源動作角色與動作角色有什麼區別？ 來源動作角色授權管線從來源倉庫 (CodeCommit, S3, 透過 CodeStarConnections 的 GitHub) 讀取。下游階段的動作角色則授權動作在目標帳戶中執行其工作。兩者都可以跨帳戶，兩者都需要明確的信任政策。
Q4：對於跨帳戶場景，何時應使用 CodePipeline V2 而非 V1？
CodePipeline V2 (即 V2 類型管線) 支援管線層級變數、條件執行和按階段觸發。對於跨帳戶跨區域工作，V2 的管線層級變數讓跨階段的參數覆蓋更簡潔。除非現有的自動化依賴於 V1 的行為，否則新管線應預設使用 V2。
Q5：如何防止開發人員在手動核准動作中核准自己的變更？
將 codepipeline:PutApprovalResult 權限綁定到與開發人員角色不同的角色。或者在動作的資源政策中強制執行 aws:PrincipalTag/Role: ReleaseManager。為了更嚴格的執行，使用 AWS Identity Center 許可集將開發人員排除在發佈經理組之外。
Q6：CloudTrail 是否會在兩個帳戶中都捕捉到跨帳戶 AssumeRole 呼叫？
是的。工具帳戶會記錄源自管線服務角色的 sts:AssumeRole；目標帳戶會記錄該角色被假定 (在 userIdentity.sessionContext.sourceIdentity 中可以看到來源 ARN)。透過組織追蹤將兩者彙整到中央日誌存檔，以進行端到端稽核。
Q7：我可以使用 AWS WAF 或 VPC 端點來限制管線核准的來源嗎？
手動核准 API 呼叫通過的是全域 CodePipeline 端點，而不是 VPC 端點 (除非你啟用了 CodePipeline VPC 端點)。結合 VPC 端點政策與 IAM 條件金鑰 (如 aws:SourceVpce 和 aws:SourceIp) 來將核准限制在企業網路內；這是一項專業級的治理模式。
Q8：如果 us-east-1 部署成功但 eu-west-1 失敗，該如何處理部分失敗？ 有兩個選項。(1) 在動作層級使用 CodeDeploy 或 CloudFormation 的自動回滾，使失敗的區域自動回滾。(2) 增加一條 EventBridge 規則來監控動作失敗事件，並觸發 Step Functions 狀態機來回滾先前成功的區域。考試偏向於使用簡單的自動回滾，除非情境明確要求跨區域協調。