AWS DVA-C02 Drill: Cross-Account IAM Roles - Accessing DynamoDB Securely

Jeff’s Note

#

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

For DVA-C02 candidates, the confusion often lies in how to properly obtain and use temporary credentials for cross-account resource access without hardcoding keys. In production, this is about knowing exactly which API to call (AssumeRole vs GetSessionToken) and how to integrate role assumption into app code securely. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

TechNova Solutions manages sensitive customer data that resides in a centralized Amazon DynamoDB table located within AWS Account Alpha. Their engineering team is developing a robust application that runs on Amazon EC2 instances launched in a different AWS account, Beta. The EC2 application needs to read and update records in the DynamoDB table in Account Alpha.

To enable this securely, the security admin in Account Alpha has created an IAM Role named CrossAccountDDBAccess with permissions scoped to the DynamoDB table in Account Alpha. The trust policy for this role explicitly authorizes Account Beta to assume the role.

The Requirement:

#

What combination of steps should TechNova’s developers take within Account Beta to allow their EC2-hosted application to access the DynamoDB table securely in Account Alpha? (Choose Two.)

The Options

#

• A) Grant the existing IAM role attached to the EC2 instances permission to assume the CrossAccountDDBAccess role in Account Alpha.

• B) Grant the EC2 IAM role direct permissions to access the DynamoDB table in Account Alpha.

• C) Modify the application code to use the AWS SDK to retrieve temporary credentials from the EC2 IAM role to access the DynamoDB table.

• D) Modify the application code to call the AssumeRole API to obtain temporary credentials scoped to the DynamoDB table access.

• E) Modify the application code to call the GetSessionToken API to obtain temporary credentials scoped to the DynamoDB table access.

Google adsense

#

leave a comment:

Correct Answer

#

A) Grant the EC2 IAM role permission to assume the CrossAccountDDBAccess role.
D) Modify the application code to call the AssumeRole API to obtain temporary credentials.

Quick Insight: The Developer Imperative

#

• The key is understanding that temporary security credentials for cross-account DynamoDB access must be obtained by assuming the cross-account role.
• GetSessionToken only works with the current account’s credentials and cannot be used for cross-account role assumption.
• You cannot grant direct access across accounts without using role assumption.
• Your app code needs to explicitly call AssumeRole to get credentials scoped by the cross-account role trust and permissions.

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

#

Options A and D

The Winning Logic

#

• Option A: The IAM role attached to the EC2 instances in Account Beta must have permission to call sts:AssumeRole on the CrossAccountDDBAccess role in Account Alpha. This enables the EC2 instances’ role to assume the cross-account role securely without long-lived credentials.

• Option D: The application running on the EC2 instances must invoke the AssumeRole API (via AWS SDK) to obtain temporary security credentials scoped by the permissions of the CrossAccountDDBAccess role. These temporary credentials are then used to make the authorized DynamoDB calls.

Together, these steps implement the AWS recommended pattern for secure cross-account access using role assumption with temporary credentials.

The Trap (Distractor Analysis):

#

• Why not Option B?
  Granting the EC2 role direct permission to access a resource in another account is invalid since IAM roles do not have cross-account permissions by default. The cross-account trust relationship and AssumeRole API must mediate.

• Why not Option C?
  The EC2 instance metadata service only provides credentials for the EC2 role in Account Beta. It cannot provide credentials scoped to the cross-account DynamoDB table. The app must call AssumeRole to get those.

• Why not Option E?
  GetSessionToken is designed to get temporary credentials for the current account’s IAM user or role; it does not allow stepping into a role in another account.

The Technical Blueprint

#

Code Snippet: Using AssumeRole in application (Python boto3 example)

#

import boto3

# Role ARN in Account Alpha to assume
role_arn = "arn:aws:iam::ACCOUNT_ALPHA_ID:role/CrossAccountDDBAccess"

# AssumeRole client using EC2 instance role credentials by default
sts_client = boto3.client('sts')

# Assume the cross-account role
response = sts_client.assume_role(
    RoleArn=role_arn,
    RoleSessionName="EC2AppSession"
)

# Extract temporary credentials
credentials = response['Credentials']

# Use temporary credentials to create DynamoDB client
ddb_client = boto3.client(
    'dynamodb',
    aws_access_key_id=credentials['AccessKeyId'],
    aws_secret_access_key=credentials['SecretAccessKey'],
    aws_session_token=credentials['SessionToken'],
)

# Now make DynamoDB calls with ddb_client

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

“For cross-account AWS resource access, always use IAM role assumption (AssumeRole)—never try to assign permissions directly to roles/users in different AWS accounts.”

Real World

#

“In actual production environments, automating role assumption with SDK credential providers ease integration and securely separate privileges across accounts.”

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

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