Courseiva
Design Secure Architectures →mediumMultiple Choice

SAA-C03 Design Secure Architectures Practice Question

A Lambda function in Account A must upload reports to an S3 bucket in Account B. Security does not want long-lived access keys anywhere, and the access should be easy to revoke from Account B. Which approach is best?

⚠ Common exam trap

Candidates often confuse security groups (network-layer controls) with IAM policies (identity-based access), or mistakenly think SCPs can grant cross-account permissions when they only act as guardrails.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Create an IAM role in Account B that Account A can assume through STS, then grant the role S3 permissions.

It uses cross-account IAM roles with AWS Security Token Service (STS) to grant temporary credentials to the Lambda function. This avoids long-lived access keys, and the permissions can be revoked immediately by modifying or deleting the role in Account B, meeting the security requirements.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • ✓

    Create an IAM role in Account B that Account A can assume through STS, then grant the role S3 permissions.

    Why this is correct

    Cross-account role assumption with AWS STS is the standard way to grant temporary access without sharing long-lived credentials. By placing the permissions on a role in Account B and controlling the trust policy there, the bucket-owning account keeps central control and can revoke access by changing the trust relationship or permissions. The Lambda execution role in Account A assumes the role when needed and receives short-lived credentials only.

  • ✗

    Create an IAM user in Account B and store its access keys in Lambda environment variables.

    Why it's wrong here

    Storing an IAM user's access keys in Lambda environment variables creates long-lived static credentials that require manual rotation and can be exposed in the function's configuration, logs, or through code. This approach also violates least privilege because a single IAM user with S3 write access becomes a standing privilege that cannot be scoped per invocation. Using STS to assume a role gives short-lived, automatically rotated credentials with a narrow trust boundary.

    When this WOULD be correct

    This option would be correct if the question stated that the Lambda function must use long-lived credentials (e.g., for legacy system compatibility) and the security requirement to avoid them was absent. It might also be acceptable in a single-account scenario where IAM users are the only option.

  • ✗

    Attach a security group to the Lambda function that allows outbound traffic to the bucket.

    Why it's wrong here

    Security groups are stateful network firewalls that filter traffic at the elastic network interface level, so they apply only to VPC-based resources and do not perform API-level authorization for S3. Lambda functions without VPC connectivity cannot have a security group attached at all, and even if one is attached, S3 access decisions are made by IAM, not network ACLs or security groups. The correct network abstraction for S3 is a VPC endpoint paired with an IAM policy.

    When this WOULD be correct

    A question where a Lambda function needs to access an S3 bucket in the same account, and the concern is network-level restriction (e.g., VPC endpoint). Then attaching a security group to the Lambda function (via VPC configuration) to allow outbound traffic to the S3 VPC endpoint would be correct.

  • ✗

    Use AWS Organizations SCPs to grant the Lambda function permission to write to the bucket.

    Why it's wrong here

    SCPs in AWS Organizations are account-level permission boundaries that can only limit the maximum permissions IAM policies can grant; they cannot grant any identity or resource access on their own. An SCP that lists s3:PutObject doesn't create a trust relationship between accounts or authorize the Lambda execution role. To allow cross-account uploads, you still need an explicit IAM role or bucket policy with a principal that the Lambda can use.

    When this WOULD be correct

    An SCP would be correct if the question asked how to prevent all accounts in an organization from writing to a specific S3 bucket, or to enforce a policy that restricts S3 bucket access across multiple accounts for compliance reasons.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.

✓Create an IAM role in Account B that Account A can assume through STS, then grant the role S3 permissions.Correct answer▾

Why this is correct

Cross-account role assumption with AWS STS is the standard way to grant temporary access without sharing long-lived credentials. By placing the permissions on a role in Account B and controlling the trust policy there, the bucket-owning account keeps central control and can revoke access by changing the trust relationship or permissions. The Lambda execution role in Account A assumes the role when needed and receives short-lived credentials only.

✗Create an IAM user in Account B and store its access keys in Lambda environment variables.Wrong answer — click to see why▾

Why this is wrong here

Option B uses long-lived access keys stored in Lambda environment variables, violating the security requirement to avoid long-lived credentials. Additionally, revoking access requires deleting or rotating the keys in Account B, which is less straightforward than removing a role trust policy.

★ When this WOULD be the correct answer

This option would be correct if the question stated that the Lambda function must use long-lived credentials (e.g., for legacy system compatibility) and the security requirement to avoid them was absent. It might also be acceptable in a single-account scenario where IAM users are the only option.

Why candidates choose this

Candidates may think storing keys in environment variables is acceptable because it avoids hardcoding, and they may overlook the 'no long-lived access keys' constraint. The simplicity of creating an IAM user and directly using its keys can seem easier than setting up cross-account roles.

✗Attach a security group to the Lambda function that allows outbound traffic to the bucket.Wrong answer — click to see why▾

Why this is wrong here

Security groups control network traffic at the instance level, not S3 bucket access. They cannot grant or deny API-level permissions to write objects; S3 uses IAM policies, bucket policies, or ACLs for authorization.

★ When this WOULD be the correct answer

A question where a Lambda function needs to access an S3 bucket in the same account, and the concern is network-level restriction (e.g., VPC endpoint). Then attaching a security group to the Lambda function (via VPC configuration) to allow outbound traffic to the S3 VPC endpoint would be correct.

Why candidates choose this

Candidates may confuse network access control (security groups) with identity-based access control (IAM), thinking that allowing outbound traffic to the bucket's IP range is sufficient to grant write permissions.

✗Use AWS Organizations SCPs to grant the Lambda function permission to write to the bucket.Wrong answer — click to see why▾

Why this is wrong here

SCPs are used to centrally control permissions for all accounts in an AWS Organization, not to grant cross-account access to a specific Lambda function. They can only deny or allow permissions at the account level, not to individual resources like a Lambda function.

★ When this WOULD be the correct answer

An SCP would be correct if the question asked how to prevent all accounts in an organization from writing to a specific S3 bucket, or to enforce a policy that restricts S3 bucket access across multiple accounts for compliance reasons.

Why candidates choose this

Candidates may confuse SCPs with IAM policies, thinking they can grant fine-grained permissions to individual resources, or they may overestimate the scope of SCPs as a tool for cross-account access.

Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Quick reference

AWS S3 Storage Class Comparison

Storage ClassMin DurationRetrievalUse Case
S3 StandardNoneImmediateFrequently accessed data
S3 Standard-IA30 daysImmediateInfrequent access, rapid retrieval
S3 One Zone-IA30 daysImmediateNon-critical infrequent data
S3 Intelligent-TieringNoneImmediate–hoursUnknown or changing access patterns
S3 Glacier Instant90 daysMillisecondsArchive with instant retrieval
S3 Glacier Flexible90 daysMinutes–hoursArchive, flexible retrieval
S3 Glacier Deep Archive180 daysHoursLong-term compliance archive

About these practice questions

Courseiva writes every SAA-C03 question from scratch — 935 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.