How to prevent S3 event notifications from invoking the wrong Lambda function?

A developer uses Amazon S3 Event Notifications to invoke AWS Lambda functions. The Lambda functions process images after the images are uploaded to S3 buckets. The developer has set up a development S3 bucket, a production S3 bucket, a development Lambda function, and a production Lambda function in the same AWS account. The developer notices that uploads to the development S3 bucket wrongly invoke the production Lambda function. The developer must prevent development data from affecting the production Lambda function. What should the developer do to meet these requirements?

Update the execution role for the production Lambda function. Add a policy that allows the execution role to read from only the production S3 bucket.
Update the S3 bucket policy for the production S3 bucket to invoke the production Lambda function. Update the S3 bucket policy for the development S3 bucket to invoke the development Lambda function.
Separate the development environment and the production environment into their own AWS accounts. Update the execution role for each Lambda function. Add a policy that allows the execution role to read from only the S3 bucket that is in the same account.
Separate the development environment and the production environment into their own AWS accounts. Add a resource policy to the Lambda functions to allow only S3 bucket events in the same account to invoke the functions. Source Reference Answer

Community Votes

100%

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

Community Insight

The core test is understanding that account separation combined with Lambda resource policies (not just bucket policies or execution roles) is the most secure and correct way to prevent unintended cross-environment invocations.

This question tests best practices for isolating development and production environments using separate AWS accounts and resource-based policies on Lambda functions to prevent cross-environment S3 event invocations.

Many candidates choose B, believing that simply updating S3 bucket policies to point to the correct Lambda functions is sufficient. However, this does not enforce a hard boundary and does not follow AWS best practices for environment isolation.

Community Discussion (6 comments)

examuserss 👍 1 Selected: B

The best solution is B. The issue stems from incorrectly configured S3 bucket policies. Each bucket's policy should explicitly specify which Lambda function to invoke when an event occurs in that bucket. By updating the policies to correctly map each bucket to its corresponding Lambda function, you ensure that events from the development bucket only trigger the development function, preventing accidental invocation of the production function.

devmo 👍 2 Selected: D

D is the answer. @Moderator, please correct the answer from B to D.

Saudis 👍 2 Selected: D

DDDDDDDDDDDDDDDDD

Saudis 👍 1 Selected: D

D is the correct answer

ogogundare 👍 1

D is the correct answer

albert_kuo 👍 3 Selected: D

Account Separation: By separating development and production environments into different AWS accounts, you create a strong boundary between the two. This is a best practice for security and resource management. Resource Policy: Adding a resource policy to the Lambda functions that allows only S3 bucket events from the same account to invoke them ensures that cross-account invocations cannot occur accidentally.

Comments & Corrections

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

Expert Analysis

The scenario describes a misconfiguration where the development S3 bucket is invoking the production Lambda function. While Option B suggests fixing the S3 bucket policies to correctly map each bucket to its respective Lambda function, this approach is insufficient from a security and best-practice standpoint.

Option D is correct because it enforces a strong isolation boundary by separating development and production into different AWS accounts. Additionally, adding a resource-based policy to the Lambda functions ensures that only S3 events originating from the same account can invoke the function. This prevents any accidental or malicious cross-account invocation, even if bucket policies are misconfigured.

Option A is incorrect because the Lambda execution role governs what the function can do after it is invoked (e.g., reading from S3), not whether it can be invoked in the first place. The invocation trigger is controlled by the resource policy on the Lambda function or the S3 bucket policy.

Option B is incorrect because while updating bucket policies may fix the immediate symptom, it does not enforce environment isolation. It also does not prevent future misconfigurations from causing cross-environment invocations.

Option C is incorrect because, although it separates accounts, it focuses on the Lambda execution role rather than the invocation permission. The execution role does not control which S3 buckets can trigger the function; that is governed by the Lambda resource policy.

Community consensus strongly supports Option D, with many users emphasizing that account separation and resource policies are AWS best practices for environment isolation.

Official Reference

Exam Strategy

When a question involves environment isolation (dev vs. prod), always look for answers that include account separation and resource-based policies. Execution roles control what a function can do, not what can invoke it.

Related Analysis

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide