Deny sso and sso-directory actions in the DevOps permission set with an aws:SourceAccount condition, then delete the SCP

DOP-C02 By islever Editorial Last updated

Implement techniques for identity and access management at scale. Deploy automation to create, onboard, and secure AWS accounts in a multi-account or multi-Region environment.

Short answer

D Deny sso and sso-directory actions in the DevOps permission set scoped to the management account, then delete the SCP.

Question

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? - Exhibit: Deny sso and sso-directory actions in the DevOps permission set with
  1. In the organization's management account, create a new OU. Move the organization's management account to the new OU. Detach the SCP from the organization root. Attach the SCP to the new OU.
  2. In the organization's management account, update the SCP condition reference to the ARN of the DevOps team's group role to include the AWS account ID of the organization's management account.
  3. In IAM Identity Center, create a new permission set. Ensure that the assigned policy has full access but explicitly denies permission for the sso: action and the sso-directory: action. Update the assigned permission set for the DevOps team's group role in the organization's management account. Delete the SCP.
  4. In IAM Identity Center, update the DevOps permission set. Ensure that the assigned policy has full access but explicitly denies permission for the sso: action and the sso-directory: action. In the Deny statement, add a StringEquals condition that compares the aws:SourceAccount global condition context key with the organization's management account IDelete the SCP. Correct Answer

Key Takeaways

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.

Common mistake: 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.

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

These links open the official vendor documentation in a new tab.

Community Votes

D
75%
B
25%

75% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 7 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 7

  1. Impromptu 👍 3 Answered D
    A and B do not work. SCPs do not apply to the management account. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_mgmt-acct.html Best practice is to limit access to the management account, and/or to delegate to Identity Centro to another member account. But since that's not an option given these answers, limiting the permission set is the next best thing.
  2. limelight04 👍 2 Answered D
    Option D In IAM Identity Center, update the DevOps permission set. Ensure that the assigned policy has full access but explicitly denies permission for the sso: action and the sso-directory: action. In the Deny statement, add a StringEquals condition that compares the aws:SourceAccount global condition context key with the organization’s management account. Delete the SCP. This approach ensures that the DevOps team retains necessary permissions while explicitly denying access to IAM Identity Center actions in the management account. Adding the StringEquals condition ensures that the policy is applied specifically to the management account, effectively preventing access.
  3. tinyshare 👍 2 Answered D
    D is correct. Identity Center uses permission sets.
  4. VerRi 👍 1 Answered B
    D might work, but SCPs are used to limit permissions and permission sets are used to grant permissions.
  5. ApacheKafkaAWS 👍 2 Answered B
    It's B according to chatGPT
Show 2 more comments
  1. siheom 👍 2 Answered D
    vote D
  2. hzaki 👍 1 Answered A
    The right answer is A

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Optimizing Amazon Timestream Query Performance

S-grade

Deploy the CloudWatch agent as a StatefulSet with IRSA and CloudWatchAgentServerPolicy, and configure the OIDC provider

S-grade

Disable cross-zone load balancing on the target group and start an Application Recovery Controller zonal shift

S-grade

Stream all CloudWatch metrics to Firehose, transform with Lambda, and deliver to S3

S-grade

Practice All DOP-C02 Questions

Access 85 questions with complete answers and detailed explanations.

View Full DOP-C02 Practice Test →

← Back to DOP-C02 Study Guide