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

B is correct because default FullAWSAccess SCP is applied

If you go to AWS management console and look up how SCP works, you will find that by default FullAWSAccess policy is attached to all OUs by default if you have SCP enabled.

AWS advises you to replace the full access assigned by default in the SCP with your controlled SCP. Enabling SCPs gives you FullAWSAccess of the bat.

B is correct. AWS Organizations attaches an AWS managed SCP named FullAWSAccess to every root, OU and account when it's created. This policy allows all services and actions. You can replace FullAWSAccess with a policy allowing only a set of services so that new AWS services are not allowed unless they are explicitly allowed by updating SCPs. For example, if your organization wants to only allow the use of a subset of services in your environment, you can use an Allow statement to only allow specific services. A policy combining the two statements might look like the following example, which prevents member accounts from leaving the organization and allows use of desired AWS services. The organization administrator can detach the FullAWSAccess policy and attach this one instead. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html

I have to choose A although A is impractical. While most vote B, it is actually impossible since removing FullAWSAcess SCP from OU will deny all the services on the ous and accounts under the OU. The correct action is to remove FullAWSAccess SCP from the developer account.

https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html If you removed the default SCP from the OU, you will be denied for these permission even you allowed in SCP on the account in OU.

If you removed FullAWSAccess from developer accounts, I vote B, however, B is removing it from OU. Keep in mind every level of organization hierarchy must reside at least one SCP.

It can be as well handled with a or d, like { "Effect": "Deny", "NotAction": [ "ec2:*", "s3:*", "dynamodb:*" ], "Resource": "*" }

B. Remove the FullAWSAccess SCP from the developers account’s OU.

B. Remove the FullAWSAccess SCP from the developers account’s OU. Explanation: FullAWSAccess SCP: By default, AWS Organizations attaches a FullAWSAccess SCP to all OUs and accounts, allowing access to all AWS services unless restricted by another SCP. If this SCP is still attached to the developers' OU, it will allow access to all services, regardless of the more restrictive SCP you have applied. SCP Behavior: SCPs are evaluated in an "implicit deny" model. If an action is not explicitly allowed by the SCPs, it is implicitly denied. However, if multiple SCPs are attached and one allows an action (like FullAWSAccess), that action is permitted unless explicitly denied in another SCP.

AWS Organizations attaches an AWS managed SCP named FullAWSAccess to every root, OU and account when it's created. This policy allows all services and actions. You can replace FullAWSAccess with a policy allowing only a set of services so that new AWS services are not allowed unless they are explicitly allowed by updating SCPs. https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html

Best practice would be to create an explicit deny statement. The reason is that other SCPs could be in effect, aside from AWSFullAccess, that could grant access to other services. If the goal is to deny access to any other service, then this must be made explicit.

B is correct Remove from develop account OU --> implicitly deny all service -->add explicity 'allow' to restirct only allow related services in SCP.

{ "Sid": "ExplicitDeny", "Effect": "Deny", "NotAction": [ "ec2:*", "dynamodb:*", "s3:*" ], "Resource": "*" }

FullAWSAccess SCP is inherited from root. Can't be removed from OU. D is correct answer.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowEC2", "Effect": "Allow", "Action": "ec2:*", "Resource": "*" }, { "Sid": "AllowDynamoDB", "Effect": "Allow", "Action": "dynamodb:*", "Resource": "*" }, { "Sid": "AllowS3", "Effect": "Allow", "Action": "s3:*", "Resource": "*" }, { "Sid": "ExplicitDeny", "Effect": "Deny", "NotAction": [ "ec2:*", "dynamodb:*", "s3:*" ], "Resource": "*" } ] }

D - the alternative doesn't mention an ASG which must be taken as implied. The other solutions are simply absurd: A: The operational overhead is ENORMOUS. To those who think that "operational overhead" is only day-to-day maintenance: it is not. It encompasses ALL CHANGES to the infrastructure. B: Kubernetes is the very definition of operational overhead. Always avoid unless there is an absolutely compelling reason to use it. C: And what do you people think the function of the Lambda is? None. D: This works and is the most straightforward as soon as you realise that the ASG is implied. In the final analysis, this is another example of how AWS exam questions leave out information in order to trip you up.