SOA-C02 Deployment, Provisioning, and Automation Practice Question

Exhibit

Refer to the exhibit.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:us-east-1:123456789012:instance/*",
      "Condition": {
        "StringEquals": {
          "ec2:InstanceType": "t2.micro"
        }
      }
    }
  ]
}

A SysOps administrator is creating an IAM policy for automation. The policy is attached to an IAM role used by an automated deployment script. The script needs to launch EC2 instances of type t2.micro and describe all EC2 resources. However, the script fails when trying to launch instances. What is the MOST likely reason?

⚠ Common exam trap

Candidates often assume granting ec2:RunInstances on the instance resource is sufficient, overlooking that AWS requires explicit permissions for all dependent resources that are implicitly created or modified during instance launch.

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 grant permissions for additional resources required by RunInstances, such as images, network interfaces, and security groups.

The RunInstances API action requires permissions for not only the EC2 instance resource itself but also for dependent resources such as Amazon Machine Images (AMI), network interfaces, security groups, and key pairs. If the IAM policy only grants ec2:RunInstances on the instance resource ARN but omits these supporting resources, the launch will fail with an 'unauthorized operation' error. Option C correctly identifies this missing dependency.

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 Resource ARN for the instance is incorrect.
Why it's wrong here
The instance ARN in the policy is correctly formatted as arn:aws:ec2:region:account:instance/instance-id, so this is not the cause of failure. Even a perfectly valid instance ARN only authorizes the action on that specific instance resource, but RunInstances is an API that creates multiple resources and therefore requires permissions on more than just the instance. An incorrect ARN would produce a different error (such as Invalid ARN or unauthorized resource), not the missing-permissions error you see here. The real issue lies in the absence of additional resource-level authorizations, not in the syntax of the ARN.
✗
The policy does not include the 'ec2:DescribeInstances' action.
Why it's wrong here
The policy includes ec2:Describe* in its Action list, and the wildcard Describe* already covers ec2:DescribeInstances, so the lack of an explicit DescribeInstances entry is irrelevant. DescribeInstances is a read-only listing operation and is not even required to launch an instance; it is only needed to display instance information after the launch. Denying or omitting DescribeInstances would not prevent RunInstances from succeeding—those are separate APIs with separate permission checks. Therefore, this is not the missing piece that causes the RunInstances call to fail.
✓
The policy does not grant permissions for additional resources required by RunInstances, such as images, network interfaces, and security groups.
Why this is correct
RunInstances is a multi-resource API action: IAM evaluates it against every resource type that the new instance will create or use, including the AMI (image), network interface, security group, volume, and optionally subnet and key pair. A policy that only grants ec2:RunInstances on the instance ARN (e.g., arn:aws:ec2:region:account:instance/*) does not grant the needed permissions on those other resource types, so the request will be denied even though the instance ARN itself is correct. To allow the launch, you must either use Resource * for the ec2:RunInstances action or provide a separate statement with the appropriate ARNs for each resource type involved. This is the core reason the policy fails as written.
✗
The Condition key 'ec2:InstanceType' is misspelled.
Why it's wrong here
The condition key ec2:InstanceType is spelled correctly and is a valid, supported condition key for the RunInstances action—it filters allowed instance types (e.g., t3.micro) and is commonly used to restrict launches. A typo in a condition key would typically cause the condition to never match, which would allow the action (if permissions were otherwise present), not deny it. Since the condition key is properly spelled and the policy still fails, the problem is not the condition key. The failure stems from missing resource-level permissions, not from any misspelling or malformed condition.

Go deeper

SOA-C02 Deployment, Provisioning, and Automation Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question