Skip to main content

AWS DVA-C02 Drill: Cross-Account Kinesis Access - Role Assumption Nuances

Jeff Taakey
Author
Jeff Taakey
21+ Year Enterprise Architect | AWS SAA/SAP & Multi-Cloud Expert.

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:AssumeRole call 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.

The DevPro Network: Mission and Founder

A 21-Year Tech Leadership Journey

Jeff Taakey has driven complex systems for over two decades, serving in pivotal roles as an Architect, Technical Director, and startup Co-founder/CTO.

He holds both an MBA degree and a Computer Science Master's degree from an English-speaking university in Hong Kong. His expertise is further backed by multiple international certifications including TOGAF, PMP, ITIL, and AWS SAA.

His experience spans diverse sectors and includes leading large, multidisciplinary teams (up to 86 people). He has also served as a Development Team Lead while cooperating with global teams spanning North America, Europe, and Asia-Pacific. He has spearheaded the design of an industry cloud platform. This work was often conducted within global Fortune 500 environments like IBM, Citi and Panasonic.

Following a recent Master’s degree from an English-speaking university in Hong Kong, he launched this platform to share advanced, practical technical knowledge with the global developer community.


About This Site: AWS.CertDevPro.com


AWS.CertDevPro.com focuses exclusively on mastering the Amazon Web Services ecosystem. We transform raw practice questions into strategic Decision Matrices. Led by Jeff Taakey (MBA & 21-year veteran of IBM/Citi), we provide the exclusive SAA and SAP Master Packs designed to move your cloud expertise from certification-ready to project-ready.