DVA-C02 · Question #233
A company requires that all applications running on Amazon EC2 use IAM roles to gain access to AWS services. A developer is modifying an application that currently relies on IAM user access keys store
The correct answer is B. Disabled environment variable credentials are still being used by the application.. Option B is correct because the AWS SDK credential provider chain checks environment variables before instance metadata (IAM role credentials), so the old AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY environment variables are still present and being picked up - but since the IAM use
Question
A company requires that all applications running on Amazon EC2 use IAM roles to gain access to AWS services. A developer is modifying an application that currently relies on IAM user access keys stored in environment variables to access Amazon DynamoDB tables using boto, the AWS SDK for Python. The developer associated a role with the same permissions as the IAM user to the EC2 instance, then deleted the IAM user. When the application was restarted, the AWS AccessDeniedException messages started appearing in the application logs. The developer was able to use their personal account on the server to run DynamoDB API commands using the AWS CLI. What is the MOST likely cause of the exception?
Options
- AIAM policies might take a few minutes to propagate to resources.
- BDisabled environment variable credentials are still being used by the application.
- CThe AWS SDK does not support credentials obtained using an instance role.
How the community answered
(61 responses)- A16% (10)
- B75% (46)
- C8% (5)
Explanation
Option B is correct because the AWS SDK credential provider chain checks environment variables before instance metadata (IAM role credentials), so the old AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY environment variables are still present and being picked up - but since the IAM user was deleted, those keys are now invalid, causing AccessDeniedException.
Why A is wrong: IAM policy propagation delays are real but measured in seconds, not persistent errors - the developer confirmed the role works fine via the AWS CLI, so propagation is not the issue.
Why C is wrong: The AWS SDK absolutely supports instance role credentials via the EC2 Instance Metadata Service (IMDS); this is a core, well-supported feature of boto/boto3 and all AWS SDKs.
The CLI worked for the developer's personal account because the CLI was not inheriting those stale environment variables from the application's process environment - it either used a different profile or had no conflicting env vars set.
Memory tip: Think of the SDK credential chain as a priority list - environment variables always win over instance role metadata. If old env vars linger after a migration to IAM roles, the SDK never even reaches the instance role. "Env vars block the role."
Topics
Community Discussion
No community discussion yet for this question.