[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"cheat-sheet---en":3,"domain-info---en":3,"topic-info----en":3,"next-aws-certified-cloudops-engineer-associate-security-and-compliance-iam-and-access-management-troubleshooting-access-with-iam-tools-en":4,"prev-aws-certified-cloudops-engineer-associate-security-and-compliance-iam-and-access-management-troubleshooting-access-with-iam-tools-en":1179,"lesson-aws-certified-cloudops-engineer-associate-security-and-compliance-iam-and-access-management-troubleshooting-access-with-iam-tools-en":1191},null,{"locked":5,"reason":3,"meta":6,"item":20},false,{"title":7,"description":8,"isFree":9,"estimatedMinutes":10,"difficulty":11,"learningObjectives":12},"AWS Organizations and Service Control Policies","How an organization gives you a control point above the account: roots, OUs, and the management account, plus the SCP inheritance rules that decide whether a permission survives the path from the root down to the account.",true,30,"intermediate",[13,14,15,16,17,18,19],"Describe the structure of an AWS organization and the difference between the management account and a member account","Explain why an SCP grants nothing and how it combines with identity-based policies","Apply the inheritance rules for Allow and Deny statements across the root, OUs, and accounts","Predict what happens when the FullAWSAccess policy is detached at any level","Choose between an allow-list and a deny-list SCP strategy for a stated requirement","Identify the principals and tasks that SCPs cannot restrict","Compare SCPs with RCPs and select the right one for a given scenario",{"id":21,"title":7,"body":22,"description":8,"difficulty":11,"estimatedMinutes":10,"extension":1079,"infographics":1080,"isFree":9,"learningObjectives":1097,"meta":1098,"navigation":9,"path":1099,"quiz":1100,"seo":1176,"stem":1177,"__hash__":1178},"courses/courses/aws-certified-cloudops-engineer-associate/en/domains/04-security-and-compliance/02-multi-account-governance/01-organizations-and-service-control-policies.md",{"type":23,"value":24,"toc":1066},"minimark",[25,38,46,49,54,65,68,86,109,120,124,130,133,144,148,171,178,181,191,197,204,208,211,216,230,244,267,274,287,290,294,300,306,316,326,330,333,411,417,423,427,430,814,817,822,834,839,845,849,852,877,880,884,891,902,975,986,990,993,996,1014,1017,1021,1059,1062],[26,27,28,29,33,34,37],"p",{},"The security team asks for a promise: no account in the company can turn off CloudTrail. You could write an IAM policy that denies ",[30,31,32],"code",{},"cloudtrail:StopLogging"," and attach it to every role in all 40 accounts. It would work until the first account administrator, who has ",[30,35,36],{},"AdministratorAccess",", detaches it.",[26,39,40,41,45],{},"That is the gap. Inside a single account, the account administrator is the top of the tree, and anything you write there they can rewrite. A promise that holds needs a control point ",[42,43,44],"strong",{},"above"," the account, owned by somebody the account administrator cannot overrule. AWS Organizations is that control point, and a service control policy is how you express the promise.",[26,47,48],{},"The previous topic ended with the enforcement order for a single request. Two of those gates, SCPs and RCPs, live in this lesson.",[50,51,53],"h2",{"id":52},"the-shape-of-an-organization","The shape of an organization",[26,55,56,57,60,61,64],{},"An organization is a tree of AWS accounts with a single ",[42,58,59],{},"root"," at the top. Under the root you create ",[42,62,63],{},"organizational units (OUs)",", and OUs can nest inside other OUs. Counting the root and the accounts at the bottom, the hierarchy goes 5 levels deep.",[26,66,67],{},"There are exactly 2 kinds of account:",[69,70,71,79],"ul",{},[72,73,74,75,78],"li",{},"The ",[42,76,77],{},"management account"," is the one that created the organization. It attaches policies, creates and invites accounts, designates delegated administrators, and pays the bill for everyone. You cannot transfer this role to a different account later.",[72,80,81,82,85],{},"Every other account is a ",[42,83,84],{},"member account",". A member account belongs to exactly one organization at a time.",[26,87,88,89,92,93,96,97,100,101,104,105,108],{},"Accounts join in 1 of 2 ways: the management account ",[42,90,91],{},"creates"," them directly, or it ",[42,94,95],{},"invites"," an existing standalone account, which the account owner must accept. The invitation runs as a ",[42,98,99],{},"handshake",", a term you meet only if you use the CLI or API, where invitations are objects with types like ",[30,102,103],{},"INVITE"," and ",[30,106,107],{},"ENABLE_ALL_FEATURES",".",[26,110,111,112,115,116,119],{},"One setup choice decides whether this lesson applies at all. An organization runs with either the ",[42,113,114],{},"consolidated billing"," feature set, which gives you a single bill and nothing else, or ",[42,117,118],{},"all features",", which adds policies and service integrations. SCPs, RCPs, and every cross-account service integration require all features. Upgrading from consolidated billing means every invited member account has to accept a handshake approving the change.",[50,121,123],{"id":122},"the-management-account-is-not-governed","The management account is not governed",[26,125,126,127],{},"This is the fact that makes multi-account design what it is: ",[42,128,129],{},"SCPs have no effect on users or roles in the management account.",[26,131,132],{},"Not \"limited effect\". None. An SCP attached to the root applies to every OU and member account beneath it and skips the management account entirely. The same is true of RCPs and the resources in the management account.",[26,134,135,136,139,140,143],{},"The consequence is the standard AWS recommendation: keep workloads, data, and day-to-day users out of the management account. Anything living there is outside every guardrail you write. When the management account still needs work done, designate a ",[42,137,138],{},"delegated administrator",", which is an ordinary member account registered to administer a specific service or to manage organization policies. Delegated administrators are convenient, but note the trap: a delegated administrator is a member account, so ",[42,141,142],{},"SCPs do apply to it",". Being trusted to manage Config for the organization does not lift the guardrails on the account doing the managing.",[50,145,147],{"id":146},"what-an-scp-is-and-what-it-is-not","What an SCP is, and what it is not",[26,149,150,151,154,155,154,158,154,161,154,164,154,167,170],{},"An SCP looks almost exactly like an IAM policy. Same ",[30,152,153],{},"Version",", ",[30,156,157],{},"Statement",[30,159,160],{},"Effect",[30,162,163],{},"Action",[30,165,166],{},"Resource",[30,168,169],{},"Condition"," elements, same JSON.",[26,172,173,174,177],{},"It behaves nothing like one in a single respect that decides most exam questions: ",[42,175,176],{},"an SCP grants no permissions",". It sets the maximum available permissions for IAM users and roles in member accounts. Permissions still come from identity-based and resource-based policies, and the effective permission is the intersection.",[26,179,180],{},"Read that as an equation you can apply under pressure:",[182,183,189],"pre",{"className":184,"code":186,"language":187,"meta":188},[185],"language-text","what a principal can actually do\n  = (what the SCP allows)\n  AND (what the identity-based policy allows)\n  AND (what the permissions boundary allows, if one exists)\n","text","",[30,190,186],{"__ignoreMap":188},[26,192,193,194,196],{},"Both halves of the failure mode follow from it. A user with ",[30,195,36],{}," and an SCP that never mentions S3 cannot touch S3. A user with no IAM policy at all and an SCP allowing every service can do nothing. The SCP is a ceiling, and a ceiling without a floor leaves you standing on the ground.",[26,198,199,200,203],{},"One extra rule when boundaries enter: if both a permissions boundary and an SCP apply, the boundary, the SCP, ",[42,201,202],{},"and"," the identity-based policy must all allow the action. Three intersections, no unions.",[50,205,207],{"id":206},"how-scps-inherit-an-allow-needs-every-level-a-deny-needs-one","How SCPs inherit: an Allow needs every level, a Deny needs one",[26,209,210],{},"Attaching a policy at the root, an OU, or an account is easy. Predicting the result across a 4-level tree is where people go wrong, because Allow and Deny travel differently.",[212,213],"infographic",{"alt":214,"slug":215},"A two-panel comparison shows an Allow failing because one OU on the path lacks it, next to a Deny at one OU blocking every account below it.","scp-inheritance-allow-vs-deny",[26,217,218,221,222,225,226,229],{},[42,219,220],{},"For a permission to be allowed",", an explicit ",[30,223,224],{},"Allow"," must exist at ",[42,227,228],{},"every level"," on the direct path from the root, through each OU, down to the account itself. Miss one, and the account is denied. SCP evaluation is deny by default: anything not explicitly allowed at every level is denied.",[26,231,232,235,236,239,240,243],{},[42,233,234],{},"For a permission to be denied",", a single ",[30,237,238],{},"Deny"," ",[42,241,242],{},"anywhere"," on that path is enough. Root, any OU on the way down, or the account itself.",[26,245,246,247,250,251,104,254,257,258,260,261,263,264,108],{},"Work an example. Root has ",[30,248,249],{},"FullAWSAccess",". The Production OU has a custom policy allowing only ",[30,252,253],{},"ec2:*",[30,255,256],{},"cloudwatch:*",". Account B, inside Production, has ",[30,259,249],{}," attached directly. A user in Account B holds ",[30,262,36],{}," and calls ",[30,265,266],{},"s3:ListBucket",[26,268,269,270,273],{},"Denied. The root allows S3 and the account allows S3, but the Production OU never did, and the chain broke there. Notice what this means in practice: ",[42,271,272],{},"the narrowest Allow on the path defines the ceiling for everything under it",". Put an allow-list at the root and it silently governs the whole organization no matter what any OU below attaches.",[26,275,276,277,279,280,282,283,286],{},"Now the mirror case. Root has ",[30,278,249],{},". The Sandbox OU has ",[30,281,249],{}," plus a policy denying ",[30,284,285],{},"s3:*",". Account A and Account B are both in Sandbox and have no S3-related policy of their own. Both are denied S3. Neither account did anything wrong, and neither can fix it locally.",[26,288,289],{},"This asymmetry is the whole design. Denies are for controls that must hold broadly, because attaching one high up covers everything beneath it. Allows are for defining a permitted surface, and they are fragile, because every level has to cooperate.",[50,291,293],{"id":292},"fullawsaccess-and-the-quietest-way-to-break-an-organization","FullAWSAccess, and the quietest way to break an organization",[26,295,296,297,299],{},"When you enable SCPs, AWS attaches an AWS managed policy named ",[30,298,249],{}," to the root, every OU, and every account. It allows all actions on all resources. New OUs and accounts get it automatically at creation.",[26,301,302,303,305],{},"It exists only because of the allow rule above. Without an ",[30,304,224],{}," at every level, nothing works, so AWS pre-attaches a blanket allow so the deny-by-default model does not lock you out on day one.",[26,307,308,309,315],{},"Which produces the failure mode worth naming: ",[42,310,311,312,314],{},"detaching ",[30,313,249],{}," without attaching a replacement allow breaks every account below that point."," Every API call fails, and the error message points at an SCP, not at anything in the account. There is no warning dialog that stops you. If you detach it at the root, the entire organization stops working.",[26,317,318,319,322,323,325],{},"The related trap: disabling the SCP policy type in a root detaches every SCP from every entity in that root, and those attachments are ",[42,320,321],{},"not recoverable",". Re-enabling gives you a clean slate with only ",[30,324,249],{}," back in place, and you reattach everything by hand.",[50,327,329],{"id":328},"allow-list-or-deny-list","Allow list or deny list",[26,331,332],{},"Two strategies, and the exam expects you to know which one a scenario is describing.",[334,335,336,351],"table",{},[337,338,339],"thead",{},[340,341,342,345,348],"tr",{},[343,344],"th",{},[343,346,347],{},"Deny list",[343,349,350],{},"Allow list",[352,353,354,367,378,389,400],"tbody",{},[340,355,356,361,364],{},[357,358,359],"td",{},[30,360,249],{},[357,362,363],{},"Keep it attached",[357,365,366],{},"Replace it with a policy naming permitted services",[340,368,369,372,375],{},[357,370,371],{},"What the SCP says",[357,373,374],{},"Subtracts specific actions",[357,376,377],{},"Names the complete permitted set",[340,379,380,383,386],{},[357,381,382],{},"A service AWS launches next month",[357,384,385],{},"Permitted immediately",[357,387,388],{},"Denied until you edit the SCP",[340,390,391,394,397],{},[357,392,393],{},"Typical use",[357,395,396],{},"Guardrails: protect audit logs, block Region use, stop accounts leaving",[357,398,399],{},"Regulated environments with an approved service catalog",[340,401,402,405,408],{},[357,403,404],{},"Maintenance",[357,406,407],{},"Low",[357,409,410],{},"Ongoing",[26,412,413,414,416],{},"Deny lists are the common case, and most published example policies assume one, which is why they say \"you also need ",[30,415,249],{}," attached\" in the fine print. Their statements only subtract, so without an allow somewhere on the path they subtract from nothing.",[26,418,419,420,422],{},"A note the docs make explicitly: relying only on allow statements and the deny-by-default model can still produce unintended access, because a broad ",[30,421,224],{}," at one level does not undo a broader one somewhere else on the path. Denies are the sharper tool.",[50,424,426],{"id":425},"a-worked-guardrail","A worked guardrail",[26,428,429],{},"The CloudTrail promise from the opening, written properly:",[182,431,435],{"className":432,"code":433,"language":434,"meta":188,"style":188},"language-json shiki shiki-themes material-theme-lighter github-light github-dark","{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Sid\": \"ProtectAuditAndComplianceServices\",\n      \"Effect\": \"Deny\",\n      \"Action\": [\n        \"cloudtrail:StopLogging\",\n        \"cloudtrail:DeleteTrail\",\n        \"config:DeleteConfigurationRecorder\",\n        \"config:StopConfigurationRecorder\",\n        \"config:DeleteDeliveryChannel\",\n        \"guardduty:DeleteDetector\"\n      ],\n      \"Resource\": \"*\",\n      \"Condition\": {\n        \"ArnNotLike\": {\n          \"aws:PrincipalArn\": \"arn:aws:iam::*:role/OrgSecurityBreakGlass\"\n        }\n      }\n    },\n    {\n      \"Sid\": \"KeepAccountsInTheOrganization\",\n      \"Effect\": \"Deny\",\n      \"Action\": \"organizations:LeaveOrganization\",\n      \"Resource\": \"*\"\n    }\n  ]\n}\n","json",[30,436,437,446,475,489,495,518,537,550,562,574,586,598,610,621,627,647,661,676,697,703,709,715,720,740,759,779,796,802,808],{"__ignoreMap":188},[438,439,442],"span",{"class":440,"line":441},"line",1,[438,443,445],{"class":444},"sP7_E","{\n",[438,447,449,453,456,459,462,466,470,472],{"class":440,"line":448},2,[438,450,452],{"class":451},"s39Yj","  \"",[438,454,153],{"class":455},"sseR_",[438,457,458],{"class":451},"\"",[438,460,461],{"class":444},":",[438,463,465],{"class":464},"sjJ54"," \"",[438,467,469],{"class":468},"s_sjI","2012-10-17",[438,471,458],{"class":464},[438,473,474],{"class":444},",\n",[438,476,478,480,482,484,486],{"class":440,"line":477},3,[438,479,452],{"class":451},[438,481,157],{"class":455},[438,483,458],{"class":451},[438,485,461],{"class":444},[438,487,488],{"class":444}," [\n",[438,490,492],{"class":440,"line":491},4,[438,493,494],{"class":444},"    {\n",[438,496,498,501,505,507,509,511,514,516],{"class":440,"line":497},5,[438,499,500],{"class":451},"      \"",[438,502,504],{"class":503},"sZMiF","Sid",[438,506,458],{"class":451},[438,508,461],{"class":444},[438,510,465],{"class":464},[438,512,513],{"class":468},"ProtectAuditAndComplianceServices",[438,515,458],{"class":464},[438,517,474],{"class":444},[438,519,521,523,525,527,529,531,533,535],{"class":440,"line":520},6,[438,522,500],{"class":451},[438,524,160],{"class":503},[438,526,458],{"class":451},[438,528,461],{"class":444},[438,530,465],{"class":464},[438,532,238],{"class":468},[438,534,458],{"class":464},[438,536,474],{"class":444},[438,538,540,542,544,546,548],{"class":440,"line":539},7,[438,541,500],{"class":451},[438,543,163],{"class":503},[438,545,458],{"class":451},[438,547,461],{"class":444},[438,549,488],{"class":444},[438,551,553,556,558,560],{"class":440,"line":552},8,[438,554,555],{"class":464},"        \"",[438,557,32],{"class":468},[438,559,458],{"class":464},[438,561,474],{"class":444},[438,563,565,567,570,572],{"class":440,"line":564},9,[438,566,555],{"class":464},[438,568,569],{"class":468},"cloudtrail:DeleteTrail",[438,571,458],{"class":464},[438,573,474],{"class":444},[438,575,577,579,582,584],{"class":440,"line":576},10,[438,578,555],{"class":464},[438,580,581],{"class":468},"config:DeleteConfigurationRecorder",[438,583,458],{"class":464},[438,585,474],{"class":444},[438,587,589,591,594,596],{"class":440,"line":588},11,[438,590,555],{"class":464},[438,592,593],{"class":468},"config:StopConfigurationRecorder",[438,595,458],{"class":464},[438,597,474],{"class":444},[438,599,601,603,606,608],{"class":440,"line":600},12,[438,602,555],{"class":464},[438,604,605],{"class":468},"config:DeleteDeliveryChannel",[438,607,458],{"class":464},[438,609,474],{"class":444},[438,611,613,615,618],{"class":440,"line":612},13,[438,614,555],{"class":464},[438,616,617],{"class":468},"guardduty:DeleteDetector",[438,619,620],{"class":464},"\"\n",[438,622,624],{"class":440,"line":623},14,[438,625,626],{"class":444},"      ],\n",[438,628,630,632,634,636,638,640,643,645],{"class":440,"line":629},15,[438,631,500],{"class":451},[438,633,166],{"class":503},[438,635,458],{"class":451},[438,637,461],{"class":444},[438,639,465],{"class":464},[438,641,642],{"class":468},"*",[438,644,458],{"class":464},[438,646,474],{"class":444},[438,648,650,652,654,656,658],{"class":440,"line":649},16,[438,651,500],{"class":451},[438,653,169],{"class":503},[438,655,458],{"class":451},[438,657,461],{"class":444},[438,659,660],{"class":444}," {\n",[438,662,664,666,670,672,674],{"class":440,"line":663},17,[438,665,555],{"class":451},[438,667,669],{"class":668},"srdBf","ArnNotLike",[438,671,458],{"class":451},[438,673,461],{"class":444},[438,675,660],{"class":444},[438,677,679,682,686,688,690,692,695],{"class":440,"line":678},18,[438,680,681],{"class":451},"          \"",[438,683,685],{"class":684},"swQdS","aws:PrincipalArn",[438,687,458],{"class":451},[438,689,461],{"class":444},[438,691,465],{"class":464},[438,693,694],{"class":468},"arn:aws:iam::*:role/OrgSecurityBreakGlass",[438,696,620],{"class":464},[438,698,700],{"class":440,"line":699},19,[438,701,702],{"class":444},"        }\n",[438,704,706],{"class":440,"line":705},20,[438,707,708],{"class":444},"      }\n",[438,710,712],{"class":440,"line":711},21,[438,713,714],{"class":444},"    },\n",[438,716,718],{"class":440,"line":717},22,[438,719,494],{"class":444},[438,721,723,725,727,729,731,733,736,738],{"class":440,"line":722},23,[438,724,500],{"class":451},[438,726,504],{"class":503},[438,728,458],{"class":451},[438,730,461],{"class":444},[438,732,465],{"class":464},[438,734,735],{"class":468},"KeepAccountsInTheOrganization",[438,737,458],{"class":464},[438,739,474],{"class":444},[438,741,743,745,747,749,751,753,755,757],{"class":440,"line":742},24,[438,744,500],{"class":451},[438,746,160],{"class":503},[438,748,458],{"class":451},[438,750,461],{"class":444},[438,752,465],{"class":464},[438,754,238],{"class":468},[438,756,458],{"class":464},[438,758,474],{"class":444},[438,760,762,764,766,768,770,772,775,777],{"class":440,"line":761},25,[438,763,500],{"class":451},[438,765,163],{"class":503},[438,767,458],{"class":451},[438,769,461],{"class":444},[438,771,465],{"class":464},[438,773,774],{"class":468},"organizations:LeaveOrganization",[438,776,458],{"class":464},[438,778,474],{"class":444},[438,780,782,784,786,788,790,792,794],{"class":440,"line":781},26,[438,783,500],{"class":451},[438,785,166],{"class":503},[438,787,458],{"class":451},[438,789,461],{"class":444},[438,791,465],{"class":464},[438,793,642],{"class":468},[438,795,620],{"class":464},[438,797,799],{"class":440,"line":798},27,[438,800,801],{"class":444},"    }\n",[438,803,805],{"class":440,"line":804},28,[438,806,807],{"class":444},"  ]\n",[438,809,811],{"class":440,"line":810},29,[438,812,813],{"class":444},"}\n",[26,815,816],{},"Three things are doing work here.",[26,818,74,819,821],{},[30,820,504],{}," values are not decoration. When a call is denied by an SCP, the error message names the policy type, and readable statement IDs shorten the conversation that follows.",[26,823,74,824,826,827,829,830,833],{},[30,825,669],{}," condition carves out one break-glass role in every account, using the wildcard in the account ID position. This is the negated-operator behavior from the previous lesson: ",[30,828,685],{}," is present in every request, so the condition is doing an honest comparison and the exemption behaves as written. If you ever build an exemption on a key that can be absent, remember that a negated operator returns ",[42,831,832],{},"true"," for a missing key, and the deny would fire on requests you never meant to cover.",[26,835,836,838],{},[30,837,774],{}," is the statement people forget. An account that can leave the organization can walk out from under every other guardrail you wrote.",[26,840,841,842,844],{},"Attach this at the root as a deny list, alongside ",[30,843,249],{},", and it holds for every member account. Not for the management account.",[50,846,848],{"id":847},"what-scps-cannot-restrict","What SCPs cannot restrict",[26,850,851],{},"Even inside member accounts, a short list sits outside SCP control:",[69,853,854,859,865,868,871,874],{},[72,855,856],{},[42,857,858],{},"Anything the management account does.",[72,860,861,864],{},[42,862,863],{},"Anything done with the permissions of a service-linked role."," Service-linked roles are how AWS services act on your behalf, and SCPs cannot narrow them.",[72,866,867],{},"Registering for the Enterprise support plan as the root user.",[72,869,870],{},"Trusted signer functionality for CloudFront private content.",[72,872,873],{},"Configuring reverse DNS for a Lightsail email server or an EC2 instance as the root user.",[72,875,876],{},"A handful of AWS-related services outside the normal API surface, including Amazon Mechanical Turk.",[26,878,879],{},"The first 2 matter for the exam. The rest is trivia you can recognize without memorizing.",[50,881,883],{"id":882},"rcps-the-same-idea-aimed-at-resources","RCPs: the same idea, aimed at resources",[26,885,886,887,890],{},"An SCP caps what ",[42,888,889],{},"your principals can do",". That leaves a hole: a bucket policy in one of your accounts can grant an outside account access, and no SCP touches that request, because the caller is not managed by your organization.",[26,892,893,894,897,898,901],{},"A ",[42,895,896],{},"resource control policy"," closes it. RCPs cap the maximum permissions available ",[42,899,900],{},"for resources"," in member accounts, whoever is calling. Same JSON shape, same never-grants rule, same intersection behavior, same management account exemption, same immunity for service-linked roles.",[334,903,904,916],{},[337,905,906],{},[340,907,908,910,913],{},[343,909],{},[343,911,912],{},"SCP",[343,914,915],{},"RCP",[352,917,918,929,940,954,965],{},[340,919,920,923,926],{},[357,921,922],{},"Caps",[357,924,925],{},"What principals in your member accounts can do",[357,927,928],{},"What can be done to resources in your member accounts",[340,930,931,934,937],{},[357,932,933],{},"Applies to callers outside your organization",[357,935,936],{},"No",[357,938,939],{},"Yes",[340,941,942,945,949],{},[357,943,944],{},"Default attached policy",[357,946,947],{},[30,948,249],{},[357,950,951],{},[30,952,953],{},"RCPFullAWSAccess",[340,955,956,959,962],{},[357,957,958],{},"Service coverage",[357,960,961],{},"All services",[357,963,964],{},"A defined subset, including S3, STS, KMS, SQS, Secrets Manager, DynamoDB, CloudWatch Logs, ECR, and EventBridge",[340,966,967,969,972],{},[357,968,393],{},[357,970,971],{},"\"Nobody here may use Region X\"",[357,973,974],{},"\"Only identities from my organization may read these buckets\"",[26,976,977,978,981,982,985],{},"The keyword split is reliable. A scenario about restricting ",[42,979,980],{},"your people"," is an SCP. A scenario about restricting ",[42,983,984],{},"who can reach your data",", especially when an external principal appears, is an RCP.",[50,987,989],{"id":988},"test-before-you-attach","Test before you attach",[26,991,992],{},"AWS says this in bold in the documentation, and it belongs in your habits: do not attach a new SCP straight to the root. Create a test OU, move accounts in a few at a time, and watch.",[26,994,995],{},"Two tools tell you what a policy would break before it breaks:",[69,997,998,1004],{},[72,999,1000,1003],{},[42,1001,1002],{},"Service last accessed data",", viewable per organization entity or per policy from the IAM console when signed in with management account credentials. It shows which services the principals in an account actually attempted, which is how you turn a guess about an allow list into evidence.",[72,1005,1006,1009,1010,1013],{},[42,1007,1008],{},"CloudTrail",", for API-level usage and, after the fact, for the ",[30,1011,1012],{},"AccessDenied"," errors a new policy produces.",[26,1015,1016],{},"The failure mode you are avoiding is not subtle: an SCP mistake does not degrade one workload, it removes a service from every account beneath the attachment point at once.",[50,1018,1020],{"id":1019},"exam-tips","Exam tips",[69,1022,1023,1026,1032,1035,1041,1044,1050,1053,1056],{},[72,1024,1025],{},"\"An SCP does not grant permissions\" is the single most tested sentence about this service. A principal with no identity-based policy has no access no matter what the SCP says.",[72,1027,1028,1029,1031],{},"An SCP with no applicable ",[30,1030,224],{}," denies. It is not just a deny list.",[72,1033,1034],{},"Allow needs every level from the root down. Deny needs one level anywhere. If a scenario walks you through a hierarchy, trace the path twice, once for each rule.",[72,1036,1037,1038,1040],{},"A scenario where \"the account administrator has ",[30,1039,36],{}," but the call still fails\" and Organizations is mentioned is an SCP question.",[72,1042,1043],{},"SCPs never affect the management account or service-linked roles. They do affect the member account root user and delegated administrator accounts.",[72,1045,1046,1047,1049],{},"Detaching ",[30,1048,249],{}," with no replacement is how organizations break. If a question describes total failure across an OU right after a policy change, look for a missing allow.",[72,1051,1052],{},"Allow list means new AWS services are blocked until you edit the SCP. Deny list means they are permitted on launch day.",[72,1054,1055],{},"External principal in the scenario, or \"only identities in my organization may access this data\", points at an RCP, not an SCP.",[72,1057,1058],{},"SCPs and RCPs both need all features enabled. Consolidated billing only means neither is available.",[26,1060,1061],{},"The decision rule to carry: ask whether the control has to survive a local administrator. If yes, it belongs above the account in an SCP or RCP, and you accept the coarse granularity that comes with it. If no, an IAM policy or permissions boundary inside the account is cheaper and easier to change. Guardrails answer the question of what is possible in an account. The next lesson answers the other half, which is how a human being gets a signed-in session in 40 accounts without 40 sets of credentials.",[1063,1064,1065],"style",{},"html pre.shiki code .sP7_E, html code.shiki .sP7_E{--shiki-light:#39ADB5;--shiki-default:#24292E;--shiki-dark:#E1E4E8}html pre.shiki code .s39Yj, html code.shiki .s39Yj{--shiki-light:#39ADB5;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .sseR_, html code.shiki .sseR_{--shiki-light:#9C3EDA;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .sjJ54, html code.shiki .sjJ54{--shiki-light:#39ADB5;--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .s_sjI, html code.shiki .s_sjI{--shiki-light:#91B859;--shiki-default:#032F62;--shiki-dark:#9ECBFF}html pre.shiki code .sZMiF, html code.shiki .sZMiF{--shiki-light:#E2931D;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .srdBf, html code.shiki .srdBf{--shiki-light:#F76D47;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html pre.shiki code .swQdS, html code.shiki .swQdS{--shiki-light:#E53935;--shiki-default:#005CC5;--shiki-dark:#79B8FF}html .light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html.light .shiki span {color: var(--shiki-light);background: var(--shiki-light-bg);font-style: var(--shiki-light-font-style);font-weight: var(--shiki-light-font-weight);text-decoration: var(--shiki-light-text-decoration);}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}html.dark .shiki span {color: var(--shiki-dark);background: var(--shiki-dark-bg);font-style: var(--shiki-dark-font-style);font-weight: var(--shiki-dark-font-weight);text-decoration: var(--shiki-dark-text-decoration);}",{"title":188,"searchDepth":477,"depth":477,"links":1067},[1068,1069,1070,1071,1072,1073,1074,1075,1076,1077,1078],{"id":52,"depth":448,"text":53},{"id":122,"depth":448,"text":123},{"id":146,"depth":448,"text":147},{"id":206,"depth":448,"text":207},{"id":292,"depth":448,"text":293},{"id":328,"depth":448,"text":329},{"id":425,"depth":448,"text":426},{"id":847,"depth":448,"text":848},{"id":882,"depth":448,"text":883},{"id":988,"depth":448,"text":989},{"id":1019,"depth":448,"text":1020},"md",[1081],{"slug":215,"concept":1082,"style":1083,"aspectRatio":1084,"labels":1085},"A two-panel comparison of how Allow and Deny statements travel down an AWS Organizations hierarchy. The left panel shows a root, an OU, and an account in a vertical chain where an Allow for ec2 exists at the root and at the account but is missing at the OU, with a broken link drawn at the OU and a denied result at the bottom. The right panel shows a root with FullAWSAccess, an OU carrying a Deny for s3, and 2 accounts underneath it, with the deny drawn as a shadow falling over both accounts even though neither account has an S3 policy of its own. The visual emphasis is the asymmetry: the left chain needs an unbroken run of allows, the right needs a single deny anywhere on the path.","comparison","16:9",[1086,1087,1088,1089,1090,1091,1092,1093,1094,1095,1096],"Allow: the permission must be allowed at every level","Root: Allow ec2:*","Production OU: no Allow covering ec2:*","Account B: Allow ec2:* attached here","Result: denied. The chain broke at the OU.","Deny: one level anywhere is enough","Root: FullAWSAccess","Sandbox OU: Deny s3:*","Account A and Account B: no S3 restriction of their own","Result: both accounts denied S3.","An Allow has to survive the whole path down. A Deny only has to appear once.",[13,14,15,16,17,18,19],{},"/courses/aws-certified-cloudops-engineer-associate/en/domains/04-security-and-compliance/02-multi-account-governance/01-organizations-and-service-control-policies",{"passingScore":1101,"questions":1102},70,[1103,1112,1120,1130,1138,1146,1152,1160,1168],{"question":1104,"type":1105,"options":1106,"correctAnswer":1109,"explanation":1111},"An SCP attached to the Production OU allows only ec2 and cloudwatch actions. The root has the default FullAWSAccess policy. Account B sits in the Production OU and has FullAWSAccess attached directly. A user in Account B with AdministratorAccess calls s3:ListBucket. What happens?","single",[1107,1108,1109,1110],"The call succeeds, because Account B has FullAWSAccess attached directly","The call succeeds, because the root allows all services","The call fails, because no SCP on the path from the root to the account allows s3","The call fails, because AdministratorAccess is blocked by the OU-level SCP","An action must be allowed by an SCP at every level from the root through each OU down to the account, so the narrowest Allow on the path wins. FullAWSAccess at the root and on the account cannot rescue a service the OU never allowed. The user's `AdministratorAccess` policy is fine; SCPs cap what any identity policy can deliver.",{"question":1113,"type":1105,"options":1114,"correctAnswer":1115,"explanation":1119},"Your organization needs a guardrail that no member account can turn off CloudTrail. Which statement is true about using an SCP for this?",[1115,1116,1117,1118],"An SCP with a Deny on cloudtrail:StopLogging blocks even a local account administrator with AdministratorAccess","An SCP cannot deny CloudTrail actions, so you need a permissions boundary on every role","The SCP only applies to IAM users, so roles can still stop logging","You must attach the SCP to every account individually for it to take effect","An SCP sits above the account, so a member account administrator cannot edit their way around it, which is exactly why guardrails live here instead of in identity policies. SCPs apply to IAM users and roles alike, including the member account root user. Attaching once at the root or an OU covers everything beneath it.",{"question":1121,"type":1122,"options":1123,"correctAnswers":1128,"explanation":1129},"Which of the following are NOT restricted by service control policies? (Choose 2.)","multiple",[1124,1125,1126,1127],"Actions performed by principals in the organization's management account","Actions performed by the root user of a member account","Actions performed using permissions attached to a service-linked role","Actions performed by an IAM role in a member account designated as a delegated administrator",[1124,1126],"SCPs never apply to the management account or to service-linked roles, which is why AWS recommends keeping workloads out of the management account entirely. They do apply to the member account root user, and they apply to delegated administrator accounts, since those are ordinary member accounts with extra service permissions.",{"question":1131,"type":1105,"options":1132,"correctAnswer":1134,"explanation":1137},"An administrator detaches FullAWSAccess from an OU and attaches nothing in its place. What is the effect on accounts in that OU?",[1133,1134,1135,1136],"Nothing changes, because the root-level FullAWSAccess still applies","All AWS actions in those accounts fail, because no Allow exists at the OU level","Only new services added by AWS become unavailable","The accounts revert to the permissions granted by their identity-based policies","SCP evaluation is deny by default, so a level with no applicable `Allow` blocks everything below it. `FullAWSAccess` exists precisely to keep that from happening, which is why AWS warns against removing it unless you replace it with another allow policy. Identity-based policies cannot grant past an SCP that never allowed the action.",{"question":1139,"type":1105,"options":1140,"correctAnswer":1143,"explanation":1145},"A security team wants to guarantee that S3 buckets in member accounts can only be read by principals inside the organization, including when an external account is named in a bucket policy. Which control fits?",[1141,1142,1143,1144],"An SCP with a Deny on s3:GetObject conditioned on aws:PrincipalOrgID","A permissions boundary applied to every role in every member account","A resource control policy with a Deny conditioned on aws:PrincipalOrgID","An IAM Identity Center permission set that excludes s3 actions","SCPs cap what principals in your member accounts can do, so they have no effect on an outside principal calling into your bucket. RCPs cap what can be done to resources in your member accounts regardless of who the caller is, which is the resource-side version of the same guardrail. S3 is one of the services RCPs support.",{"question":1147,"type":1105,"options":1148,"correctAnswer":1150,"explanation":1151},"True or False: an SCP can grant a permission that no identity-based policy in the account provides.",[1149,1150],"True","False","An SCP never grants anything; it only sets the maximum available permissions for principals in member accounts. A user with no IAM permissions policy has no access even under an SCP allowing every service and action. Permissions still come from identity-based and resource-based policies, and the SCP intersects with them.",{"question":1153,"type":1105,"options":1154,"correctAnswer":1155,"explanation":1159},"Your organization structure is Root, then a Workloads OU, then a Test OU nested inside Workloads. The root has FullAWSAccess. The Workloads OU has FullAWSAccess. The Test OU has FullAWSAccess plus a policy with Deny on ec2:*. Account D sits in the Test OU. What can Account D do?",[1155,1156,1157,1158],"Everything except EC2 actions","Nothing, because the Deny at the Test OU blocks the FullAWSAccess allow","Everything, because FullAWSAccess appears at every level of the path","Only EC2 actions, because the most specific policy wins","Allows and denies are evaluated separately: the unbroken `FullAWSAccess` chain permits every service, and the single `Deny` subtracts EC2 for everything at and below the Test OU. There is no most-specific-wins rule in SCP evaluation; a deny anywhere on the path is final.",{"question":1161,"type":1105,"options":1162,"correctAnswer":1164,"explanation":1167},"An organization enabled only consolidated billing features. The security team asks you to attach an SCP to a new OU. What do you tell them?",[1163,1164,1165,1166],"SCPs work, but only for deny statements in a consolidated billing organization","SCPs are unavailable until the organization enables all features","SCPs work, but only if the OU contains fewer than 10 accounts","SCPs work only after each member account attaches FullAWSAccess itself","The consolidated billing feature set gives you one bill and nothing else; SCPs, RCPs, and service integrations all require all features enabled. Moving to all features requires every invited member account to approve the change through a handshake. Accounts created inside the organization do not need to approve.",{"question":1169,"type":1105,"options":1170,"correctAnswer":1172,"explanation":1175},"Which SCP strategy makes newly launched AWS services unavailable by default until you explicitly permit them?",[1171,1172,1173,1174],"A deny list, because the deny statements keep growing as services launch","An allow list, because the SCP names the permitted services and nothing else passes","Neither, because SCPs always inherit new services from FullAWSAccess","Both, because SCP evaluation is deny by default in either case","An allow list replaces `FullAWSAccess` with a policy naming the services you permit, so a service launched next month is denied until somebody edits the SCP. A deny list keeps `FullAWSAccess` and subtracts specific actions, so new services are permitted from day one. The tradeoff is control against maintenance, and it is the standard way exams frame this choice.",{"title":7,"description":8},"courses/aws-certified-cloudops-engineer-associate/en/domains/04-security-and-compliance/02-multi-account-governance/01-organizations-and-service-control-policies","ya3H4ORkfhnSs-8C2ihBaWsO4CbN_RFoESrQML8P6X8",{"locked":9,"reason":1180,"meta":1181,"item":3},"paywall",{"title":1182,"description":1183,"isFree":5,"estimatedMinutes":742,"difficulty":11,"learningObjectives":1184},"MFA, Federation, and Account Security","Hardening the credentials themselves: the root user and the tasks that still require it, password policy limits, the MFA types AWS supports and how to enforce them, access key hygiene, and the federation options that let you stop creating IAM users at all.",[1185,1186,1187,1188,1189,1190],"Identify the tasks that require AWS account root user credentials and the controls that protect it","Configure an account password policy within the ranges AWS allows and predict which settings apply immediately","Compare the 3 MFA types AWS supports and choose the phishing-resistant option","Enforce MFA on sensitive actions and explain which STS operations can carry MFA information","Decide when an IAM user with long-term access keys is still the right answer","Choose between IAM Identity Center, SAML or OIDC federation in IAM, and Amazon Cognito for a given set of users",{"locked":9,"reason":1180,"meta":1192,"item":3},{"title":1193,"description":1194,"isFree":5,"estimatedMinutes":761,"difficulty":11,"learningObjectives":1195},"Troubleshooting Access with IAM Tools","Turning an AccessDenied into an answer: reading what the error message already tells you, testing with the policy simulator, and using IAM Access Analyzer, last accessed information, the credential report, and CloudTrail to find both the permissions you are missing and the ones you should never have granted.",[1196,1197,1198,1199,1200,1201],"Read an AccessDenied message and name the policy type that produced it","Distinguish an implicit deny from an explicit deny by the wording of the error alone","Run the policy simulator and state which policy types it does and does not evaluate","Select the right IAM Access Analyzer analyzer type for external, internal, and unused access questions","Interpret last accessed information within its tracking periods and excluded policy types","Order the diagnostic steps so the cause of a denied request is found with the least work"]