A=local account admin can change this. B=local admin has admin permissions. Complicated. C=implicit permit on everything else = breaks requirements. D= As they want to approve each service, its got to be white-list based SCP setup. Answer is D.

D seems better.

Ans D: It is easier to allow approved services than deny all the other services, considering the vast amount of AWS services. it's easier to whitelist than blacklisting all the remaining services.

Option C: Place all the accounts under a new top-level OU within the organization: This allows for centralized management of the accounts. Create an SCP that denies access to restricted AWS services: This ensures that only approved services are accessible. SCPs (Service Control Policies) are the best way to control permissions at the organizational level. Attach the SCP to the OU: By attaching the SCP to the OU, all accounts within the OU will inherit the restrictions set by the SCP. D is wrong: This option allows access only to approved AWS services by creating an SCP that allows access to only approved services and attaching it to the root OU of the organization. However, this would restrict all accounts, including those of other departments or teams within the organization. It doesn't meet the requirement of allowing each team to retain full administrative rights to its AWS account.

Conclusion: Option C is the best solution to meet the requirements with operational efficiency and scalability. It allows teams to retain administrative rights while enforcing company-wide controls on service access through SCPs. This approach is straightforward to manage at scale, as adding or removing services from the SCP can adjust access permissions across all accounts within the OU. It directly aligns with the goal of allowing access only to approved AWS services and supports a governance model that can evolve with the organization's needs.

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

C is correct: <all the accounts are in an organization in AWS Organizations> means we need scps A and B: no mention of scps D: SCP only denies access, not allow. Additionally, should not attack SCP to the root OU because this may inadvertently denies users' access to AWS services

C is correct; apart from SCP's only denying ... why would u want to add SCPs to the root org.

D is wrong SCP can only deny, not approve. my answer is C

Option C is Correct Option D is wrong because AWS strongly recommends that you don't attach SCPs to the root of your organization without thoroughly testing the impact that the policy has on accounts. Instead, create an OU that you can move your accounts into one at a time, or at least in small numbers, to ensure that you don't inadvertently lock users out of key services. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

Sill C must correct answer. The use case is just to restrict access to not allowed services. Everything else should stay as the current configuration. " Each team must RETAIN full administrative rights to its AWS account. Each team also must be allowed to ACCESS ONLY AWS services that the company approves for use

SCPs alone are not sufficient in granting permissions to the accounts in your organization. No permissions are granted by an SCP. An SCP defines a guardrail, or sets limits, on the actions that the account's administrator can delegate to the IAM users and roles in the affected accounts. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html

D wrong because: Attach the SCP to the root OU of the organization. Remove the FullAWSAccess SCP from the root OU of the organization. This makes locking your own root account with inability with full root access. You need keep root OU full access for better management for other accounts. Better move all to separate OU with the restricted access.

This ensures only the approved services can be used in all accounts. C can work , however everytime AWS introduces a new service that will be accessible and need to be included in SCP deny to disable it

I prefer C to D. Say users have full admin access with permission set in their own account and what we need is to use SCP to deny certain services and actions. What is the point of granting explicit access to them again from scp when they have already?

It’s D, because it’s the only one to propose a white list and not a black list. White list is important because AWS regularly opens new services as GA.

C seems better if you can create top level OU. Retain the FullAccess to prevent unforeseen issues and restrict access only to selected resources.