DOP-C02 Security and Compliance Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Tag the approved AMI and use resource-based policies to allow only tagged AMIs.

  Why it's wrong here

  AMI resource-based policies cannot conditionally allow ec2:RunInstances based on tags; in fact, AMIs don't support resource policies that are evaluated during the RunInstances API call. Additionally, the ec2:RunInstances action does not accept the ec2:ResourceTag condition key for AMIs, so tag-based gating is impossible at the IAM level. This approach is therefore unimplementable and would not prevent the launch of unapproved AMIs.

• ✓

  Create an IAM policy that denies ec2:RunInstances unless the AMI ID matches the approved AMI.

  Why this is correct

  An identity-based IAM policy can deny ec2:RunInstances unless the request's ec2:ImageId condition key matches the approved AMI ID. Because IAM policies are evaluated synchronously before the launch proceeds, this is a true preventive control that blocks the API call, not just an after-the-fact check. It can be attached to all relevant principals and combined with a Deny for a null ImageId to ensure every launch specifies an approved AMI.

• ✓

  Use an AWS Organizations service control policy (SCP) to restrict AMI usage across accounts.

  Why this is correct

  An SCP can enforce the same restriction at the AWS Organizations level by denying ec2:RunInstances unless the ec2:ImageId condition matches an approved AMI. SCPs are service-wide safeguards that apply to every account and IAM principal in the organization, including the root user, so they provide a strong guardrail that IAM policies alone cannot override. However, an SCP only restricts; it does not grant permissions, so it must be combined with identity policies that allow the action in the first place.

• ✗

  Create an AWS Config rule to check that EC2 instances are launched from the approved AMI.

  Why it's wrong here

  An AWS Config rule is a detective control that evaluates whether running EC2 instances were launched from the approved AMI after the fact. It does not intercept the RunInstances call, so an instance from an unapproved AMI will already exist by the time the rule evaluates and flags it. Config can trigger auto-remediation, but that remediation happens post-launch and cannot prevent the initial violation from occurring.

• ✗

  Enable CloudTrail to log all EC2 RunInstances calls and alert on unapproved AMIs.

  Why it's wrong here

  CloudTrail is an audit service that records API activity after it happens; enabling it to log RunInstances calls and alerting on unapproved AMIs only provides visibility and notification. It does not affect the authorization decision, so the instance launch would already succeed before any alarm fires. This is a reactive, detective approach, not a preventive control, and therefore cannot fulfill the requirement to ensure only approved AMIs are used.

Go deeper

Related to this question