Welcome to ExamTopics
ExamTopics Logo
- Expert Verified, Online, Free.

Unlimited Access

Get Unlimited Contributor Access to the all ExamTopics Exams!
Take advantage of PDF Files for 1000+ Exams along with community discussions and pass IT Certification Exams Easily.

Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 3 discussion

A company uses AWS Organizations with a single OU named Production to manage multiple accounts. All accounts are members of the Production OU. Administrators use deny list SCPs in the root of the organization to manage access to restricted services.
The company recently acquired a new business unit and invited the new unit’s existing AWS account to the organization. Once onboarded, the administrators of the new business unit discovered that they are not able to update existing AWS Config rules to meet the company’s policies.
Which option will allow administrators to make changes and continue to enforce the current policies without introducing additional long-term maintenance?

  • A. Remove the organization’s root SCPs that limit access to AWS Config. Create AWS Service Catalog products for the company’s standard AWS Config rules and deploy them throughout the organization, including the new account.
  • B. Create a temporary OU named Onboarding for the new account. Apply an SCP to the Onboarding OU to allow AWS Config actions. Move the new account to the Production OU when adjustments to AWS Config are complete.
  • C. Convert the organization’s root SCPs from deny list SCPs to allow list SCPs to allow the required services only. Temporarily apply an SCP to the organization’s root that allows AWS Config actions for principals only in the new account.
  • D. Create a temporary OU named Onboarding for the new account. Apply an SCP to the Onboarding OU to allow AWS Config actions. Move the organization’s root SCP to the Production OU. Move the new account to the Production OU when adjustments to AWS Config are complete.
Show Suggested Answer Hide Answer
Suggested Answer: B 🗳️

Comments

Chosen Answer:
This is a voting comment (?) , you can switch to a simple comment.
Switch to a voting comment New
Snip
Highly Voted 1 year, 6 months ago
Right answer is D. An SCP at a lower level can't add a permission after it is blocked by an SCP at a higher level. SCPs can only filter; they never add permissions. SO you need to create a new OU for the new account assign an SCP, and move the root SCP to Production OU. Then move the new account to production OU when AWS config is done.
upvoted 45 times
...
robertohyena
Highly Voted 1 year, 6 months ago
Answer: D. Not A: too much overhead and maintenance. Not B: SCP at Root will still deny Config to the temporary OU. Not C: Too much overhead to create allow list.
upvoted 16 times
...
Amazonexamss
Most Recent 1 week, 6 days ago
AmazonExams.com
upvoted 1 times
...
pnannepaga
1 month, 2 weeks ago
For all the answers provided, which answer is mostly correct, the revealed solution or most voted?
upvoted 1 times
...
Mikep12357
1 month, 2 weeks ago
Option B. If a "Deny" list SCP is applied at the root of the organization to restrict access to a service, and then a new SCP is created at a lower level (e.g., an Organizational Unit or OU) to "Allow" access to that restricted service, the permissions are cumulative. So, if an account is placed under the Test OU, it will inherit the permissions from both SCPs. Since the "Allow" SCP at the Test OU level overrides the "Deny" SCP at the root level, the account under the Test OU will effectively have access to the restricted service. This is because SCPs are evaluated hierarchically, with SCPs at higher levels in the organizational structure being evaluated first, followed by SCPs at lower levels. When there are conflicting SCPs, the most permissive policy (i.e., the one that allows access) takes precedence.
upvoted 1 times
...
TonytheTiger
2 months, 2 weeks ago
Selected Answer: D
Option D: The link doesn't give you a full explanation on why "D" is correct however it does check all the boxes https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/transitional-ou.html
upvoted 1 times
...
Dgix
3 months, 3 weeks ago
This question is ambiguous. If D was formulated like this: "D. Create a temporary OU named Onboarding for the new account. Apply a Config non-blocking SCP to the Onboarding OU to allow AWS Config actions. Apply the organization’s root SCP to the Production OU instead of to the root OU. Move the new account to the Production OU when adjustments to AWS Config are complete." Then D would be a viable option. However, it isn't, and even if it were, it fails to mention the crucial fact that the Root OU always must have an SCP, which in this case must Allow everything. For someone with some experience this is a given, but as it isn't mentioned, I'd go for B. However, AWS should reformulate the question and the answers. They are really subpar.
upvoted 2 times
JOKERO
3 months, 2 weeks ago
AWS Config will still be restricted despite the Allow SCP in Onboarding because of the Deny SCP in the root of the organization
upvoted 2 times
fartosh
1 month, 3 weeks ago
This sentence: "Apply the organization’s root SCP to the Production OU instead of to the root OU." solves the issue you mentioned. You can safely move this SCP as the question states that all AWS accounts are in Production OU.
upvoted 1 times
...
...
...
awsylum
3 months, 3 weeks ago
I don't like any of the answers to be honest. Let's look at D since that's the one most people think is right. The problem with D is that you can't detach the last SCP associated with a root container, OU, or account. There has to be at least one. So, removing the SCP from the root and moving it down to the Production OU is a no-go unless you add a permissable SCP to the root. Check the section on detaching here: https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_attach.html The only way B is correct is if the reason the new admins don't have access to Config is not because Config is in the Deny List, but because the management account doesn't have the appropriate IAM Policy giving PERMISSION to Config. You need both an IAM Policy and a permissable SCP to have permission and access to a service. But, why wasn't IAM Policy mentioned in choice B. Clearly, without that information, choice B also is not right.
upvoted 1 times
awsylum
3 months, 3 weeks ago
Also, even if you could remove a root SCP, you would never do that in production. You would never just flat remove an SCP with a Deny list just to give one account access to some service. Even if it's temporary, that's a fatal mistake as the other accounts will not be restricted from certain services they shouldn't have access to.
upvoted 1 times
...
awsylum
3 months, 3 weeks ago
The question mentioned a Deny List architecture, but it didn't specifically say Config was in the Deny List. We are assuming that, which could lead to the wrong answer. Unfortunately, I'm not satisfied with any of the answers. Hopefully, this is a question that would be thrown out from the exam. LOL.
upvoted 1 times
...
...
DmitriKonnovNN
4 months, 3 weeks ago
The question itself is a bit confusing. It says "Deny List in the root", which should be understood as Deny List Architecture, but can be misinterpreted as "Allow List Architecture with attached Deny List in the root that explicitly deny AWS Config". Since AWS Config on Production OU is denied, an appropriate SCP is attached to it, which explicitly denies AWS Config. Thus, the root has FullAWSAccess SCP attached to it. That's why we just need to create Onboarding OU with no explicit deny of AWS Config and that's it. So the correct answer is truly correct, but the question is a bit tricky and easy to misunderstand.
upvoted 1 times
...
kobi44
5 months ago
option D - how creating new OU will solve the problem? the root SCP will deny it , isnt? also why do we need to Move the organization’s root SCP to the Production OU ?
upvoted 1 times
...
GabrielShiao
5 months, 2 weeks ago
Answer D is the answer most accurate. it would be good that add another statement to say" Add awsFullAccess SCP policy on the root and move the deny list scp policy from root to production OU"
upvoted 1 times
...
atirado
6 months ago
Selected Answer: C
Option A - This option actually rolls out AWS Config across the company which is exactly the opposite of what they are doing Option B - This option does not work because AWS Config will still be restricted despite the Allow SCP in Onboarding because of the Deny SCP in the root of the organization Option C - This option allows access to AWS Config in the new business unit and restricts access to everything else. However, the SCP will require regular updates to add new AWS services Option D - This option applies the correct level of access to each OU without needing updates: Onboarding gets access to AWS Config, Production does not and FullAWSAccess is established at the root after the company's Deny SCP is moved.
upvoted 1 times
...
cgsoft
6 months, 1 week ago
Selected Answer: D
SCP at root must be moved to Production OU to prevent it from being applied to onboarded account.
upvoted 1 times
...
ninomfr64
6 months, 2 weeks ago
Selected Answer: D
This was not easy for me due to wording, however here is my take: Not A. here we permanently remove SCPs that limit access to AWS Config, while we are requested to continue to enforce the current policies Not B. temporary OU and related SCP that allows AWS Config are nested under root where SCPs that limit access to AWS Config are applied. As SCP can only remove permission and not add, this will not work Not C. converting deny list into allow list here is not beneficial also temporarily apply SCP allowing AWS Config does not meet the request to avoid additional long-term maintenance. Thus D does the job.
upvoted 1 times
...
abeb
6 months, 3 weeks ago
D is correct
upvoted 1 times
...
swadeey
7 months ago
The Root is not an OU. It is a container for the management account, and for all OUs and accounts in your organization. Conceptually, the Root contains all of the OUs. It cannot be deleted. You cannot govern enrolled accounts at the Root level within AWS Control Tower. Instead, govern enrolled accounts within your OUs. The SCP don't apply at root OU. This will impact production as when you move SCP from root to Production you are changing SCP for all OU which are part of it. Will customer allow to change existing production SCP to on board a new. I don't think D is correct
upvoted 1 times
...
jainparag1
7 months ago
B is horribly wrong. Correct answer must be D.
upvoted 1 times
...
Community vote distribution
A (35%)
C (25%)
B (20%)
Other
Most Voted
A voting comment increases the vote count for the chosen answer by one.

Upvoting a comment with a selected answer will also increase the vote count towards that answer by one. So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.

SaveCancel
Loading ...