SOA-C02 Security and Compliance Practice Question

A SysOps administrator is troubleshooting an issue where an IAM user cannot launch an EC2 instance. The user has a policy that allows ec2:RunInstances. What is the most likely cause of the failure?

⚠ Common exam trap

SOA-C02 often tests the misconception that a single allow action (ec2:RunInstances) is sufficient for a composite operation — candidates overlook the dependent actions that EC2 requires under the hood, so they pick MFA or KMS as the cause instead of the missing supporting permissions.

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 user does not have permissions for supporting actions like CreateNetworkInterface.

Launching an EC2 instance requires more than just ec2:RunInstances — the principal also needs permissions for dependent actions such as ec2:CreateNetworkInterface, ec2:DescribeImages, ec2:DescribeSubnets, and ec2:DescribeSecurityGroups, depending on the launch configuration. If the policy only grants ec2:RunInstances, the launch fails with an UnauthorizedOperation error on the supporting action. This is the most likely cause given the scenario.

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 user does not have permissions for supporting actions like CreateNetworkInterface.
Why this is correct
Launching an instance via RunInstances is a complex API call that implicitly requires permission for several supporting EC2 actions, including CreateNetworkInterface, DescribeSubnets, DescribeVpcs, and CreateTags. If the IAM policy grants only "ec2:RunInstances" without including these supporting actions, the call will fail with an UnauthorizedOperation or dependency error. Thus a user with the RunInstances permission can still be blocked because the instance launch cannot complete without the ability to create and attach the necessary network interfaces.
✗
The user is not using multi-factor authentication (MFA).
Why it's wrong here
MFA is not a default requirement for RunInstances; it only becomes a prerequisite when an IAM policy explicitly includes a condition such as "aws:MultiFactorAuthPresent": "true" to enforce it. Since the failure is caused by missing EC2 actions rather than authentication, the absence of MFA would not prevent the launch. Even an MFA-authenticated user would face the same permission error if their policy does not authorize the supporting EC2 calls.
✗
The user does not have permission to use the KMS key for encryption.
Why it's wrong here
KMS key permissions are only evaluated when the instance is configured to use an encrypted boot or data volume, which requires the user to have kms:GenerateDataKey and kms:Decrypt on the customer-managed key. The scenario gives no indication that encryption was requested, and using the default AWS-managed key (aws/ebs) typically does not require an explicit KMS action in the user's policy. Therefore, a KMS-related permission problem would not be the root cause of a failed instance launch under these circumstances.
✗
The policy is attached to a group instead of the user.
Why it's wrong here
IAM permissions are aggregated across all identity-based policies attached to a user, including those inherited through group membership. Attaching a policy to a group still grants the permissions to any user in that group, so this would not cause an authorization failure. The actual issue is that the policy content itself is incomplete, not its attachment point, meaning the user lacks the necessary supporting EC2 actions rather than being denied because the policy is on a group.

Visual reference

Go deeper

SOA-C02 Security and Compliance Practice Question

Why each option matters

Option-by-option breakdown

Related to this question