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 delegate cross-account permissions using IAM roles and trust policies. In production, this is about knowing exactly how role assumption and resource-based policies interact to enable secure, least-privilege cross-account Kinesis stream access. Let’s drill down.”
The Certification Drill (Simulated Question) #
Scenario #
TechPulse Solutions is deploying a real-time analytics application on Amazon EC2 instances running in their primary AWS account (Account Alpha). The application needs to consume data from an existing Amazon Kinesis data stream that resides in a separate AWS account (Account Beta). As the lead developer, you must enable the application running in Account Alpha to read from the Kinesis stream in Account Beta securely and efficiently.
The Requirement: #
How should you configure IAM roles and policies to grant the EC2 instances in Account Alpha the necessary read permissions on the Kinesis data stream located in Account Beta? (Choose two.)
The Options #
- A) Attach Amazon Kinesis read permissions to the EC2 instance profile role in Account Alpha.
- B) Create an IAM role with Kinesis read permissions in Account Beta.
- C) Add a trust policy to both Account Alpha’s instance profile role and Account Beta’s IAM role allowing the instance profile role to assume the IAM role.
- D) Add a trust policy to the instance profile role and IAM role in Account Beta to allow reads directly from the stream.
- E) Add a resource-based policy on the Kinesis stream in Account Beta to allow read access from the instance profile role in Account Alpha.
Google adsense #
leave a comment:
Correct Answer #
A and C
Quick Insight: The Developer Imperative #
The key lies in setting the instance profile in Account Alpha with read permissions and enabling it to assume a cross-account IAM role granted permissions in Account Beta through an appropriate trust policy. Resource-based policies on Kinesis streams are not supported, so option E is a common misconception.
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 C
The Winning Logic #
-
Option A: You must update the EC2 instance profile role in Account Alpha with permissions that allow the
sts:AssumeRolecall on the IAM role in Account Beta. This role itself does not need Kinesis read permissions—just permission to assume the cross-account role. -
Option C: The IAM role in Account Beta must grant trusted relationship (trust policy) allowing the EC2 instance profile role from Account Alpha to assume it, establishing secure cross-account role assumption.
-
The IAM role in Account Beta holds the actual Kinesis read permissions scoped to least privilege.
-
This approach leverages role assumption rather than trying to directly grant permissions via resource policies or trust policies that do not apply to Kinesis streams.
The Trap (Distractor Analysis) #
-
Option B: Creating a role with read permissions in Account Beta is necessary but insufficient without allowing the EC2 instance profile to assume it.
-
Option D: Misunderstands trust policies; trust policies define who can assume a role, they do not control stream read access.
-
Option E: Kinesis data streams do not support resource-based policies for granting access to IAM principals. This usually trips up candidates assuming S3-like behavior.
The Technical Blueprint #
# Step 1: Attach read permission policy to IAM role in Account Beta (example JSON)
aws iam create-role --role-name KinesisCrossAccountRole --assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"AWS": "arn:aws:iam::ACCOUNT_ALPHA_ID:role/EC2InstanceProfileRole"},
"Action": "sts:AssumeRole"
}]
}'
# Attach Kinesis read permissions to this role
aws iam put-role-policy --role-name KinesisCrossAccountRole --policy-name ReadKinesisStream --policy-document '{
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":["kinesis:GetRecords","kinesis:GetShardIterator","kinesis:DescribeStream","kinesis:ListStreams"],
"Resource":"arn:aws:kinesis:region:ACCOUNT_BETA_ID:stream/YourStreamName"
}
]
}'
# Step 2: Update EC2 instance profile role in Account Alpha to allow AssumeRole on the cross-account role
aws iam put-role-policy --role-name EC2InstanceProfileRole --policy-name AllowAssumeCrossAccountRole --policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::ACCOUNT_BETA_ID:role/KinesisCrossAccountRole"
}]
}'
The Comparative Analysis #
| Option | API Complexity | Performance | Use Case |
|---|---|---|---|
| A | Low - Add inline policy or attach managed policy | Native IAM role update | Grants permission to assume cross-account role |
| B | Medium - Role creation in cross account | N/A | Creates role with Kinesis permissions but no trust relationship |
| C | Medium - Trust policy configuration | Instantaneous | Enables secure role assumption cross-account |
| D | Misunderstood concept | N/A | Trust policies can’t be applied to instance profile roles directly |
| E | Invalid - Kinesis streams do not support resource-based policies | N/A | Misconception from S3 experience |
Real-World Application (Practitioner Insight) #
Exam Rule #
“For the exam, always pick AssumeRole when you see cross-account access with EC2 and non-S3 services.”
Real World #
“In production, you’ll often combine role assumption with temporary credentials generated via SDK calls to manage delegation securely and avoid long-term credential leakage.”
(CTA) Stop Guessing, Start Mastering #
Disclaimer
This is a study note based on simulated scenarios for the AWS DVA-C02 exam.