The correct answer is D. Remove Amazon SES from the root SCP.
This answer is correct because the root SCP is the most restrictive policy that applies to all accounts in the organization. The root SCP explicitly denies access to Amazon SES by using the NotAction element, which means that any action that is not listed in the element is denied. Therefore, removing Amazon SES from the root SCP will allow the developers to access it, as long as there are no other SCPs or IAM policies that deny it.
The other options are incorrect because:
A.Adding a resource policy that allows each member of the group to access Amazon SES is not a solution, because resource policies are not supported by Amazon SES1.Resource policies are policies that are attached to AWS resources, suchas S3 buckets or SNS topics, to control access to those resources2. Amazon SES does not have any resources that can have resource policies attached to them.
B.Adding a resource policy that allows “Principal”: {“AWS”: “arn:aws:iam::account-number:group/Dev”} is not a solution, because resource policies do not support IAM groups asprincipals3.Principals are entities that can perform actions on AWS resources, such as IAM users, roles, or AWSaccounts4.IAM groups are not principals, but collections of IAM users that share the same permissions5.
C.Removing the AWS Control Tower control (guardrail) that restricts access to Amazon SES is not a solution, because AWS Control Tower does not have any guardrails that restrict access to Amazon SES6.Guardrails are high-level rules that govern the overall behavior of an organization’s accounts7.AWS Control Tower provides a set of predefined guardrails that cover security, compliance, and operations domains8.
[References:, 1: Amazon Simple Email Service endpoints and quotas2: Resource-based policies and IAM policies3: Specifying a principal in a policy4: Policy elements: Principal5: IAM groups6: AWS Control Tower guardrails reference7: AWS Control Tower concepts8: AWS Control Tower guardrails, , , , ]
Submit