授權、IAM policies 與 AccessDenied 排錯是 SCS-C02 Domain 4 的操作核心——這是考試唯一不問「某服務能做什麼」，而是直接問「某支 API 呼叫為何在凌晨三點失敗」的領域。這三個主題並非單一功能，而是一門學科：讀懂一份 policy、預測授權決策的結果，以及將 AccessDenied 錯誤訊息解碼至確切缺少或衝突的 statement。SCS-C02 Task 4.2——「設計、實作與排查 AWS 資源的授權問題」——對此大量出題，因為安全工程師正是團隊在束手無策時首先求助的人。
本文從 Specialty 深度出發，走遍 SCS-C02 所有相關主題：五種 policy 類型（managed、inline、identity-based、resource-based、session）及各自的適用時機；policy 評估演算法中「explicit deny 永遠優先」的規則；四個必要元素（Principal、Action、Resource、Condition）及各自如何造成失敗；ABAC 與 RBAC 的取捨及 session tags 何時能解決 RBAC 難以擴展的問題；最小權限與職責分離設計原則；以及使用 CloudTrail、IAM Policy Simulator 和 IAM Access Advisor 進行深度 AccessDenied 排錯的完整演練。讀完後，你將能對 SCS-C02 任何授權情境快速定位需要修改的 policy 層。
什麼是授權、IAM Policies 與 AccessDenied 排錯？
這三項是安全工程師的核心活動：設計授予正確存取權的 IAM policies、透過正確的掛載點（users、groups、roles、resources、sessions、OUs）實作這些 policies，以及診斷已驗證的 principal 在特定 API 呼叫中收到 AccessDenied 回應的確切原因。涵蓋設計階段（撰寫符合最小權限意圖的 policies）、實作階段（在正確的層掛載）和運維階段（在出問題時解碼 CloudTrail 紀錄）。三個階段都是 SCS-C02 考試範圍，因為安全工程師對每個階段都負有責任。
為何授權、IAM Policies 與 AccessDenied 排錯主導了 Domain 4
Domain 4 佔 SCS-C02 考試 16% 的比重，在 Domain 4 內，授權任務（4.2）與驗證（4.1）共享範圍。這個領域的題目特別具體——不是問你選哪個服務，而是直接給你一段 policy 片段、一份 SCP 和一個 CloudTrail 事件，要你說出呼叫為何失敗或哪個單一修改能讓它成功。這個 domain 是無法靠感覺矇混的；你必須讀得懂 JSON。
授權、IAM Policies 與 AccessDenied 排錯在安全工程師工作流中的位置
安全工程師通常在三個循環中處理這三個主題：設計循環（開發者申請新 role，安全工程師撰寫 policy，Policy Simulator 驗證）、稽核循環（Access Advisor 與 Access Analyzer 發現未使用的權限，安全工程師收緊 policies），以及事件循環（生產環境 AccessDenied 告警，安全工程師拉 CloudTrail，找出缺少的層，在 SLA 內修復）。三個循環都是考試範圍。
白話文解釋：授權、IAM Policies 與 AccessDenied 排錯
授權聽起來很抽象，三個日常類比能讓它具體化。每個類比呈現不同的角度；三個都讀。
類比一——捷運閘門進出管制系統（大眾交通類比）
把台北捷運系統想像成一個複雜的存取管制場景：每個車站是一個 AWS 資源，每張悠遊卡是一個 IAM principal，每個閘門讀卡機評估一次授權決策。IAM 中的授權、IAM policies 與 AccessDenied 排錯，就像捷運系統的層層管制機制。
你的悠遊卡設定檔是 identity policy——它列出你可以進入哪些場域。特定場域的白名單是 resource policy——某些區域還需要額外的准入清單，即使你持有通行証，若場域 policy 未包含你，你仍無法進入（這正是跨帳號存取的機制）。主管機關的全面禁令是 SCP——一條全系統指令，例如「晚上十點後任何人不得進入機房，無論持有何種票證」，該指令凌駕任何正面許可。前台發出的臨時通行証是 session policy——它只能限縮你正常悠遊卡已有的權限；不能擴增。部門主管的職掌上限是 permissions boundary——即使你的主管給了你更廣的職務說明，boundary 仍然限制你的 role 能做的事。
當閘門嗶了紅燈拒絕你時，AccessDenied 排錯就是安全人員的診斷流程：確認你的卡是否在場域的准入清單上（resource policy）、你的卡設定是否允許該場域（identity policy）、是否有全系統規定封鎖此時段（SCP）、你的臨時通行証是否比你的卡更嚴格（session policy），以及你的 boundary 是否把你限制在主管授權範圍以下（permissions boundary）。五個地方要看——而門上任何一個明確的「禁止進入」貼紙（explicit Deny）都會蓋過所有的「允許」印章。
類比二——分層規則的開卷考試（考場規則類比）
想像一場認證考試，五層規則決定你可以帶什麼進考場。考試是 AWS API 呼叫；你是 principal；監考人員是 IAM 授權引擎。
全國考試委員會的禁帶清單是 SCP——委員會全國禁止的物品，任何考場都無法覆蓋（policy 考不得帶手機、智慧型手錶、計算機）。考場的自帶物品清單是 identity policy——考場通常允許的東西（紙本筆記、鉛筆、水瓶）。特定考室的房規是 resource policy——某些考室額外允許耳機或禁止水瓶。監考老師當日的限制是 session policy——監考人員今天可以進一步限制你的允帶物品，即使你的考証說可以，但無法賦予考場禁止的物品。監考員資格標準是 permissions boundary——監考人員的授權本身被資格機構限制著。
當監考人員在門口攔住你（AccessDenied），排錯按層進行：先查全國禁帶清單（SCP explicit Deny——遊戲結束），再查考場清單（identity allow），再查考室規定（cross-account resource allow），再查今日監考指示（session policy 交集），最後查監考員的資格上限（boundary）。五個審查步驟；任何一個明確禁止都讓請求失敗。
類比三——醫院藥物授權系統（醫療工作流類比）
想像一家醫院，護理師想為病患施用一種藥物。護理師是 IAM principal，藥物是 action，病房是 resource，用藥申請是 API 呼叫。授權、IAM policies 與 AccessDenied 排錯對應醫院授權機制。
護理師執照是 identity policy——衛主機關授予護理師施用特定藥物清單的許可。病歷與處方醫囑是 resource policy——病歷必須記載此次的用藥醫囑；沒有醫囑，無論護理師執照怎麼說，都不授權。醫院用藥規範是 SCP——全院禁用的藥物（產科病房禁用嗎啡類）凌駕任何處方。班組長的當日限制是 session policy——流感爆發期間，組長限制各護理師當班可施用的藥物範圍，比平時更窄。護理師執業範疇是 permissions boundary——執照本身限制了護理師 role 永遠能做的事，不論個別處方如何。
當藥物發送系統拒絕請求（AccessDenied），藥師的排錯流程是精確的：拉審計日誌（CloudTrail），確認護理師是否有此藥執照（identity policy）、病歷是否有醫囑（resource policy）、醫院是否已禁用（SCP）、組長今日是否限制（session policy），以及執業範疇是否上限（boundary）。審計日誌是 AccessDenied 排錯的關鍵——它精確記錄哪個檢查失敗了。
安全工程師必須分清楚的五種 Policy 類型
授權、IAM policies 與 AccessDenied 排錯，從辨識你正在讀的是哪一種 policy 類型開始。錯誤判斷類型是 SCS-C02 授權設計錯誤最常見的原因。
Identity-Based Policies——附加在 Principal 上
Identity-based policies 是附加到 IAM user、group 或 role 的 JSON 文件，授予那個身份的權限。Principal 元素是隱式的（就是被附加的身份）。Identity-based policies 有三種子類型：AWS-managed（AWS 精心整理，例如 AdministratorAccess）、customer-managed（你自己可重複使用的 managed policies），以及 inline（匿名、直接嵌入在 user/group/role 中，隨實體刪除而消失）。
Resource-Based Policies——附加在資源上
Resource-based policies 是直接附加在資源上的 JSON——S3 bucket policy、KMS key policy、SNS topic policy、SQS queue policy、Lambda resource policy、Secrets Manager secret policy、ECR repository policy、IAM role trust policy。Resource-based policies 必須包含明確的 Principal 元素（policy 描述誰可以對這個資源操作）。它們是唯一能授予匿名（未驗證）principal 存取的機制，例如 S3 的公開存取。
Permissions Boundaries——Principal 的上限
Permissions boundary 是附加在 user 或 role 上的 managed policy，定義 identity policies 可授予的最大權限。Boundaries 不授予任何東西；它們是上限。有效權限 = identity policy ∩ permissions boundary。Boundaries 是中央安全團隊讓開發者能創建自己的 roles、同時防止權限升級的機制。
Service Control Policies (SCPs)——組織層級的上限
SCPs 附加在 AWS Organizations 的 root、OU 或帳號上。和 boundaries 一樣，SCPs 不授予任何東西——它們定義受影響帳號中 principals 的權限上限。SCPs 不適用於管理帳號（SCS-C02 的經典陷阱）。使用 SCPs 強制執行不可覆蓋的規則：禁止使用核准清單外的區域、禁止停用 CloudTrail/Config/GuardDuty、禁止使用 root 憑證。
Session Policies——在 AssumeRole 時注入
Session policies 透過 Policy 和 PolicyArns 參數，在 sts:AssumeRole、sts:AssumeRoleWithSAML、sts:AssumeRoleWithWebIdentity 或 sts:GetFederationToken 呼叫時以 inline 方式傳入。產生的 session 有效權限 = role 的權限 ∩ session policy。Session policies 無法擴展權限；它們只限縮特定 session 的權限。身份供應商（IdP）常在聯合驗證時注入 session policies，以按使用者縮小廣義 role 的範圍。
Managed vs Inline——跨越類型的區別
Managed 與 inline 是跨越 identity vs resource 的橫切區別。Managed policies 有 ARN、可重複使用，且有版本（最多保留五個）。Inline policies 是匿名的、嵌入在實體中，隨實體刪除。使用 managed 做為共用標準與可重用性；使用 inline 做一次性、緊密耦合且 policy 必須始終跟著實體走的規則。
五種 policy 類型，兩個橫切屬性。 Identity-based、resource-based、permissions boundary、SCP、session policy——這就是五種。Managed vs inline 適用於 identity-based policies。一次 API 呼叫的有效權限，是所有適用層中所有正面授予的交集，任何層中的 explicit Deny 都是決定性的。在嘗試任何 SCS-C02 的 AccessDenied 排錯題目前，請先記熟這個分類法。
Policy 評估邏輯——演算法
IAM policy 評估演算法是 SCS-C02 上最重要的授權概念。把它內化成一個流程圖。
第一步——預設 Deny
每次授權決策都從預設 Deny 開始。沒有任何 policy 授予存取，答案就是否。新的 IAM users、全新帳號、未碰過的 roles——全部預設 Deny。
第二步——評估所有適用的 Policies
對於給定的請求，IAM 收集每一個適用的 policy：principal 帳號鏈上的 SCPs、principal 的 permissions boundary、principal 的 identity-based policies（managed 和 inline）、資源的 resource-based policy（若有），以及附加到當前 session 的 session policy。全部都會被評估；無一跳過。
第三步——Explicit Deny 優先
若任何適用的 policy 包含符合請求的 action、resource 和 condition 的 "Effect": "Deny"，最終決策就是 Deny。任何地方的 allow 都無法覆蓋 explicit Deny。這就是著名的「explicit deny 蓋過 allow」規則，也是 SCP 防護欄的基礎。
第四步——尋找 Explicit Allow
在沒有 explicit Deny 的情況下，IAM 搜尋 explicit Allow。Allow 可以來自任何適用的 policy。對於同帳號存取，identity policy 或 resource policy 其中之一有 Allow 就足夠（大多數服務）。對於跨帳號存取，Allow 必須同時出現在呼叫者的 identity policy 和目標的 resource policy 上。
第五步——套用 SCP 與 Boundary 的上限
即使有 Allow，SCP 也必須允許該 action（或至少沒有拒絕），permissions boundary 也必須允許該 action。SCP 和 boundary 充當過濾器：action 必須被 identity policy 允許，且未被 SCP 拒絕，且未被 boundary 拒絕，且未被 session policy 拒絕。
第六步——最終決策
若所有上限通過且找到 Allow、且任何地方沒有 explicit Deny，結果是 Allow。否則，Deny。完整評估會產生一個 授權決策，當呼叫被記錄時寫入 CloudTrail。
跨帳號的特殊情況
跨帳號存取時，評估在兩個帳號中同時執行。呼叫者帳號評估呼叫者的 identity policy + 呼叫者的 SCP + 呼叫者的 boundary；目標帳號評估目標的 resource policy + 目標的 SCP。兩個帳號都必須說 Allow 且沒有 Deny。這就是為什麼跨帳號 AccessDenied 排錯需要在兩個帳號都查 CloudTrail。
Explicit Deny 是決定性的——沒有例外。 任何單一適用 policy（SCP、boundary、identity、resource、session）中的 explicit Deny，都能覆蓋任意數量的 Allows。這就是為何最安全的防護欄（例如「禁止停用 CloudTrail」）要寫成 SCP 中的 Deny statement——沒有任何權限組合可以覆蓋它。排錯時，永遠先搜尋 explicit Deny；一旦找到，其他層都不重要了。
四個必要 Policy 元素——Principal、Action、Resource、Condition
每個 IAM policy statement 評估四個元素。四個都必須符合，statement 才會適用。AccessDenied 排錯通常最終就是找出哪個元素未能符合。
Principal——誰
Principal 元素指定發出請求的 IAM 身份。在 identity-based policies 中，Principal 是隱式的（policy 附加的實體）。在 resource-based policies 中，Principal 是必要且明確的：帳號 ARN、IAM user ARN、IAM role ARN、AWS 服務主體（例如 lambda.amazonaws.com）、SAML provider、web identity provider，或 "*" 代表任何人。Principal 不符——帳號 ID 錯誤、role 名稱錯誤、role 被重建後有新的內部 ID——是 AccessDenied 的主要原因之一。
Action——做什麼
Action 元素指定 API 操作。使用 "s3:GetObject"、"kms:Decrypt" 等。允許使用萬用字元（"s3:Get*"、"s3:*"）。Action 不符——把 s3:GetObject 寫成應該是 s3:HeadObject 的呼叫、KMS 加密物件時缺少 kms:Decrypt——產生的 AccessDenied 和其他失敗看起來完全一樣，需要 CloudTrail 才能辨識。
Resource——對什麼
Resource 元素指定 AWS 資源 ARN。"arn:aws:s3:::my-bucket/*" 符合 my-bucket 中的所有物件，但 "arn:aws:s3:::my-bucket" 只符合 bucket 本身（用於 ListBucket，不用於 GetObject）。bucket-vs-object ARN 的區別是 S3 上最常見的 AccessDenied 排錯陷阱之一。
Condition——在什麼情況下
Condition 元素限制 statement 適用的條件。Conditions 評估 context keys——aws:SourceIp、aws:MultiFactorAuthPresent、aws:RequestedRegion、aws:PrincipalTag/Team、aws:ResourceTag/Project、s3:x-amz-server-side-encryption 等。Condition 失敗是最隱晦的 AccessDenied 原因：policy 看起來正確，呼叫看起來正確，但 context key 不符（呼叫者來自錯誤的 IP 範圍、請求來自錯誤的區域、缺少 MFA、缺少必要的 tag）。
每個元素如何造成 AccessDenied
AccessDenied 排錯時，一個有用的心理檢查清單：對每個適用的 policy 逐一走遍 Principal、Action、Resource、Condition。Principal 是否符合呼叫者？Action 是否符合 API？Resource ARN 是否涵蓋目標？所有 Conditions 是否都評估為 true？一個元素沒對到就讓 Allow 失效。
Resource ARN 的 bucket-vs-object 陷阱。 arn:aws:s3:::my-bucket 和 arn:aws:s3:::my-bucket/* 不可互換。s3:ListBucket 需要 bucket ARN（沒有 /*）。s3:GetObject、s3:PutObject、s3:DeleteObject 需要 object ARN（/* 或特定 key）。只授予 arn:aws:s3:::my-bucket/* 的 policy 套用到 s3:ListBucket 永遠失敗。CloudTrail 事件顯示 AccessDenied，即使 Action 和 Principal 看起來正確——Resource ARN 就是不涵蓋這個呼叫。SCS-C02 會反覆測試這個不符。
ABAC vs RBAC——選擇授權模型
ABAC（Attribute-Based Access Control）和 RBAC（Role-Based Access Control）是大規模設計 IAM policies 的兩種授權模型。SCS-C02 測試各自的適用時機。
RBAC——按職能設定 Role
在 RBAC 中，你為每個職能定義一個 role（DataEngineer、Auditor、BillingReader），範圍明確到特定資源。加入新專案就要新建 roles 或擴充現有的。加入新區域就要編輯每個受影響的 role。RBAC 起步簡單但擴展性差：100 個專案 × 每個專案 5 個 roles = 要維護 500 個 roles。
ABAC——Principal 的 Tags 符合 Resource 的 Tags
在 ABAC 中，你為 principals 打標籤（PrincipalTag/Team=Alpha、PrincipalTag/Project=PaymentSvc），並以相同方式為資源打標籤（ResourceTag/Team=Alpha、ResourceTag/Project=PaymentSvc）。一個 policy 說「若 PrincipalTag/Team 等於 ResourceTag/Team 則允許。」加入新專案只需對新資源和新使用者打標籤——不需編輯 policy。ABAC 用一到兩個 policies 就能擴展到數千個資源。
Session Tags——從聯合驗證帶入 ABAC
Session tags 在 AssumeRole 時注入屬性，通常由 SAML 或 web-identity IdPs 完成。IdP 包含 https://aws.amazon.com/SAML/Attributes/PrincipalTag:Team 宣告；role 在 assume 時帶著那些 tags 適用於 session。ABAC 加上 session tags 是聯合多租戶存取的標準模式——每個使用者繼承其組織的 team tag，不需要 IAM 管理員維護使用者清單。
何時 RBAC 仍然正確
ABAC 並不總是更好。RBAC 對需要可稽核且穩定的明確指名 principals 的敏感特權 roles（SecurityAuditor、BreakGlass）仍然正確。當授權決策必須精確且可追溯到特定人員時，ABAC 的彈性反而成為負擔。考試的模式：ABAC 用於可擴展的工作負載存取，RBAC 用於特權人員存取。
混合模式
生產環境通常混合兩者：ABAC 用於大量的團隊範圍資源存取，RBAC 用於狹義特權操作，SCPs 作為兩者之上的不可變防護欄。SCS-C02 情境常要求辨識正確答案是組合兩種模型。
ABAC 需要 tag 治理——沒有它，ABAC 就會靜默失敗。 Policy "Condition": {"StringEquals": {"aws:ResourceTag/Team": "${aws:PrincipalTag/Team}"}} 只有在每個資源都正確打標籤，且每個 principal 都帶有相符 tag 的情況下才有效。未打標籤的資源無法存取（無符合）。標籤打錯的資源會被錯誤的團隊存取。安全工程師部署 ABAC 前的先決條件是強制打標籤 policies（SCPs 拒絕建立未帶必要 tag 的資源）加上建立時自動打標籤。SCS-C02 關於 ABAC 遷移的題目幾乎都會問「你必須先實作什麼」——答案是 tag 治理。
最小權限與職責分離
授權、IAM policies 與 AccessDenied 排錯的設計遵循兩個基本原則。兩者都直接在考試中出題。
最小權限——只授予必要的權限
最小權限意味著只授予 principal 執行工作所需的確切權限，不多不少。實作策略：從預設拒絕出發，根據 Access Advisor 數據逐步增加權限，優先使用具體的 Resource ARNs 而非 "*"，優先使用具體的 Action 名稱而非 "s3:*"，盡可能加入 Condition 限制（區域、IP、MFA、要求加密）。
職責分離——無單一人員具有端到端的控制力
職責分離意味著劃分關鍵工作流，使得沒有任何單一 principal 能獨自完成敏感操作。例子：寫入 CloudTrail 日誌的 principal 不能刪除它；審批 IAM role 建立的 principal 不同於使用 roles 的 principal；定義 SCPs 的 principal 不同於撰寫工作負載 policies 的 principal。透過 OU 結構、各功能的獨立 IAM roles，以及阻止工作負載帳號中特權操作的 SCPs 來實作。
Permissions Boundary 作為最小權限的執行工具
Permissions boundaries 是大規模落實最小權限的操作工具。開發者為自助服務的 Lambda、EC2、ECS 建立自己的 roles——但他們建立的每個 role 都必須附加一個 boundary，把權限上限設定在工作負載 roles 允許的範圍內（無 IAM 管理、無 Organizations 操作、無 CloudTrail 控制）。Boundary 是不可移動的上限。
最小權限是迭代的，不是一次完成的。 先給廣一點的權限以解除阻礙，再用 30-90 天的 Access Advisor 數據收緊。Access Advisor 顯示 role 實際使用過哪些 actions；其他都可以移除。IAM Access Analyzer policy 生成能自動化這個過程——指向一個有 CloudTrail 歷史的 role，它就會產生收緊後的 policy。不使用這些工具手動設計最小權限，必然產生過度授權的 roles。
AccessDenied 排錯——解碼錯誤
當 API 呼叫返回 AccessDenied，安全工程師的工作是找出導致拒絕的確切 policy 層。AccessDenied 排錯遵循結構化的流程。
第一步——取得 CloudTrail 事件
拉取失敗呼叫的 CloudTrail 事件。事件包含 eventName、eventSource、errorCode（AccessDenied、AccessDeniedException、UnauthorizedOperation、InvalidClientTokenId）、errorMessage、userIdentity（principal ARN、帳號、類型）、sourceIPAddress、requestParameters（API 參數——bucket、key、role ARN），以及 resources（目標 ARNs）。沒有這個事件，AccessDenied 排錯等於在猜謎。
第二步——仔細閱讀錯誤訊息
AccessDenied 錯誤訊息在 2023-2024 年已有大幅改善，包含了造成拒絕的 policy 類型。現代訊息會說類似「User: arn:... is not authorized to perform: s3:GetObject on resource: arn:... because no resource-based policy allows the s3:GetObject action」或「...with an explicit deny in a service control policy.」仔細閱讀——它告訴你先調查哪個層。
第三步——先查 SCP（Explicit Deny 路徑）
若錯誤訊息提到 explicit deny，先查 SCPs。SCPs 在全組織層級拒絕並覆蓋所有 Allow。常見的 SCP 拒絕模式：action 不在核准的區域、對 root 憑證的操作、對受保護服務的操作（CloudTrail/Config/GuardDuty 的停用）。拉取附加在 principal 帳號鏈（root → OU → account）上的 SCPs，搜尋符合的 Deny statements。
第四步——查 Identity Policy
確認 principal 有 identity policy 授予對該資源的 action。常見缺口：完全缺少該 action、action 萬用字元未涵蓋特定呼叫（s3:Get* 不涵蓋 s3:ListBucket）、Resource ARN 範圍錯誤（object 層級 vs bucket 層級）、Condition 失敗（區域錯誤、缺少 MFA、來源 IP 錯誤）。
第五步——查 Resource Policy（跨帳號）
對於跨帳號呼叫，同時驗證目標的 resource policy。常見缺口：Principal ARN 拼錯、Principal 參照了已重建的舊 role（不同的內部 ID）、Action 缺少 kms:Decrypt 即使物件是加密的、Condition 要求 VPC endpoint 但呼叫來自網路。
第六步——查 Permissions Boundary
若 principal 有 boundary，確認 action 也被 boundary 允許。Boundaries 靜默地限制；即使 identity policy 正確，principal 仍會看到 AccessDenied。
第七步——查 Session Policy
若呼叫是透過帶有 session policy 的 AssumeRole 進行的，確認 session policy 允許該 action。來自 SAML 或 OIDC IdPs 的聯合 sessions 常會注入限制性的 session policies；廣義 role 權限的開發者可能因 IdP 縮小了 session 而收到 AccessDenied。
第八步——用 Policy Simulator 驗證
在腦中用 IAM Policy Simulator 重跑失敗的呼叫——選 principal、選 action、設定 resource ARN 和任何 context keys（來源 IP、MFA、區域）。Simulator 的判決符合真實 IAM 評估的結果，並說明哪個 statement 允許或拒絕了。
現代 AccessDenied 訊息會點名 policy 類型——讀它。 AWS 升級了 AccessDenied 訊息，能識別哪一層造成拒絕：「explicit deny in identity-based policy」、「no resource-based policy allows」、「implicit deny due to no allow」、「explicit deny in a service control policy」。這大幅縮短了 AccessDenied 排錯的時間。舊版錯誤訊息很精簡，需要靠猜；現在的版本直接指出層。SCS-C02 兩種格式都會考——準備好解讀兩者。
針對 AccessDenied 的 CloudTrail 調查模式
CloudTrail 是 AccessDenied 排錯的主力工具。三種查詢模式在 SCS-C02 反覆出現。
模式一——依 errorCode 過濾
在 CloudTrail Lake 或 Athena 中使用 errorCode = AccessDenied（或 AccessDeniedException、UnauthorizedOperation）列出某時間窗口內所有被拒絕的呼叫。依 userIdentity.arn 和 eventName 分組，找出哪些 principals 和哪些 APIs 持續失敗——高頻率的配對是要優先修復的。
模式二——關聯 sourceIPAddress
當呼叫因 aws:SourceIp 的 Condition 失敗時，CloudTrail 事件記錄了實際的來源 IP。對照 policy 中允許的 CIDR——通常 principal 是從不在允許清單中的新 VPN 端點或辦公室網路呼叫的。
模式三——查信任政策失敗
AssumeRole 拒絕以 eventName = AssumeRole 且 errorCode = AccessDenied 呈現。讀取 requestParameters.roleArn 和 requestParameters.externalId。常見原因：呼叫者帳號不在信任政策的 Principal 中、ExternalId 不符、要求 MFA 的 Condition 未滿足、SCP 拒絕 sts:AssumeRole。
模式四——分析唯讀呼叫
失敗的唯讀呼叫（s3:HeadObject、dynamodb:DescribeTable、kms:DescribeKey）常發生在真正的工作負載呼叫之前。一個常見的除錯技巧：Lambda 在 kms:Decrypt 失敗；CloudTrail trail 顯示它先在 kms:DescribeKey 失敗，表示 role 同時缺少兩個 action，不只是 kms:Decrypt。
CloudTrail Lake 用於多帳號查詢
對於全組織的 AccessDenied 排錯，CloudTrail Lake 跨所有成員帳號聯合事件。SQL 式查詢返回跨帳號結果集——對於「查找過去 24 小時內使用者 X 在所有 50 個帳號中的每個 AccessDenied」來說非常珍貴。
CloudTrail 資料事件預設關閉——為 AccessDenied 排錯開啟它們。 管理事件（預設值）擷取控制平面 API 呼叫，但跳過 S3 物件讀取、DynamoDB GetItem、Lambda Invoke 以及類似的高量資料平面操作。若開發者回報 s3:GetObject 上的 AccessDenied 但 CloudTrail 中看不到任何跡象，原因是缺少資料事件設定。透過 CloudTrail trail 或帶有資料事件選擇器的 CloudTrail Lake 事件資料存儲為相關資源啟用資料事件。依資源 ARN 過濾以控制成本。
IAM Policy Simulator 工作流程
IAM Policy Simulator 是安全工程師部署前的驗證工具。SCS-C02 期望熟悉三種工作流程。
工作流程一——在附加前驗證新 Policy
在 Simulator 的 policy 編輯器中撰寫新的 identity policy。選擇你打算授權的 action 和 resource。執行。確認 Allow。然後加入反向測試：選擇你打算拒絕的 action。確認 Deny。這能在投入生產前抓出過於寬泛的萬用字元。
工作流程二——重現開發者回報的 AccessDenied
開發者回報在特定 bucket 上 s3:GetObject 失敗。在 Simulator 中選擇他們的 role，選擇 s3:GetObject，貼入 bucket ARN。設定 context keys 以符合實際呼叫（來源 IP、MFA、請求區域）。執行。Simulator 顯示哪個 statement 符合以及適用的決策——Allow、Implicit Deny 或 Explicit Deny。對照可疑的 policies 交叉比對。
工作流程三——在全組織推出前預測試 Policy 變更
在修改將影響 100 個帳號的 SCP 之前，對現有 roles 的典型 actions 模擬新的 SCP。Simulator 支援在帳號層級附加 SCP 進行 SCP 測試。跑一套常見 actions 的測試，在部署前抓出意外的拒絕。
Simulator 的限制
Simulator 並不評估每個 condition key（某些服務專屬 keys 不支援）。一次只評估一個 principal。不完整地模擬跨帳號呼叫（必須分別模擬呼叫者的 identity policy 和目標的 resource policy）。對於複雜的跨帳號 AccessDenied 排錯，Simulator + 手動評估是組合方法。
IAM Access Advisor——找出未使用的權限
IAM Access Advisor 顯示每個 AWS 服務最後被 principal 存取的時間。它是最小權限清理的操作工具。
Access Advisor 顯示什麼
對於任何 IAM user、group、role 或 policy，Access Advisor 顯示該實體有權限存取的每個 AWS 服務，以及最後存取的時間戳（或「Not accessed in tracking period」——通常 400 天）。較新的服務層級 Action-Last-Accessed 資訊顯示每個 Action 最後被呼叫的時間，而非只是每個服務。
工作流程——收緊過度授權的 Role
為有 AdministratorAccess 或其他廣義 managed policies 的 role 開啟 Access Advisor。查看「Not accessed in tracking period」的服務。這些是移除的候選。建立一個只列出近期有存取記錄的服務的收緊 policy。用收緊的 policy 替換廣義 policy。用 Policy Simulator 確認沒有任何東西壞掉。
結合 Access Analyzer Policy 生成
Access Analyzer policy 生成更進一步：它讀取 role 的 CloudTrail 歷史並生成一個最小權限 policy，精確列出使用過的 actions 和 resources。Access Advisor 顯示最後存取時間戳，Access Analyzer 輸出可直接附加的 JSON。組合工作流程：Access Advisor 用於分類，Access Analyzer 用於生成，Policy Simulator 用於驗證。
限制
Access Advisor 數據有延遲（通常 4 小時）。某些服務不在 action 粒度回報最後存取。Access Advisor 不偵測僅被拒絕或受 condition 限制的 actions；它顯示嘗試的操作，不一定是被授權的。要進行全面的最小權限分析，結合 Access Analyzer 未使用存取發現。
常見授權 Bug 及其修復
五種反覆在 SCS-C02 出現的授權錯誤模式。依症狀辨識它們。
Bug 1——SCP Deny 覆蓋本地 Allow
症狀：principal 有授予 action 的 identity policy，但呼叫被拒絕。CloudTrail 錯誤訊息提到「explicit deny in service control policy」。原因：OU 或帳號層級的 SCP 拒絕該 action——區域限制 SCP、禁止停用 CloudTrail 的 SCP，或 root 憑證封鎖 SCP。修復：確認 action 是否有意被限制；若不是，修改 SCP。Principal 無法在本地覆蓋 SCP。
Bug 2——跨帳號缺少 Resource Policy
症狀：從帳號 A 呼叫帳號 B 的 S3 bucket 返回 AccessDenied。帳號 A 的 role 有允許 s3:GetObject 的 identity policy。原因：帳號 B 的 bucket policy 沒有把帳號 A 的 role 列為 Principal。跨帳號需要雙方。修復：在 bucket policy 中加入一個 Principal 區塊，授予帳號 A 的 role 相關 actions，或以帳號 A 整體作為 Principal 並加 Condition。
Bug 3——AssumeRole 缺少信任政策
症狀：帳號 A 呼叫帳號 B 中 role 的 sts:AssumeRole。CloudTrail 顯示 AccessDenied。原因：帳號 B 的 role 信任政策沒有把帳號 A 列為受信任的 Principal。role 的 identity policy 無關緊要——信任先決。修復：編輯 role 的信任政策，將帳號 A 的 ARN（或特定 role ARN）加入 Principal，並加入適當的 Conditions（aws:PrincipalOrgID、sts:ExternalId、MFA）。
Bug 4——Session Policy 縮減了預期的權限
症狀：聯合使用者的 role 有廣義權限，但使用者在 role 允許的 actions 上收到 AccessDenied。原因：IdP 在 AssumeRoleWithSAML 或 AssumeRoleWithWebIdentity 時注入了限制性的 session policy，把 role 的權限交集到更小的子集。修復：檢查 IdP 的 session-policy 邏輯，並擴展 session policy 或改用不同的 role 附加方式。
Bug 5——Permissions Boundary 靜默上限
症狀：principal 的 identity policy 看起來正確，沒有 SCP 拒絕，沒有 resource policy 問題，但 AccessDenied 返回。原因：附加在 principal 上的 permissions boundary 不包含該 action。修復：若意圖允許，修改 boundary 包含該 action；否則接受上限。Boundary 在許多排錯流程中是看不見的；透過 aws iam get-user --user-name X 或 aws iam get-role --role-name X 明確確認，並查看 PermissionsBoundary。
Permissions boundaries 是靜默的——它們讓 AccessDenied 在不可見的情況下發生。 很多工程師排查了 identity policy + SCP + resource policy 卻完全漏掉 boundary，因為 boundaries 是以獨立欄位附加的，不是 policy 附件。當「看起來正確」的 policy 仍然拒絕時，查看 principal 的 PermissionsBoundary。考試會設置 boundary 就是答案的情境；如果你忘了查它，你就會選錯。
跨帳號授權——雙向決策
跨帳號存取需要雙方都允許。這讓 AccessDenied 排錯的範圍加倍。跨帳號情境的授權是 Domain 4 的熱區。
呼叫者端
呼叫帳號的 principal 必須有 identity policy 允許對跨帳號資源的 action。跨帳號 ARNs 使用目標的帳號 ID——policy 必須參照 arn:aws:s3:::target-account-bucket/* 而非呼叫者的 bucket。呼叫者帳號的 SCPs 不能拒絕該 action。呼叫者的 permissions boundary 必須允許它。
目標端
目標帳號的資源（S3 bucket、KMS key、IAM role）必須有 resource policy 允許呼叫者。對於 S3，這是帶有呼叫者 role ARN 作為 Principal 的 bucket policy。對於 KMS，key policy 必須列出呼叫者。對於 IAM AssumeRole，信任政策必須列出呼叫者。目標端 SCPs 不能拒絕 action——例如，目標端 SCP 拒絕來自組織外帳號的 s3:GetObject 會阻擋來自組織外帳號的呼叫。
雙方都有決定性
與同帳號存取（許多服務只需一方即可）不同，跨帳號永遠需要雙方。SCS-C02 常見問題：「為何帳號 A 的 Lambda 在呼叫帳號 B 的 S3 時收到 AccessDenied，即使 Lambda role 有正確的 policy？」——答案幾乎總是「帳號 B 的 bucket policy 沒有把 Lambda role 列為 Principal。」
KMS 跨帳號是三方問題
對於 KMS 加密的 S3 跨帳號存取，三個地方必須對齊：呼叫者的 IAM policy（允許 kms:Decrypt on key ARN）、目標帳號的 key policy（Principal = 呼叫者，Action = kms:Decrypt），以及目標帳號的 S3 bucket policy（Principal = 呼叫者，Action = s3:GetObject）。若再算上呼叫者端 SCP 和目標端 SCP，就是五個層。AccessDenied 排錯需要有條理地逐一走遍每一個。
跨帳號 AccessDenied？每次都查雙方。 同帳號存取可以只憑 identity policy 或只憑 resource policy 成功（大多數服務）。跨帳號需要雙方明確 Allow 且任何地方沒有 Deny。跨帳號最有效的 AccessDenied 排錯清單：(1) 呼叫者 identity policy，(2) 呼叫者 SCP，(3) 目標 resource policy，(4) 目標 SCP，(5) 任一帳號中的 boundary 或 session policy。因為「呼叫者端的 policy 看起來正確」就跳過目標端，是跨帳號排錯的頭號錯誤。
情境演練——Lambda 讀取另一帳號加密的 S3
SCS-C02 的經典 AccessDenied 排錯情境。端到端走一遍。
情境設定
帳號 A 執行一個 Lambda，需要讀取帳號 B 的 S3 bucket 中的物件。Bucket B 使用帳號 B 的 CMK 做 SSE-KMS 加密。帳號 A 中 Lambda 的執行 role 已被授予相關 ARNs 上的 s3:GetObject 和 kms:Decrypt。
症狀
Lambda 呼叫在函數程式碼層面成功，但讀取 S3 物件返回 AccessDenied。帳號 A 的 CloudTrail 顯示一個 s3.amazonaws.com 事件，errorCode = AccessDenied。
診斷
走完七個查核層：
- 呼叫者 SCP：沒有拒絕
s3:GetObject——確認。 - 呼叫者 identity policy：允許正確 ARNs 上的
s3:GetObject和kms:Decrypt——確認。 - 呼叫者 permissions boundary：不存在，無上限。
- 目標 SCP（帳號 B）：沒有拒絕。
- 目標 bucket policy：缺少——bucket policy 沒有把 Lambda role 列為 Principal。找到第一個缺口。
- 目標 KMS key policy：缺少——帳號 B 的 key policy 沒有列出 Lambda role。找到第二個缺口。
- 目標 session policy：不適用。
修復
在帳號 B，為 bucket policy 加入一個 statement，授予 Lambda role ARN 作為 Principal 的 s3:GetObject。在帳號 B，為 key policy 加入一個 statement，授予同一個 Principal 的 kms:Decrypt 和 kms:DescribeKey。重跑；成功。
教訓
跨帳號加密 S3 永遠需要四個允許點：呼叫者 IAM（S3 + KMS）、目標 bucket policy、目標 key policy。忘記任何一個都產生完全相同的 AccessDenied 症狀。需要在兩個帳號的 CloudTrail 才能看出哪一側失敗了。
情境演練——聯合使用者在 IdP 變更後收到 AccessDenied
SCS-C02 的另一個常見模式。
情境設定
聯合使用者透過企業 IdP 的 SAML 登入。他們 assume 的 role 有廣義權限（PowerUserAccess）。昨天 IdP 團隊更新了 SAML 設定。今天使用者回報在之前能用的 actions 上收到 AccessDenied。
診斷
CloudTrail 顯示 eventName = AssumeRoleWithSAML 成功——聯合驗證有效。但後續的 action 呼叫被拒絕。現代錯誤訊息：「implicit deny — no statements allow this action.」
Role 的 identity policy 未變。SCPs 未變。唯一不同的是 IdP。查看 AssumeRoleWithSAML 的 CloudTrail 事件——responseElements 包含了套用的 session policy。IdP 現在注入一個 SessionPolicy ARN，把 role 限縮到 PowerUserAccess 的一個狹窄子集。
修復
與 IdP 團隊協調。要嘛 (a) 擴展 session policy 以涵蓋使用者需要的 actions，要嘛 (b) 若不需要就移除 session policy 注入。Session policies 無法擴展權限，但可以在 role 的授予範圍內放寬限制。
教訓
Session policies 是 IAM 評估中的第三方變數。當 IdP 驅動的聯合驗證發生變化，AccessDenied 排錯必須包含查看 AssumeRole 事件的 session policy 欄位。很多安全工程師會漏掉這一點，因為 role 本身沒有變化。
SCS-C02 常見授權陷阱
陷阱一——Permissions Boundary 授予權限
錯誤。Boundaries 是上限；它們從不授予任何東西。Identity policy 仍然必須明確允許 action。Boundary 是取交集的。
陷阱二——SCPs 適用於管理帳號
錯誤。SCPs 豁免管理帳號。最佳做法：把工作負載完全放在管理帳號之外。
陷阱三——Resource Policy 單獨授予跨帳號存取
大多數服務都是錯誤的。跨帳號存取需要雙方。例外是 IAM role AssumeRole（信任政策單獨是目標端的跨帳號授予；呼叫者仍然需要 identity policy）。
陷阱四——Implicit Deny 和 Explicit Deny 是一樣的
錯誤。Implicit deny 意味著沒有找到 Allow，可以透過加入 Allow 來覆蓋。Explicit Deny 意味著一個 "Effect": "Deny" statement 符合了，並覆蓋每個 Allow。AccessDenied 錯誤訊息現在區分兩者——讀它們。
陷阱五——Policy Simulator 完整測試跨帳號
部分正確。Policy Simulator 一次模擬一個 principal 的權限。跨帳號需要分別模擬雙方並手動合併結果。
陷阱六——Access Advisor 顯示授權失敗
錯誤。Access Advisor 顯示成功的服務存取。失敗（被拒絕的）呼叫不會出現在 Access Advisor 中。要找被拒絕的呼叫，用 errorCode = AccessDenied 查詢 CloudTrail。
陷阱七——ABAC 消滅了 RBAC
錯誤。ABAC 適合大量存取的擴展；RBAC 對狹義特權 roles 仍然正確。生產環境混合兩者。
陷阱八——Session Policy 能擴展 Role 的權限
錯誤。Session policies 只限縮（與 role 的權限取交集）。它們無法超出 role 的範圍進行授予。
陷阱九——IAM Policies 依順序評估
錯誤。IAM policy 評估是基於集合的，不是有序的。每個適用的 policy 都會被評估；explicit Deny 無論附加順序如何都優先。
陷阱十——Identity Policy 中的 * Resource 包含跨帳號資源
錯誤。Identity policy 中的 "Resource": "*" 意味著 principal 有權限 ARN 的所有資源——但跨帳號目標仍然需要目標的 resource policy 來允許。Identity-policy * 對跨帳號來說是必要但不充分的。
授權心智模型——六個檢查點。 (1) SCP——任何地方的 explicit Deny 都讓請求失敗。(2) Permissions boundary——限制 identity-policy 的授予上限。(3) Identity policy——必須明確 Allow。(4) Resource policy——跨帳號必須明確 Allow。(5) Session policy——取交集，無法擴展。(6) Implicit Deny 預設——任何地方都沒有找到 Allow 就意味著 Deny。對每道授權、IAM policies 與 AccessDenied 排錯題目跑過這六個檢查點，正確答案自然浮現。
關鍵數字與必記授權事實
Policy 類型數量
五種：identity-based、resource-based、permissions boundary、SCP、session policy。Managed vs inline 適用於 identity-based。
評估順序
預設 Deny。Explicit Deny 優先。若無 Allow 則 Implicit Deny。只有在存在適用的 Allow 且沒有 Deny 的情況下才 Allow。
跨帳號規則
雙方必須允許。呼叫者 identity policy 以及目標 resource policy。
AccessDenied 的 CloudTrail 錯誤代碼
AccessDenied、AccessDeniedException、UnauthorizedOperation、Client.UnauthorizedOperation、InvalidClientTokenId（驗證而非授權，但相關）。
排錯工具
CloudTrail（發生了什麼）、Policy Simulator（會發生什麼）、Access Advisor（最後存取數據）、Access Analyzer（外部 + 未使用 + policy 生成）、現代 AccessDenied 錯誤訊息（哪個層拒絕了）。
ABAC 先決條件
Principal 上的 tags、resource 上的 tags、比較 aws:PrincipalTag/X 與 aws:ResourceTag/X 的 policy。聯合 ABAC 使用 IdP 的 session tags。
Boundary 行為
限制 identity policy 授予。歷史上在錯誤訊息中是靜默的，現代訊息中有命名。永遠在 user/role 上查看 PermissionsBoundary。
Session Policy 行為
取交集，無法擴展。在 AssumeRole 時傳入。聯合驗證中常見。
SCP 範圍
適用於所有成員帳號。豁免管理帳號。Deny 優先。不授予任何東西。
常見問題——授權、IAM Policies 與 AccessDenied 排錯
Q1——開發者回報 s3:GetObject 上的 AccessDenied，即使他們有 AdministratorAccess。我先查哪裡？
現代 AccessDenied 訊息會告訴你哪一層造成拒絕。先讀錯誤訊息。若說「explicit deny in a service control policy」，查 SCPs。若說「no resource-based policy allows」，查 bucket policy（可能是跨帳號或受限的 bucket）。若說「with an explicit deny in identity-based policy」，principal 附加的某個 identity policy 中有 Deny statement。若說「implicit deny — no statements allow」，action 未被授予。AdministratorAccess 涵蓋大多數服務，但跨帳號目標仍需要目標的 resource policy。拉 CloudTrail 事件，讀訊息，走向被命名的層。
Q2——Permissions boundary 和 SCP 有什麼區別？
兩者都是不授予任何東西的上限。SCPs 附加在 AWS Organizations 的 roots、OUs 或帳號上，適用於受影響帳號中的每個 principal（除了管理帳號）。Permissions boundaries 附加在特定 IAM user 或 role 上，只適用於那個 principal。SCPs 是全組織防護欄；boundaries 是逐 principal 的防護欄。使用 SCPs 在帳號之間強制執行不可變規則（禁止核准清單外的區域、禁止 CloudTrail 停用）。使用 boundaries 啟用安全的 role 建立委派（開發者只有在附加標準 boundary 時才能建立 roles）。它們獨立疊加。
Q3——什麼時候應該用 ABAC 而非 RBAC？
當你有許多資源和許多需要按屬性（team、project、environment）範圍存取的 principals，且數量隨時間增長時，使用 ABAC。ABAC 以相同方式為 principals 和 resources 打標籤，並使用一個比較它們的 policy，無需編輯 policy 即可擴展。對於需要具名 principals 的可稽核性比彈性更重要的小數量特權 roles（SecurityAuditor、BreakGlass），使用 RBAC。大多數生產環境兩者都用：ABAC 用於工作負載自助服務，RBAC 用於特權人員存取。來自 SAML 或 OIDC IdP 的 session tags 能在沒有 IAM 管理員開銷的情況下為聯合使用者啟用 ABAC。
Q4——如何從現有 role 的實際使用情況生成最小權限 policy？
使用 IAM Access Analyzer policy 生成。在 IAM 中開啟 role，選擇「Generate policy based on CloudTrail events」，選一個時間窗口（通常 30-90 天），讓 analyzer 掃描 CloudTrail。結果是一個 JSON policy，精確列出 role 使用過的 actions 和 resource ARNs。檢閱，必要時精煉，並替換廣義的起始 policy。結合 Access Advisor 確認沒有近期活動的服務，以及 Policy Simulator 驗證新 policy 不會破壞預期的操作。這是 SCS-C02 的標準最小權限工作流程。
Q5——跨帳號 API 呼叫對某些使用者有效但對其他人失敗，他們都 assume 同一個 role。為什麼？
兩個可能的原因。第一，session policies——若某些使用者透過注入 session policies 的聯合 IdP assume role，他們看到的是縮小的權限，而直接 assume 的使用者則不受影響。查看 AssumeRole CloudTrail 事件的 responseElements，看 session policy。第二，MFA 條件——若 role 的 policies 要求 aws:MultiFactorAuthPresent，session 中沒有活躍 MFA 的使用者會看到拒絕，而啟用 MFA 的使用者則成功。拉取失敗使用者的 CloudTrail 事件；userIdentity.sessionContext.attributes.mfaAuthenticated 欄位告訴你 MFA 是否存在。
Q6——為何 CloudTrail 沒有顯示每個 AccessDenied 事件？
通常它都會顯示。確認 trail 已設定為同時擷取讀和寫管理事件。若 AccessDenied 是在資料平面 action（S3 物件讀取、DynamoDB GetItem），在 trail 上為那些資源啟用資料事件記錄。STS 呼叫（AssumeRole 失敗）上的 AccessDenied 事件出現在呼叫帳號的 CloudTrail 中；跨帳號 AssumeRole 拒絕可能出現在任一或兩個帳號，取決於哪一側拒絕了。對於大規模的高量排錯，使用帶有 SQL 查詢的 CloudTrail Lake。
Q7——可以用 IAM Policy Simulator 測試 SCPs 嗎？
可以，但有注意事項。Simulator 支援在你選擇 Organization 中的帳號或 principal 時包含 SCP。模擬會套用附加在 principal 帳號鏈上的 SCPs。限制：跨帳號情境中目標的 SCPs 無法被模擬。在 AssumeRole 時傳入的 Session policies 也在 Simulator 範圍之外。對於推出前的全面 SCP 測試，對已知 principals 和操作的測試組合進行模擬，並補充 CloudTrail Lake 對歷史數據的查詢來預測影響。
Q8——當開發者可以建立自己的 IAM roles 時，如何防止權限升級？
使用 permissions boundaries。開發者的 role 授予 iam:CreateRole、iam:PutRolePolicy、iam:AttachRolePolicy、iam:PassRole——但帶有要求 iam:PermissionsBoundary 等於特定 managed policy ARN 的 Condition。Boundary policy 明確拒絕特權升級操作（沒有對其他實體的 iam:*、沒有 organizations:*、沒有 cloudtrail:Stop* 等）。結果：開發者可以為自己的工作負載建立 roles，但每個建立的 role 都被 boundary 上限。結合阻止刪除 boundary policy 本身的 SCP。這是 SCS-C02 標準的「自助服務不升級」模式。
Q9——AccessDenied 訊息中的「implicit deny」是什麼意思？
Implicit deny 意味著沒有 policy 明確 Allow 該 action——請求落到了預設的 Deny。修復是在某個適用的 policy（identity、resource 或 permissions boundary 路徑）中加入一個 Allow statement。Implicit deny 可以透過加入 Allow 來覆蓋。對比「explicit deny」，那是一個 "Effect": "Deny" statement 符合了——explicit deny 不可覆蓋，除非移除 Deny statement。現代 AccessDenied 錯誤訊息區分兩者：「implicit deny — no statements allow this action」vs「explicit deny in a service control policy」。這個區別對修復策略很重要。
Q10——應該優先使用 managed policies 還是 inline policies？
預設優先使用 customer-managed policies。它們可跨 users/roles 重複使用、有版本控制（可以回滾），且更易稽核（一個 ARN、多個附件）。AWS-managed policies 用於廣義的通用標準（ReadOnlyAccess），但要謹慎——它們不是最小權限。只有在 policy 與單一實體緊密耦合且必須始終跟著它走時，才使用 inline policies（例如，一個有獨一無二權限且其他 role 絕不會需要的特殊 role）。Inline policies 是匿名的，隨實體消失，因此更難集中稽核。
延伸閱讀——官方 AWS 文件
如需超出 SCS-C02 範圍的深度資料，權威的 AWS 來源包括：IAM User Guide policy 評估邏輯、IAM policy 類型總覽、permissions boundaries、Policy Simulator 使用者指南、Access Advisor 文件、排查 AccessDenied 訊息、ABAC 介紹、session tags、session policies，以及 IAM 全域 condition keys。
AWS Security Reference Architecture (SRA) 白皮書整理了組織規模的授權模式。IAM 最佳做法文件提供了最小權限的標準指引。過去兩年的 AWS re:Inforce 有關 IAM 深度解析與 AccessDenied 排錯的場次，是最豐富的真實世界演練來源。
摘要——授權決策樹
考試當天，當你看到授權、IAM policies 與 AccessDenied 排錯的情境，跑這個決策樹：
- 問題是關於無論身份為何都要組織層級阻止一個 action？→ SCP。
- 問題是關於限制開發者建立的 roles 能做什麼？→ Permissions boundary。
- 問題是關於授予特定 principal 存取？→ Identity-based policy。
- 問題是關於授予跨帳號存取某個資源？→ Resource-based policy + 呼叫者的 identity policy（兩者都需要）。
- 問題是關於限制特定聯合 session 的權限？→ AssumeRole 時的 session policy。
- 問題是關於「explicit deny in service control policy」的 AccessDenied？→ SCP——在 root、OU 或 account 找 Deny statement。
- 問題是關於「no resource-based policy allows」的 AccessDenied？→ 跨帳號目標的 resource policy 缺口。
- 問題是關於「implicit deny — no statements allow」的 AccessDenied？→ Identity policy 中缺少 Allow。
- 問題是關於按 team 或 project tag 擴展存取？→ ABAC 用
aws:PrincipalTag對照aws:ResourceTag。 - 問題是關於從實際使用情況生成最小權限 policy？→ 從 CloudTrail 的 IAM Access Analyzer policy 生成。
- 問題是關於 principal 最近使用了哪些服務？→ IAM Access Advisor。
- 問題是關於部署前驗證新 policy？→ IAM Policy Simulator。
- 問題是關於解碼特定呼叫失敗的原因？→ 帶有
errorCode = AccessDenied的 CloudTrail 事件。 - 問題是關於跨帳號呼叫返回 AccessDenied？→ 查雙方——呼叫者 identity 以及目標 resource policy。
熟記這十四個分支，你就能正確回答 SCS-C02 Domain 4.2 的每一道授權題目。授權、IAM policies 與 AccessDenied 排錯需要系統性的 policy 層思維——研究各層如何組合，排錯時有條理地逐一走遍每一層，正確答案就會自然浮現。