SCS-C02 IAM Policy Evaluation Practice Question

A company has a single AWS account with multiple IAM users. The administrator created an IAM policy that allows all users to launch EC2 instances, but only if they use a specific AMI ID (ami-12345678) and a specific instance type (t3.micro). The policy uses a condition that checks the EC2 instance type and AMI ID. However, a user is able to launch an EC2 instance with a different AMI ID and a larger instance type. The administrator reviews the policy and confirms that the condition is correctly written. What is the most likely reason that the policy is not working as expected?

⚠ Common exam trap

Candidates often assume that adding a condition to an allow statement is sufficient to restrict actions, but if another allow statement without the condition exists, the condition is ineffective. An explicit deny is required to override other allows.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The policy does not include an explicit deny statement for non-compliant launches.

The most likely reason is that the user has another IAM policy attached (e.g., a managed policy or group policy) that allows ec2:RunInstances without the condition. IAM evaluates all policies; if any allow statement grants the action, the action is permitted unless explicitly denied. The conditional allow only restricts when that specific statement is used, but a separate unconditional allow overrides the condition. Adding an explicit deny for non-compliant launches would block them regardless of other policies.

Answer analysis

Option-by-option breakdown

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

✗
The condition keys used (ec2:InstanceType and ec2:ImageId) are not supported for the RunInstances action in IAM policies.
Why it's wrong here
The condition keys ec2:InstanceType and ec2:ImageId are officially supported for the RunInstances action in IAM policies, so this is not the cause of the failure. Even when condition keys are valid, a statement that only grants access to matching resources does not implicitly deny access to non-matching ones. In IAM, access is denied by default, but any effective allow from another policy will grant access unless an explicit deny overrides it. Thus, the problem is not the condition keys but the lack of a deny statement to block non-compliant launches.
✗
The policy is attached to the user but must also be attached to the IAM group.
Why it's wrong here
IAM policies can be attached directly to a user, an IAM group, or a role, and attaching to the user alone makes the policy effective for that user's permissions. Requiring attachment to the group is incorrect because there is no rule that a policy must be applied at both levels. The user's effective permissions are the union of all attached identity-based policies, and the missing explicit deny remains the actual gap. Therefore, the attachment location is not the problem; the policy's content is.
✓
The policy does not include an explicit deny statement for non-compliant launches.
Why this is correct
In IAM, the default behavior is to deny access, but that default is overridden by any applicable allow statement from another policy. This policy only allows RunInstances when the specified condition keys match; it does not explicitly deny RunInstances when the conditions are not met. Consequently, if the user has any other identity-based or resource-based policy that allows RunInstances without conditions, the user can still launch non-compliant instances. An explicit Deny statement using a condition like StringNotEquals (or a NotCondition) would be required to block those non-compliant launches, making the missing deny the root cause.
✗
The condition is written incorrectly; it should use StringLike instead of StringEquals.
Why it's wrong here
StringEquals performs an exact match, which is the correct operator when the policy is intended to allow only a precise list of instance types and AMI IDs. StringLike would introduce wildcard matching, potentially broadening the allowed set rather than tightening it, and it would still not prevent actions that are allowed by other policies. The real issue is that the statement does not include an explicit Deny for RunInstances when the conditions are not satisfied, so any separate allow policy without those conditions remains effective. Thus, changing the operator would not resolve the failure.

Visual reference

Go deeper

SCS-C02 IAM Policy Evaluation Practice Question

Why each option matters

Option-by-option breakdown

Related to this question