Exam AWS Certified Solutions Architect - Professional topic 1 question 626 discussion

Correct answer is C. When you use a Deny list, you cannot explicitly allow access to services at OU or account levels. You need to explicitly deny access to services and that's why the term deny list. By default, all services are explicitly allowed starting at the root level. So you need to explicitly create an SCP at each OU level where you need to implement the control policy of denying access to services. In exceptional circumstances on a use case basis, you need to allow access to the services that already have an allow access from root to this OU level where you are creating an exception. Only C satisfies this criteria. D is not correct because it doesn't create an SCP that allow access at all level from the OU in question upto the root level. So even if you create an SCP that allows access to a service, access won't be granted as it's not been explicitly allowed at all level above this OU.

Prohibit all AWS servers (should be services i guess) can only be achieved by whitelisting method. This means that you will have to remove the AWS managed SCP from the root. Whitelist SCP on the root of your organisation makes sure that any new account will apply these settings. SCP never grants access but can allow you to make use of AWS services. With that baseline set, granting a new set of AWS services in a separate SCP attaching it to the new account in your organisation complies here for the minimal operational overhead. only D will statisfy. One more negative for C. once you implement a deny on a toplevel. it will override any allow in a child OU. not that it is stated within this question. but with that in mind that it could be the case, whitelisting makes more sense for me.

Answer is C. In D, the allow list on the root level implicitly denies all other services. You can try to allow what you want on OU level, it will never overrule the implicit deny on root level. With C, you actually use the default allow from AWS and specify any restrictions on OU level.

Both C and D can meet the requirements, but D is more efficient. For answer C, SCP needs to be applied on EACH OU level. While for answer D, SCP is applied ONLY on root level. From another angle, which list is longer, deny or allow? For most of accounts, we just give them a few basic accesses. I would say allow list is shorter. IMHO, answer is D.

C When there is an implicit deny at the root of an AWS organization and an allow at an OU, the allow policy will take precedence. This means that users in the OU will be able to access the resources that are allowed by the policy, even though there is an implicit deny at the root. For example, if the root of the organization has an implicit deny policy that prohibits the creation of AWS servers, and an OU has an allow policy that allows the creation of AWS servers, users in the OU will be able to create AWS servers. It is important to note that the implicit deny policy at the root will still apply to resources that are not explicitly allowed by the allow policy at the OU. For example, if the root has an implicit deny policy that prohibits the use of the AWS Management Console, and the OU has an allow policy that allows the use of the AWS Management Console for a specific service, users in the OU will still be able to use the AWS Management Console for that service, but they will not be able to use the AWS Management Console for any other services.

D and C both right , but I think D is better since it requires less effort than C.

Can't be D.. D says: "Apply SCP the allow specific list of services to the root, Then, For any specific exceptions for an OU, modify the SCP attached to that OU, and add the required AWS services to the allow list. Read it again... Did you see they mentioned "add Deny" to the SCP in OU level? 😂

C is correct D is totally wrong and can't minimal operational overhead

If a deny list of AWS services is applied at the root level SCP and specific exceptions are allowed at the OU level SCP in the AWS Organizations hierarchy, then the SCP applied at the OU level will take precedence. This means that the AWS services that are allowed in the OU level SCP will be allowed, while the rest of the AWS services will be prohibited as per the deny list applied at the root level SCP. When multiple SCPs are applied, AWS Organizations evaluates them in the order of precedence, which is determined by the level at which the SCP is applied. The SCP applied at the highest level takes precedence over the SCPs applied at lower levels. If a lower-level SCP explicitly allows an action, that action is allowed, even if higher-level SCPs would have otherwise prohibited the action. In this case, the allow list of AWS services at the OU level SCP will take precedence over the deny list of AWS services at the root level SCP, allowing the specified AWS services for that OU, while prohibiting all other AWS services.

You only have access to services because of the default AWS managed SCP, so if you remove that, you don't need to explicitly deny access.

C is wrong. 1.Attach Deny SAP to all OUs. 2. Attach Allow SCP to the OU. They don't say to Detach Deny SCP from the OU - so explicit Deny will be here and win!

C makes more sense

C is correct. For explanation, please refer to Bulti's answer.

D Cannot work if SCP is not attached to Every Level of OU including root. C can work but is too much overhead; A may have incomplete wording but as is, it is working solution, as the SCP is attached "at the Level". In A, it nowhere says to "attach deny to root level". Here is the whole text for A: "A. Use an SCP in Organizations to implement a deny list of AWS servers. Apply this SCP at the level. For any specific exceptions for an OU, create a new SCP for that OU and add the required AWS services to the allow list." The New SCP will not have a Deny for specific service and will have an Allow statement..

Three key points in SCP: 1 Explicit deny actions has the highest priority; 2 Accounts under sub OU inherit the parent OU permissions; 3 Explicit allow actions overrides default FullAWSAccess on root organizations; 4 Once a deny actions applied on a some OU, even an explicit allow action added on sub OU, all the accounts directly under this OU and its sub OU have no permission to perform the action.

it's D

Minimal operational overhead compared to C