How Can Lambda Securely List EC2 Instances in Another Account?

SOA-C03 By islever Editorial Last updated Oct 20, 2026

Implement and manage security and compliance tools and policies. Implement strategies to protect data and infrastructure.

Short answer

B Configure the Lambda execution role to assume a scoped cross-account IAM role in the EC2 account via STS AssumeRole.

Question

A company has AWS accounts in an organization in AWS Organizations. The company has built an AWS Lambda function in one account. The Lambda function needs to retrieve a list of Amazon EC2 instances that are running in another account.
Which solution will provide this access MOST securely?

Create an IAM user in the account where the EC2 instances are running. Collect access keys from the user. Store these credentials in AWS Systems Manager Parameter Store in the account of the Lambda function. Configure the Lambda function to use the access key and the secret key.
Configure the Lambda function's execution role to assume a cross-account IAM role in the account where the EC2 instances are running. Modify the trust policy of the cross-account role to allow the Lambda function to assume the role. Add the AWS STS AssumeRole API operation to the Lambda function's code. Correct Answer
From the management account in the organization, call the Organizations CreatePolicy API operation to create a new service control policy (SCP). Configure the SCP to grant lambda:InvokeFunction permission. Assign the SCP to the organization root.
Create a new resource-based policy for the Lambda function. In the policy, set the Principal to "*" and set the Action to lambda:InvokeFunction. Create a condition on the policy to allow access when the value of the aws:PrincipalOrgID condition key matches the organization's ID.

Key Takeaways

It tests least-privilege cross-account delegation, and the trap is treating SCPs or Lambda resource policies as mechanisms that grant EC2 read access.

This question tests how an AWS Lambda function in one account can securely read EC2 instance data from another account. The page establishes that scoped cross-account IAM role assumption with AWS STS is the most secure answer, not static access keys, SCPs, or a broad Lambda resource policy.

Common mistake: The most common wrong answer is A, storing IAM user access keys in Parameter Store, because it looks like centralized credential management but creates long-lived secrets that must be rotated and can be leaked.

Expert Analysis

Why the Answer Is Correct

Option B follows the standard AWS cross-account access pattern: the Lambda execution role calls STS AssumeRole to obtain temporary credentials for a role in the account that owns the EC2 instances. That cross-account role can be tightly scoped to only the EC2 describe/list actions the function needs, and its trust policy can allow only the specific Lambda execution role. This avoids long-lived secrets and keeps permissions auditable through IAM and CloudTrail. It is the most secure option because it combines temporary credentials, least privilege, and explicit cross-account trust.

Why the Other Options Are Wrong

Option A creates an IAM user with access keys and stores them in Parameter Store, which introduces long-lived credentials that must be rotated and protected across accounts. Option C misuses an SCP: SCPs are organization guardrails that limit maximum permissions, not a way to grant lambda:InvokeFunction or EC2 read access. Option D creates a Lambda resource-based policy that only controls who may invoke the function; setting Principal to "*" with an aws:PrincipalOrgID condition does not give the function permission to list EC2 instances and is broader than necessary.

Community Comment Notes

Bad_Mat's comment supports B by emphasizing temporary STS credentials and least privilege, noting that the cross-account role can be scoped to only describe or list EC2 instances. The comment also describes role assumption as the standard IAM pattern for cross-account resource access, which matches AWS guidance for this scenario. No comment argues convincingly for the static-key, SCP, or resource-policy alternatives.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

When a question asks for the MOST secure cross-account access, prefer temporary credentials from IAM role assumption over stored access keys. Remember that SCPs are permission guardrails, not grants, and resource-based policies on Lambda control invocation rather than the function's outbound EC2 permissions.

Frequently Asked Questions

Why is storing IAM user access keys in Parameter Store less secure than assuming a role?

Access keys are long-lived secrets that must be rotated and can leak; STS temporary credentials from role assumption expire automatically and are scoped to the role.

What does the aws:PrincipalOrgID condition in option D actually control?

It limits who can invoke the Lambda function to principals in the organization, but it does not grant the function permission to list EC2 instances and Principal "*" is still broad.

More SOA-C03 FAQ →

Discussion 1 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 1

Bad_Mat 👍 1 Answered B

Why Option B is CorrectTemporary Credentials: Uses AWS Security Token Service (AWS STS) to issue short-lived tokens instead of permanent access keys.Least Privilege: The cross-account role in the second account can be precisely scoped with permissions solely to describe or list EC2 instances.Clean Architecture: Standard IAM assumption pattern recommended for cross-account resource access from compute services.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Practice All SOA-C03 Questions

Access 100 questions with complete answers and detailed explanations.

View Full SOA-C03 Practice Test →

← Back to SOA-C03 Study Guide