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.

• ✓

  Create an IAM role with a policy that allows dynamodb:GetItem on the 'Orders' table, create an instance profile, add the role to the profile, and launch the EC2 instance with the instance profile

  Why this is correct

  This is the correct and canonical method. Create an IAM role that includes a policy granting the `dynamodb:GetItem` action on the `Orders` table, define a trust policy that lets the EC2 service (`ec2.amazonaws.com`) assume it, and then create an instance profile containing that role. When you launch the EC2 instance with the instance profile, AWS automatically supplies temporary credentials through the instance metadata service (IMDSv2), so the SDK can read from DynamoDB without any stored keys. This avoids long-lived credentials and is the supported mechanism for giving an EC2 instance permissions.

• ✗

  Create an instance profile and attach a policy to it, then launch the EC2 instance with the instance profile

  Why it's wrong here

  An instance profile is not a policy entity; it is a container that holds an IAM role and provides that role's credentials to the EC2 instance via its metadata service. You cannot attach a managed or inline policy to an instance profile — the API will reject it because the profile lacks an identity for IAM to evaluate. The correct approach is to create a role, attach the policy to that role, and then add the role to the instance profile. This option fails because it attempts to treat the profile as a policy target.

• ✗

  Create an IAM role with the required policy, then attach the role directly to the EC2 instance during launch

  Why it's wrong here

  You cannot attach an IAM role directly to an EC2 instance as if it were a resource; instead, you must associate the role with an instance profile, which is the wrapper the EC2 service uses to establish the role assumption. When you launch an instance in the EC2 API, the parameter is an instance profile name/ARN, not a role's ARN, and any attempt to plug a role directly into those launch parameters will be invalid. In the AWS Management Console, the dropdown for an IAM role during launch actually lists instance profiles, which is why this option misinterprets the console flow. The role gets assumed through the profile, not attached.

• ✗

  Create an IAM user with programmatic access, store the access key in a secure S3 bucket, and have the EC2 instance retrieve the credentials at startup

  Why it's wrong here

  Hardcoding or storing IAM user access keys in an S3 bucket and then harvesting them at startup is insecure because the EC2 instance still has to bootstrap with some other set of credentials to get into the bucket — there is no way around that chicken-and-egg problem without eventually creating a local copy of a static secret. It also perpetuates long-lived credentials, which magnifies any leak from a compromised S3 bucket, exposed startup logs, or a user who later leaves. AWS best practice is to rely on temporary credentials delivered via an instance profile, not to copy static keys onto a server. This option violates that pattern.

Go deeper

Related to this question