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.

• ✓

  IAM roles can be used by federated users.

  Why this is correct

  Federated users, such as those authenticated by an external identity provider via SAML 2.0 or web identity federation, can assume an IAM role to obtain temporary AWS credentials. The user's original identity is mapped to a role, and AWS STS issues scoped, time-limited access keys that abide by the role's trust and permissions policies. This allows external identities to access AWS resources without creating an IAM user and without distributing permanent credentials.

• ✗

  IAM roles are specific to an AWS region.

  Why it's wrong here

  IAM roles are global entities defined within an AWS account, not scoped to a specific region. Role definitions, including their policies and trust relationships, are stored in the IAM global service partition and appear across all regions in the management console. While the STS endpoint that issues temporary credentials is regional (e.g., sts.us-east-1.amazonaws.com), the role itself is not. Therefore, a role created in one region is usable in every region, unless a condition in its policy explicitly restricts usage geographically.

• ✗

  IAM roles cannot be attached to an EC2 instance.

  Why it's wrong here

  An IAM role can absolutely be attached to an EC2 instance using an instance profile, which is a container for the role. When an instance is launched with a role, the AWS credentials are made available through the instance metadata service (IMDS), and the instance automatically assumes the role to receive temporary credentials. This removes the need to manually place access keys on the instance, which is a security best practice. The role must have a trust policy allowing ec2.amazonaws.com as a principal.

• ✗

  IAM roles have permanent access keys.

  Why it's wrong here

  IAM roles do not have permanent access keys at all; they are identities, not credentials. Instead, when an entity assumes a role, AWS STS dynamically generates temporary security credentials consisting of an access key, secret access key, and session token, which expire after a configurable session duration (default one hour, up to 12 hours for role sessions). These temporary credentials include a session token that must be passed with every API call, making them inherently less risky than long-lived access keys because they are automatically rotated upon expiration.

• ✓

  IAM roles can be assumed by AWS services like EC2.

  Why this is correct

  AWS services such as EC2 are common principals for IAM roles. An EC2 instance can be launched with a role attached through an instance profile, causing the instance to assume the role automatically and receive temporary credentials from the instance metadata service. Applications running on the instance then make authenticated API calls using these credentials, eliminating the need to embed static keys. This pattern currently supports any service that can be configured with a service role, such as Lambda, ECS, and RDS.

Go deeper

Related to this question