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

Option C - From AWS doc page "Don't use AWS Organizations to update service control policies (SCPs) attached to an OU that is registered with AWS Control Tower. Doing so could result in the controls entering an unknown state, which will require you to repair your landing zone or re-register your OU in AWS Control Tower. Instead, you can create new SCPs and attach those to the OUs rather than editing the SCPs that AWS Control Tower has created." https://docs.aws.amazon.com/controltower/latest/userguide/orgs-guidance.html

Voting for B: SCP will cause a state drift, since company already use Control Tower

"Behavior of proactive controls Proactive controls check resources whenever those resources are created or updated by means of AWS CloudFormation stack operations. Specifically, these proactive controls are implemented as preCreate and preUpdate hook handlers. As a consequence, these controls may not affect requests that are made directly to services through the AWS console, through AWS APIs, or through other means such as AWS SDKs, or other Infrastructure-as-Code (IaC) tools. For more information about when preCreate and preUpdate hooks operate, see AWS CloudFormation hooks."

Control Tower's Proactive Control Uses Cloud Formation. This means AWS CLI, AWS API, AWS console will be able to bypass Proactive controls. OPtion C of using new SCP will enforce Public IP restriction effectively.

Answer is 100% C. It asks to prevent NEW or EXISTING. It doesn't talk about remediation. A proactive control is only applied if you deploy with cloudformation. If you deploy with the console or through API, the control does not apply. Answer is C

Unfortunately it is C even though i liked B better "Proactive controls check resources whenever those resources are created or updated by means of AWS CloudFormation stack operations. Specifically, these proactive controls are implemented as preCreate and preUpdate hook handlers. As a consequence, these controls may not affect requests that are made directly to services through the AWS console, through AWS APIs, or through other means such as AWS SDKs, or other Infrastructure-as-Code (IaC) tools."

Option C (SCP): Service Control Policies (SCPs) provide a proactive mechanism to prevent non-compliant actions from occurring in the first place. The SCP will block the launch of instances with public IP addresses or the attachment of public IP addresses to existing instances, ensuring that the requirement is met from the outset. Option B (Control Tower proactive control): Proactive controls in AWS Control Tower are designed to detect and remediate non-compliant resources after they have been created. While they can remediate instances with public IP addresses, they do not prevent the initial assignment of public IP addresses.

Option C is actually a good solution for this scenario. C is right. By creating an SCP (Security Policy) that: Prevents the launch of instances with public IP addresses. Prevents the attachment of a public IP address to existing instances, you can effectively prevent new or existing Amazon EC2 instances in the OU's accounts from gaining a public IP address. This solution is suitable because it: Is proactive and automated, reducing the risk of human error Can detect existing instances with public IP addresses and prevent future assignments Is directly attached to the OU, ensuring that all accounts within it are subject to this policy.

The company must prevent any new or existing Amazon EC2 instances in the OU's accounts from gaining a public IP address." The key phrase is "from gaining" a public IP address - this means: It's about preventing future actions of getting public IPs It's NOT about removing already attached public IPs It applies to both new and existing instances In this case, an SCP (Option C) is indeed the correct solution

"The company MUST PREVENT..." Proactive controls do not directly prevent the action of attaching a public IP. They are applicable to resources that are specifically PROVISIONED THROUGH AWS SERVICE CATALOG. They do not have the ability to broadly prevent all EC2 instances in an organization from obtaining a public IP, especially those created outside of Service Catalog. Also, as user VerRi says here in the comments, how will AWS Control Tower proactive control "check whether instances IN the OU's accounts have a public IP address."? Option C is the best solution because it uses an SCP, which is a preventive control that directly stops the creation or modification of EC2 instances with public IP addresses in all accounts under the specified OU. This ensures compliance with the requirement of preventing public IP addresses on EC2 instances.

B. AWS Control Tower's Active Controls primarily focus on security related best practices such as IAM policies, security group rules, etc., rather than directly controlling the public IP addresses of EC2 instances. Although custom proactive control can be created, setting the associatePublicIpAddress property to False is usually done through API calls or CLI/SDK when starting an EC2 instance, rather than through proactive control in AWS Control Tower. C. AWS Service Control Policies (SCPs) are a mechanism provided by AWS Organizations for implementing access control to AWS services at the OU level. SCP can restrict the ability to request public IP addresses when launching EC2 instances within OU accounts, as well as limit the permission to modify existing instances to attach public IP addresses. This fully meets the company's needs as it ensures the implementation of a unified strategy at the OU level without the need to manage each account or instance separately.

SCP prevent but not remediate existing. So correct is B with CT

Going for B as Control Tower permissions have to be managed using Controls but not SCPs which causes drifts.

B is a bit weird because proactive control is used to check NEW resources. It is weird to say "Check whether instances IN the OU's accounts have a public IP address.".

C. B is not correct since Control Tower doesn't have this capability.

Option B is the right option.

NOT B -- These controls are referred to as proactive because they check your resources –**BEFORE** the resources are deployed – to determine whether the new resources will comply with the controls that are activated in your environment. This control applies only to a new network interface created by means of the NetworkInterfaces property, where a NetworkInterfaceId has not been specified. Best answer is C