Deny sso and sso-directory actions in the DevOps permission set with an aws:SourceAccount condition, then delete the SCP
A company uses an organization in AWS Organizations that a security team and a DevOps team manage. Both teams access the accounts by using AWS IAM Identity Center. A dedicated group has been created for each team. The DevOps team's group has been assigned a permission set named DevOps. The permission set has the AdministratorAccess managed IAM policy attached. The permission set has been applied to all accounts in the organization. The security team wants to ensure that the DevOps team does not have access to IAM Identity Center in the organization's management account. The security team has attached the following SCP to the organization root: After implementing the policy, the security team discovers that the DevOps team can still access IAM Identity Center. Which solution will fix the problem? - 
Community Votes
75% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.
Community Insight
SCPs do not apply to the organization management account, so no SCP attachment strategy at any organizational unit can restrict the management account (A and B are both ineffective). The only mechanism that governs what a permission set grants is the permission set's own policy, so denying sso: and sso-directory: there blocks Identity Center access (C and D both do this). D is the precise answer because it conditions the deny on aws:SourceAccount matching the management account, so the restriction applies only where the problem exists and the same permission set remains usable elsewhere, whereas C applies the deny unconditionally.
The SCP attached at the organization root has no effect because AWS Organizations SCPs do not apply to the management account, which is precisely the account whose IAM Identity Center access must be blocked. The enforcement point must instead be the DevOps permission set itself: update it so the policy grants full access but explicitly denies the sso and sso-directory actions, adding a StringEquals condition on the aws:SourceAccount global condition key set to the management account ID so the deny applies only there. With the permission set enforcing the restriction, the ineffective SCP can be deleted.
Moving the management account into a new OU and reattaching the SCP there (A) — SCPs still do not apply to the management account regardless of which OU it is placed in, so the DevOps team keeps its Identity Center access. Updating the SCP condition reference to the DevOps group role ARN and the management account ID (B) — the same limitation applies, since the policy type itself is inert for the management account. tinyshare's observation that Identity Center uses permission sets captures why the fix belongs in the DevOps permission set.
Community Discussion (7 comments)
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The root cause is that service control policies do not apply to the AWS Organizations management account. AWS documentation on management account best practices confirms that SCPs do not affect users or roles in the management account, so the SCP attached at the organization root can never restrict the DevOps team's IAM Identity Center access there, and the DevOps team can still get in. The fix must move the control to a mechanism that does apply: the DevOps permission set. Updating that permission set so its policy retains full access but explicitly denies the sso and sso-directory actions, and adding a StringEquals condition comparing the aws:SourceAccount global condition key against the management account ID, restricts Identity Center access in the management account only (D). Because the permission set now enforces the requirement, the ineffective SCP can be deleted, as the option specifies.Why the Other Options Are Wrong
A creates a new OU, moves the management account into it, and reattaches the SCP there. Since SCPs do not apply to the management account at all, relocating the account and the policy changes nothing and the DevOps team retains access. B updates the SCP condition reference to include the DevOps group's role ARN and the management account ID, which runs into the identical limitation: an SCP cannot restrict the management account, so the policy remains inert regardless of its conditions. C creates a new permission set with the deny and updates the assignment, deleting the SCP; it does remove access, but it applies the sso and sso-directory deny unconditionally, with no scoping to the management account, so the DevOps team would lose Identity Center access in every account where the permission set is used. D scopes the deny to the management account with aws:SourceAccount, achieving the requirement precisely, and is the correct answer. VerRi's comment that SCPs limit permissions while permission sets grant them is exactly right about which layer owns this control.Community Comment Notes
Community voted D (69), with B a 23 percent minority. Impromptu gave the decisive reason, citing the AWS documentation that SCPs do not apply to the management account, which also explains why both A and B fail. tinyshare confirmed the fix belongs in the permission set because Identity Center is governed by permission sets. ApacheKafkaAWS favored B based on ChatGPT output, but B cannot work given the management-account exemption.Official Reference
Related Analysis
Practice All DOP-C02 Questions
Access 85 questions with complete answers and detailed explanations.
View Full DOP-C02 Practice Test →