SCS-C02 Identity and Access Management 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.

• ✗

  Regularly rotate IAM user access keys.

  Why it's wrong here

  Rotating IAM user access keys is a hygiene measure for long-lived credentials attached to a user identity, not to an EC2 instance. It neither changes the permissions of the instance profile nor addresses how an application on the instance gains AWS access. Since instance roles issue ephemeral, automatically rotated credentials, periodic manual rotation of user access keys is irrelevant to this scenario.

• ✗

  Attach the same role to all instances for simplicity.

  Why it's wrong here

  Attaching the same IAM role to every instance collapses the security boundary between different workloads. The role's policy would have to be the union of every application's requirements, creating unnecessarily broad permissions and making a compromise of any single instance expose all capabilities. It also prevents using resource-level conditions or scoped policies that distinguish environments, compliance boundaries, or application tiers.

• ✓

  Apply the principle of least privilege when defining role permissions.

  Why this is correct

  Enforcing least privilege means granting only the specific API actions and resources required for the application's function, and then further constraining them with conditions such as ec2:ResourceTag or aws:SourceIp. This limits the blast radius if the instance is compromised because a breached application can only perform the minimal set of operations. A role's policy is the sole authority for what temporary credentials obtained through the instance profile can do, so its precision directly determines the security posture.

• ✓

  Use an IAM role to grant permissions to applications running on EC2.

  Why this is correct

  An IAM role attached to an EC2 instance via an instance profile provides temporary security credentials through the instance metadata service (IMDSv2). The AWS SDK automatically retrieves, uses, and refreshes these credentials, so no long-term secrets ever need to be baked into the AMI or application code. This is the correct pattern because it relies on AWS-managed temporary credentials that automatically expire, reducing the risk of leaked static keys.

• ✗

  Store AWS access keys directly on the instance.

  Why it's wrong here

  Storing AWS access keys directly on the instance leaves a permanent, unencrypted secret on the filesystem or in environment variables that can be stolen through an application vulnerability, misconfigured user-data script, or snapshot access. Unlike instance-profile credentials, these static access keys do not rotate automatically and remain valid until manually deleted, even after the instance is terminated. This pattern also forces you to manage and distribute the keys across every instance, whereas an instance profile removes that burden entirely.

Go deeper

Related to this question