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

Design, implement, and troubleshoot authorization for AWS resources. Develop a strategy to centrally deploy and manage AWS accounts.
Answer Correct answer: B — edit the existing root SCP to add a Condition that excludes the marketing account from the external-sharing deny.

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.

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.

Community Insight

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.

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).

Community Discussion (3 comments)

aescudero51 👍 5 Selected: 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>" } } }
phmeeeee 👍 1 Selected: B
SCP is deny by default but you can exclude it in the contidion not allow it to use.
HunkyBunky 👍 1 Selected: 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

Comments & Corrections

No comments 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.

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

Related Analysis

A company has an AWS Key Management Service (AWS KMS) custom

S-Grade

A company that uses AWS Organizations is migrating workloads

A-Grade

A company needs to create a centralized solution to analyze

S-Grade

← Back to SCS-C02 Study Guide