Edit the root SCP to add a Condition excluding the marketing account from the external-sharing deny

SCS-C02 By islever Editorial Last updated

Design, implement, and troubleshoot authorization for AWS resources. Develop a strategy to centrally deploy and manage AWS accounts.

Short answer

B Edit the existing root SCP to add a Condition that excludes the marketing account from the external-sharing deny.

Question

A company uses an organization in AWS Organizations to manage its AWS accounts. The company has implemented an SCP in the root account to prevent resources from being shared with external accounts. The company now needs to allow applications in its marketing team's AWS account to share resources with external accounts. The company must continue to prevent all the other accounts in the organization from sharing resources with external accounts. All the accounts in the organization are members of the same OU. Which solution will meet these requirements?
  1. Create a new SCP in the marketing team's account Configure the SCP to explicitly allow resource sharing.
  2. Edit the existing SCP to add a Condition statement that excludes the marketing team's account. Correct Answer
  3. Edit the existing SCP to include an Allow statement that specifies the marketing team's account.
  4. Create an IAM permissions boundary policy to explicitly allow resource sharing Attach the policy to IAM users in the marketing team's account.

Key Takeaways

You cannot 'allow' around an SCP deny with another SCP (A's new allow SCP would be overridden by the root deny). The fix is to refine the existing deny with a Condition that carves out the marketing account. An IAM permissions boundary (D) is per-principal and does not override the org SCP. Editing the deny with an exclusion condition (B) is the precise, minimal change. C (adding an Allow) cannot defeat the existing deny.

An SCP at the organization root denies sharing resources with external accounts for all members of one OU, and only the marketing account needs an exception. Because SCPs are deny-by-default and denies cannot be overridden by an Allow, the correct approach is to edit the existing SCP and add a Condition that excludes the marketing account's principal/resource from the deny statement—leaving the restriction in force for every other account.

Common mistake: Creating a new SCP that 'allows' sharing for marketing (A/C)—an Allow cannot overcome the existing root-level Deny, so it would have no effect. Using a permissions boundary (D)—that constrains a principal's max permissions but does not override the organization SCP deny. The right move is a Condition exclusion on the existing deny (B).

Expert Analysis

Why the Answer Is Correct

SCPs evaluate as deny-by-default and an explicit deny wins over any allow, so you cannot grant an exception with a second 'allow' SCP. The correct, minimal change is to edit the existing root SCP's deny statement and add a Condition (e.g., excluding the marketing account's ARN) so the external-sharing restriction no longer applies to that one account while remaining in force for all others.

Why the Other Options Are Wrong

A and C try to add an Allow SCP or Allow statement, but an Allow cannot override the existing root Deny, so marketing would still be blocked. D uses an IAM permissions boundary, which limits a principal's permissions but does not override the organization SCP. B is the correct refinement.

Community Comment Notes

Community voted B (100). Commenters explained SCPs are deny-by-default and you exclude the account in a Condition rather than allow it, noting a nested-OU SCP (A) would still be blocked by the root-level deny. B confirmed.

Official Reference

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_general.html

This link opens the official vendor documentation in a new tab.

Community Votes

B
100%

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

Discussion 3 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 3

  1. aescudero51 👍 5 Answered B
    Answer is B The SCP continues to prevent resource sharing with external accounts for all other accounts in the organization. The marketing team's account is specifically exempted from this restriction, allowing them to share resources as needed. Here's an example of a Condition statement that could be used: JSON { "Condition": { "StringEquals": { "aws:PrincipalOrgID": "<marketing-team-account-id>" } } }
  2. HunkyBunky 👍 1 Answered B
    B - looks good for me. A - will not work, becuase if we have SCP at root level - it will block all nested OU SCPs
  3. phmeeeee 👍 1 Answered B
    SCP is deny by default but you can exclude it in the contidion not allow it to use.

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.

Preserve EC2 forensic evidence by isolating first, then capturing memory before stopping the instance

S-grade

Grant the report Lambda Security Hub read-only access because findings are already in Security Hub

S-grade

Deny inbound MySQL 3306 and allow outbound TLS 443 with ephemeral return in a custom NACL

S-grade

Prepare a PHI/public-bucket audit with Macie, Audit Manager, and Security Hub FSBP

S-grade

← Back to SCS-C02 Study Guide