AWS DVA-C02 Drill: Cross-Account Lambda IAM - Principle of Least Privilege

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 to properly set up cross-account permissions for Lambda invoking AWS APIs with minimal privileges. In production, this is about knowing exactly when to use AssumeRole versus direct permissions and how trust relationships work across accounts. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

NimbusSoft, a software consultancy, maintains a shared AWS account for centralized compute resources including Lambda functions, while its development teams maintain separate AWS development accounts. One Lambda function running in the shared account must query EC2 information (via the ec2:DescribeInstances API) located in the development accounts. A developer is tasked with configuring permissions to allow this Lambda function to call ec2:DescribeInstances in those development accounts — but adhering strictly to the principle of least privilege.

The Requirement:

#

Configure cross-account permissions so the Lambda function in the shared account can perform ec2:DescribeInstances only in the development accounts, granting the minimum necessary permissions.

The Options

#

• A) Create an IAM role in the shared account and attach the ec2:DescribeInstances permission to this role. Establish a trust relationship allowing the development accounts to assume this role. Then update the Lambda function’s IAM role in the shared account by adding the ec2:DescribeInstances permission.
• B) Create an IAM role in the development accounts with the ec2:DescribeInstances permission. Establish a trust relationship allowing the shared account to assume this role. Update the Lambda function’s IAM role in the shared account by granting it iam:AssumeRole permission to this role.
• C) Create an IAM role in the shared account with the ec2:DescribeInstances permission. Establish a trust relationship with the development accounts to assume this role. Update the Lambda function’s IAM role by adding iam:AssumeRole permissions.
• D) Create an IAM role in the development accounts with ec2:DescribeInstances permission. Establish a trust relationship for the shared account to assume this role. Update the Lambda function’s IAM role in the shared account by adding ec2:DescribeInstances permission.

Google adsense

#

leave a comment:

Correct Answer

#

B

Quick Insight: The Developer IAM Imperative

#

• For Developers: The core pattern for cross-account API calls from Lambda is to create an IAM role in the target account (development accounts here) with necessary service permissions, allow the source account (shared Lambda account) to assume that role, and then grant the Lambda function permission to assume that role via iam:AssumeRole. This adheres to least privilege by not duplicating permissions across accounts, and relies on temporary credentials scoped to precise resources.

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 Lambda function runs in the shared account, but needs to query EC2 instances in the development accounts. Therefore, permissions granting ec2:DescribeInstances must exist in the development accounts where the EC2 resources reside.
• To allow cross-account access securely and adhering to least privilege, you create an IAM role in each development account with a policy allowing ec2:DescribeInstances.
• This role must trust the shared account — that is, its trust policy allows the shared account (Lambda’s account) to assume it.
• The Lambda function’s execution role in the shared account must have the permission to iam:AssumeRole on these roles in the development accounts. At runtime, the Lambda function assumes the development account role, getting short-lived credentials scoped to those permissions.
• This provides least privilege by limiting the permissions only to development accounts’ resources and restricting Lambda’s role to assuming those target roles rather than having broad permissions.
• Without iam:AssumeRole, cross-account access isn’t possible in this model.

The Trap (Distractor Analysis)

#

• Why not A or C? These suggest creating the role in the shared account with ec2:DescribeInstances, then trusting development accounts to assume it. But DescribeInstances permissions in the shared account don’t give access to EC2 instances in the development accounts. Also, trusting development accounts to assume shared-account roles does not serve this cross-account pattern and violates least privilege.
• Why not D? It correctly creates a role in development accounts with proper permissions, but incorrectly states to add ec2:DescribeInstances permission to Lambda’s role in the shared account — without iam:AssumeRole, Lambda cannot use the development account’s role.

The Technical Blueprint

#

# Example IAM role trust policy in the development account allowing shared account to assume role
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::SHARED_ACCOUNT_ID:root"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

# Inline policy attached to the role in development account
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:DescribeInstances",
            "Resource": "*"
        }
    ]
}

# Inline policy attached to the Lambda execution role in shared account, to allow assume role
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::DEV_ACCOUNT_ID:role/DescribeEC2Role"
        }
    ]
}

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

“For Lambda functions accessing resources across accounts, always use IAM roles in the target account with AssumeRole permissions granted to Lambda’s execution role.”

Real World

#

“In production, you might also automate this with CI/CD pipelines to propagate role ARNs and permissions, and use AWS SDKs with STS.assumeRole calls for temporary credentials.”

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

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