AWS DVA-C02 Drill: IAM Roles on EC2 Instances - Debugging AccessDeniedException

Jeff’s Note

#

Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Lead Developer.

For AWS DVA-C02 candidates, the confusion often lies in how the AWS SDK sources credentials when switching from IAM User keys to EC2 Instance Roles. In production, this is about knowing exactly how environment variables and the Instance Metadata Service affect authentication behavior. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

CloudMetrics Inc., a SaaS startup, has a fleet of EC2 instances hosting their Python-based microservices responsible for persisting telemetry data in Amazon DynamoDB. Initially, developers embedded IAM user access keys as environment variables for AWS SDK authentication. To improve security, the DevOps team assigned a suitable IAM role to each EC2 instance and deleted the associated IAM users.

After restarting the services, CloudMetrics’ engineers observe AccessDeniedException errors in the application logs when the Python app attempts to write to DynamoDB using boto3. However, when they run DynamoDB CLI commands on the same instance using their personal IAM user accounts, operations succeed without error.

The Requirement:

#

Identify the MOST probable cause of the SDK authentication failures despite correctly attached IAM roles on the EC2 instances.

The Options

#

• A) IAM policy changes might take several minutes to propagate to the instance role permissions.
• B) The Python application is still using old environment variable credentials instead of the EC2 instance role credentials.
• C) The AWS SDK for Python (boto3) does not support credentials obtained from EC2 instance roles.
• D) The instance’s security group blocks access to the EC2 instance metadata service (http://169.254.169.254).

Google adsense

#

leave a comment:

Correct Answer

#

B

Quick Insight: The Developer Imperative

#

The fundamental takeaway is understanding how the AWS SDK credential provider chain prioritizes environment variables over instance metadata credentials. Even though the IAM user was deleted, stale environment variables persist and cause access denial.

Content Locked: The Expert Analysis

#

You’ve identified the answer. But do you know the implementation details that separate a Junior from a Senior?

The Expert’s Analysis

#

Correct Answer

#

Option B

The Winning Logic

#

The boto3 SDK follows a credential provider chain when authenticating:

1. It first checks for static credentials passed via environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, etc.).
2. If not found, it falls back to instance profile credentials retrieved via the EC2 instance metadata service at http://169.254.169.254.
3. Finally, it checks AWS CLI config files or other sources.

In this scenario, the application still has the old access keys set in environment variables—even though the corresponding IAM user was deleted—which causes immediate AccessDeniedException errors because those credentials no longer have permissions. The SDK never attempts to use the EC2 instance role credentials.

The developer must remove these environment variables so the SDK falls back to the instance metadata service credentials, which are valid through the attached IAM role.

Note: Running CLI commands manually works because those commands likely pick up credentials from the developer’s personal AWS credentials stored in ~/.aws/credentials or environment variables on their user account.

The Trap (Distractor Analysis):

#

• Why not A?
  IAM policy changes propagate almost instantly for attached roles. A few minutes delay is rare and in this case irrelevant—the problem is stale credentials.

• Why not C?
  boto3 fully supports instance role credentials via the metadata service. This is standard practice.

• Why not D?
  If the security group blocked access to the metadata service, the SDK would fall back to errors indicating no credentials found at all (NoCredentialsError), not an AccessDeniedException. Also, instance metadata endpoint is private to the instance and usually unrestricted by security groups.

The Technical Blueprint

#

For Developers, a relevant snippet to clear environment variables before app startup:

# Unset legacy environment variables in the app server session
unset AWS_ACCESS_KEY_ID
unset AWS_SECRET_ACCESS_KEY
unset AWS_SESSION_TOKEN

# Then restart the Python app
python app.py

In Python boto3, you can also explicitly force usage of instance metadata credentials by not passing explicit credentials:

import boto3

# Use default session, will pick up instance profile if no env vars set
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('TelemetryData')
response = table.put_item(Item={'id': '123', 'metric': 'cpu_usage'})

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the exam, always pick B) when you see persistent AccessDeniedException after switching from IAM users to roles on EC2 instances.

Real World

#

In real environments, legacy environment variables or config files are common culprits behind seemingly inexplicable access issues post-migration to roles. Auditing environment variables and config sources is a crucial troubleshooting step.

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

This is a study note based on simulated scenarios for the AWS DVA-C02 exam.