AWS SOA-C02 Drill: Cross-Account Lambda S3 Access - IAM Role Trust Strategies

Jeff’s Note

#

Unlike generic exam dumps, ADH analyzes this scenario through the lens of a Real-World Site Reliability Engineer (SRE).

For SOA-C02 candidates, the confusion often lies in correctly configuring IAM roles across AWS accounts to enable Lambda’s cross-account access without over-privileging or breaking trust chains. In production, this is about knowing exactly which role assumes which, and how to properly establish role trust and policies to avoid permission errors and security pitfalls. Let’s drill down.

The Certification Drill (Simulated Question)

#

Scenario

#

BlueOcean Data Inc. operates two separate AWS accounts to isolate environments and billing. Their analytics team maintains an AWS Lambda function in Account Alpha that needs to process files stored in an S3 bucket in Account Beta. As the SRE, you are tasked with configuring IAM roles so that the Lambda function in Account Alpha can securely read objects from the S3 bucket in Account Beta. Both accounts must create the minimal necessary IAM roles to allow this cross-account access.

The Requirement:

#

Enable the Lambda function in Account Alpha to read S3 objects in Account Beta by correctly creating and configuring IAM roles and trust relationships.

The Options

#

• A) Create a Lambda execution role in Account Alpha that assumes a role in Account Beta. In Account Beta, create a role that the Lambda’s execution role can assume to gain S3 bucket access.
• B) Create a Lambda execution role in Account Alpha that has direct permissions to access the S3 bucket. In Account Beta, create a role for the Lambda to assume.
• C) Create a role in Account Alpha that the Lambda function can assume. Create a Lambda execution role in Account Beta that has permissions for the S3 bucket.
• D) Create a role in Account Alpha that the Lambda function assumes to access the S3 bucket. Create a Lambda execution role in Account Beta that assumes the role in Account Alpha.

Google adsense

#

leave a comment:

Correct Answer

#

A

Quick Insight: The SOA-C02 Imperative

#

To enable cross-account Lambda access to S3, Lambda’s execution role resides in the Lambda’s account (Account Alpha) and must have permission to assume a role in the S3 bucket’s account (Account Beta). This delegation approach follows the AWS security best practice of minimum privilege and least trust, avoiding direct cross-account permissions in the Lambda role itself.

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 A

The Winning Logic

#

The Lambda function’s execution role must be in the same AWS account where the Lambda function runs (Account Alpha). This role needs permission to assume a role in Account Beta that has the S3 bucket read permissions.

• In Account Beta, a dedicated IAM role grants read access to the S3 bucket, and its trust policy allows the role from Account Alpha to assume it.
• This two-role strategy creates a clear and secure trust boundary between accounts.

By assuming the role in Account Beta, the Lambda function operates with temporary credentials scoped to exactly what is needed, following the principle of least privilege.

The Trap (Distractor Analysis):

#

• Option B: Incorrect because the Lambda role in Account Alpha can’t directly access the S3 bucket in another account without assuming a role there. S3 policies alone won’t grant cross-account read access without role assumption.
• Option C: Incorrect role placement—Lambda execution role must be in the Lambda’s account, not in the S3 bucket’s account.
• Option D: Reverse trust relationship, making the S3 account’s Lambda execution role assume a role in the Lambda account, which doesn’t align with the actual resource ownership or function invocation pattern.

The Technical Blueprint

#

# Example AWS CLI snippet showing the trust relationship in Account Beta's IAM role JSON:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::AccountAlphaID:role/LambdaExecutionRole"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

# The Lambda execution role in Account Alpha must have permission to assume this role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::AccountBetaID:role/AccessS3Role"
    }
  ]
}

The Comparative Analysis

#

Real-World Application (Practitioner Insight)

#

Exam Rule

#

“For the exam, always pick AssumeRole with clear trust policies when Lambda needs to access resources in another AWS account.”

Real World

#

“In production, you might automate this setup with CloudFormation or Terraform, managing cross-account role setup and permissions to ensure consistent and auditable access management.”

(CTA) Stop Guessing, Start Mastering

#

Disclaimer

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