Cross-Account SNS to Lambda Invocation

SAA-C03 By islever Editorial Last updated

Short answer

AC Create an IAM resource policy for the Lambda function that allows Amazon SNS to invoke the function and create an IAM policy for the SNS topic that allows the Lambda function to subscribe to the topic.

Question

A media company has a multi-account AWS environment in the us-east-1 Region. The company has an Amazon Simple Notification Service (Amazon SNS) topic in a production account that publishes performance metrics. The company has an AWS Lambda function in an administrator account to process and analyze log data. The Lambda function that is in the administrator account must be invoked by messages from the SNS topic that is in the production account when significant metrics are reported. Which combination of steps will meet these requirements? (Choose two.)
  1. Create an IAM resource policy for the Lambda function that allows Amazon SNS to invoke the function. Correct Answer
  2. Implement an Amazon Simple Queue Service (Amazon SQS) queue in the administrator account to buffer messages from the SNS topic that is in the production account. Configure the SQS queue to invoke the Lambda function.
  3. Create an IAM policy for the SNS topic that allows the Lambda function to subscribe to the topic. Correct Answer
  4. Use an Amazon EventBridge rule in the production account to capture the SNS topic notifications. Configure the EventBridge rule to forward notifications to the Lambda function that is in the administrator account.
  5. Store performance metrics in an Amazon S3 bucket in the production account. Use Amazon Athena to analyze the metrics from the administrator account.

Key Takeaways

The core trap is assuming a single permission grant suffices; successful cross-account invocation requires mutual explicit permissions on both the subscriber (Lambda) and the publisher (SNS).

This question addresses configuring secure cross-account communication between Amazon SNS and AWS Lambda by establishing the necessary IAM resource policies for both services.

Common mistake: Many learners select Option B (SQS), which adds unnecessary complexity and buffering when direct subscription is supported, or they choose only one of the required policy steps.

Expert Analysis

Why the Answer Is Correct

To invoke a Lambda function in Account B from an SNS topic in Account A, two distinct permission boundaries must be bridged. First, the Lambda function must explicitly allow the SNS service principal to invoke it via a Resource Policy (Option A). Second, the SNS topic must explicitly allow the specific Lambda ARN to subscribe to it via its Access Policy (Option C). These two steps create the secure handshake required for cross-account event delivery without intermediate queues.

Why the Other Options Are Wrong

Option B introduces an SQS queue, which changes the architecture to a pull-based model rather than the requested push/subscription model, adding latency and cost unnecessarily. Option D suggests using EventBridge, but EventBridge cannot directly trigger Lambda based solely on an SNS topic notification without additional complex rule configurations that are not implied here. Option E proposes storing metrics in S3, which completely ignores the requirement to invoke the Lambda function upon metric reporting.

Community Comment Notes

The community consensus strongly favors options A and C, with many users noting that "AWS services already exist only permissions are missing" (as noted by user dhewa). Several comments highlight that while SQS (Option B) is a valid pattern for decoupling, it is not the correct answer for this specific direct invocation scenario. User Anyio correctly explained that the SNS console allows adding a cross-account Lambda subscription, which inherently requires these two policy adjustments.

Official Reference

https://docs.aws.amazon.com/sns/latest/dg/sns-cross-account-subscription.html

This link opens the official vendor documentation in a new tab.

Exam Strategy

When dealing with cross-account service integrations, always check if both sides need explicit permission grants: the target service (e.g., Lambda) must allow the source service (e.g., SNS), and the source service must allow the target to interact with it.

Frequently Asked Questions

Why can't I just use an SQS queue?

SQS adds buffering and decoupling, changing the architecture. The question asks for direct invocation via subscription, making direct permissions the simpler, correct path.

Do I need an IAM Role for Lambda?

No. For receiving events from SNS, Lambda uses a Resource Policy (allowing invocation), not an Execution Role (which defines what resources Lambda can access internally).

More SAA-C03 FAQ →

Community Votes

AC
59%
AB
41%

59% of anonymous learners picked answer AC. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 12 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 12

  1. mooondooo 👍 3
    Probably A and C https://repost.aws/knowledge-center/sns-with-crossaccount-lambda-subscription
  2. Anyio 👍 2
    The correct answers are A,B. Explanation: Option A: Correct. Creating an IAM resource policy for the Lambda function that allows Amazon SNS to invoke the function is necessary for SNS to have permission to trigger Lambda. This policy ensures that the Lambda function can be invoked by a service principal from the SNS service. Option B: Correct. Using an Amazon Simple Queue Service (Amazon SQS) queue as an intermediary buffer allows for decoupling the SNS topic from the Lambda function, providing more reliability and handling burst traffic effectively. In this setup, the SNS topic can publish to the SQS queue, and the queue can then trigger the Lambda function to process the messages.
  3. dhewa 👍 2
    No need to complicate stuff, AWS services already exist only permissions are missing. A&C will set up the necessary permissions and subscriptions for cross-account invocation of the Lambda function by the SNS topic.
  4. jamesukae 👍 2
    For me AB is contradict , why we invoke lambda function by both SNS and SQS? I think BE is correct answer because question also need solution to analyze data.
  5. EllenLiu 👍 2
    A: resource-policy for Lambda: should grant SNS to access lambda permission C: resource-policy for SNS: should specify who can subscribe SNS topic
Show 7 more comments
  1. JA2018 👍 1
    #A: This is the most direct way to allow the SNS topic in the production account to trigger the Lambda function in the administrator account. By creating an IAM policy on the Lambda function that grants SNS permission to invoke it, you establish the necessary access control. #D: Using an EventBridge rule in the production account allows you to filter and route the SNS notifications specifically to the Lambda function in the administrator account, providing greater control and flexibility over the event delivery .
  2. Anyio 👍 1
    The Correct answer is A,C. Using the Amazon SNS console, add a cross-account AWS Lambda subscription to an Amazon SNS topic. the Lambda function resource policy allows SNS to invoke the function. the SNS topic access policy allows Lambda to subscribe to the topic. Note: The SNS topic resides in account A and the Lambda function resides in account B.
  3. 523db89 👍 1
    A,C correct - While using SQS could be a solution for buffering messages, it introduces additional complexity
  4. progounick 👍 1
    A and C seem to be the best answer
  5. siheom 👍 5
    VOTE A,B
  6. nebajp 👍 4
    correct answer is AD
  7. agbor_tambe 👍 1
    most reasonable

Reader comments & corrections

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

Log in to comment, report an error, or add a note about this question.

Submitted for moderation before publishing. Keep it helpful and respectful.

Practice All SAA-C03 Questions

Access 120 questions with complete answers and detailed explanations.

View Full SAA-C03 Practice Test →

← Back to SAA-C03 Study Guide