DOP-C02 Resilient Cloud Solutions 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.

• ✗

  The policy does not include the ec2:DescribeRegions action, which is required to describe instances in other regions.

  Why it's wrong here

  DescribeRegions is a separate EC2 endpoint action used to list the regions available to the account; it is not a prerequisite for calling DescribeInstances. EC2 DescribeInstances is a regional action invoked against a region endpoint (e.g., ec2.eu-west-1.amazonaws.com), and IAM evaluation checks only whether the principal is allowed to perform the ec2:DescribeInstances action on the resource. A policy lacking DescribeRegions does not prevent a user from describing instances in another region, because the DescribeInstances call itself does not require that capability; instance metadata and ARNs already convey region information. Therefore, this omission cannot explain the reported issue.

• ✗

  The Allow statement's Resource is set to '*' which only matches instances in the caller's region.

  Why it's wrong here

  In IAM policies, the Resource element of '*' matches all resource ARNs across every region, not just the caller's region; EC2 instance ARNs include region but wildcards are not region-scoped. Because ec2:DescribeInstances is a list-type operation that does not support resource-level restrictions for specific instance IDs, AWS requires or accepts Resource '*' as the only meaningful scope, and it applies globally. Without a Condition block on ec2:Region, an Allow on ec2:DescribeInstances with Resource '*' grants the action from any region endpoint the caller chooses. Thus, the allow statement is not limited to the caller's region and cannot be the cause of cross-region describe failures.

• ✗

  The Deny statement for TerminateInstances implicitly denies all other EC2 actions in regions other than us-east-1.

  Why it's wrong here

  An explicit Deny in IAM applies only to the actions named in its Action element and to the resource condition specified; it does not suppress or deny any other EC2 action. In this policy, the Deny statement targets TerminateInstances specifically, so DescribeInstances is evaluated independently and may still be granted by an Allow statement. The only way a user would be denied DescribeInstances in regions other than us-east-1 is if a separate policy/condition explicitly denies it, or if no Allow exists for that action (an implicit deny), neither of which is produced by the TerminateInstances Deny. Confusing an action-specific Deny with a blanket region-based denial is a common misunderstanding of IAM evaluation logic.

• ✓

  The Deny statement only applies to TerminateInstances, but the Allow statement for DescribeInstances is not restricted by region, so the issue must be elsewhere.

  Why this is correct

  The policy shown contains an explicit Allow for ec2:DescribeInstances on Resource '*' and an explicit Deny only for ec2:TerminateInstances; there is no Deny for DescribeInstances and no region condition on the Allow. Under IAM evaluation, an Allow for an action with no matching explicit Deny results in the action being permitted, so DescribeInstances is allowed in any region. Therefore, if a user cannot describe instances outside us-east-1, the policy fragment is not the cause; the problem must stem from another factor such as a service control policy (SCP), a permission boundary, a session policy, or a VPC endpoint policy that restricts the API call.

Go deeper

Related to this question