Preventing Cross-Environment Lambda Invocations via Resource Policies

Implement authentication and/or authorization for applications and AWS services.

Answer Correct answer: C — Add a resource policy to the production Lambda function to allow only the production environment S3 bucket to invoke the function.

A company uses AWS Lambda functions and an Amazon S3 trigger to process images into an S3 bucket. A development team set up multiple environments in a single AWS account. After a recent production deployment, the development team observed that the development S3 buckets invoked the production environment Lambda functions. These invocations caused unwanted execution of development S3 files by using production Lambda functions. The development team must prevent these invocations. The team must follow security best practices. Which solution will meet these requirements?

Update the Lambda execution role for the production Lambda function to add a policy that allows the execution role to read from only the production environment S3 bucket.
Move the development and production environments into separate AWS accounts. Add a resource policy to each Lambda function to allow only S3 buckets that are within the same account to invoke the function.
Add a resource policy to the production Lambda function to allow only the production environment S3 bucket to invoke the function. Correct Answer
Move the development and production environments into separate AWS accounts. Update the Lambda execution role for each function to add a policy that allows the execution role to read from the S3 bucket that is within the same account.

Community Votes

66%

34%

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

Community Insight

The exam tests your ability to apply least-privilege access controls using Lambda resource policies, often trapping candidates who over-engineer solutions with multi-account setups when a simpler policy fix suffices.

This question addresses how to prevent unintended cross-environment Lambda invocations caused by shared S3 triggers within a single AWS account. It establishes that applying resource-based policies is the direct and secure method to scope access.

Many candidates choose Option B because they prioritize 'best practices' for isolation (multi-account) over the specific technical requirement to stop the immediate trigger conflict, leading to unnecessary architectural changes.

Community Discussion (40 comments)

rodrigo35 👍 1 Selected: C

La respuesta correcta es C. Agregue una directiva de recursos a la función Lambda de producción para permitir que solo el depósito del entorno de producción S3 invoque la función. ¿Por qué? Cuando Amazon S3 invoca una función Lambda, la autorización se controla mediante una resource-based policy en la función Lambda, no mediante el rol de ejecución de Lambda. B. Incorrecta. Separar cuentas es una buena práctica de aislamiento, pero no es suficiente por sí sola. Además, la opción habla de permitir que cualquier bucket de la misma cuenta invoque la función, cuando el requisito es permitir únicamente el bucket de producción.

wmv__ 👍 1 Selected: C

Amazon S3 can invoke a Lambda function only if the Lambda function's resource-based policy allows it. In this case, development S3 buckets are incorrectly configured to invoke the production Lambda function. This implies that the resource policy on the production Lambda function is too permissive. To fix this, you should restrict the Lambda function’s resource policy so that only the production S3 bucket has permission to invoke it.

mooncake1 👍 1 Selected: C

Separating account can be more secure and easy but maintenance will be more hard. It is developer's role and ability to distinguish and maintain between two environments, not just splitting them because it's easy. What AWS wants as a DVA Certificate Member is not a person who splits the accounts because its easy , but is able to use IAM properly.

rkotit 👍 1 Selected: C

When securing AWS Lambda functions, you must ensure that only authorized resources (like an S3 bucket) can trigger or invoke the function. In this scenario, the simplest and most effective solution is to use resource-based policies on the Lambda function to restrict access.

sumanshu 👍 1 Selected: C

A) Eliminated - This approach focuses on the Lambda function's ability to read from S3, not on which S3 buckets can invoke it. B) Eliminated - Moving environments to separate AWS accounts might improve isolation but is not necessary to solve the stated problem C) Correct - The resource policy in Option C restricts Lambda function invocations to only the intended production S3 bucket. This is a direct implementation of AWS's least privilege security model

sumanshu 👍 1

B) can be correct While this does restrict invocation to the production S3 bucket, keeping both environments in the same account is not a best security practice. A single-account setup increases the risk of misconfigurations, accidental access, and security breaches.

Dimix3 👍 1 Selected: C

Option C focuses on securing the production Lambda function by adding a resource policy to restrict invocations. This policy would specify that only the production S3 bucket can trigger the production Lambda function. This prevents accidental invocations from development S3 buckets.

nbxyzd 👍 2 Selected: B

Pls pay attention to keywords when you do aws quizzes. The best security practice: option B The lowest operational cost: option C. So B is definitely the answer.

AmitRanchi 👍 1 Selected: C

Because- B. Move the development and production environments into separate AWS accounts: While moving to separate accounts is a good practice for environment isolation, it's a more complex and potentially costly solution. Also, it isn't strictly necessary to achieve the goal of preventing unauthorized invocations, which can be accomplished via resource policies. It adds overhead without directly addressing the root cause.

Saudis 👍 1 Selected: B

Best practices is the key Word

Saurabh04 👍 1

Option D is correct. This approach ensures isolation while maintaining manageability

queekao 👍 1 Selected: C

Option C is the simplest way to achieve this requirement.

nbxyzd 👍 1

Read carefully. The questions asks for 'the best' not the 'the simplest' security practice.

Anandesh 👍 1 Selected: B

Establish common guardrails and isolation between environments (such as production, development, and test) and workloads through a multi-account strategy. Account-level separation is strongly recommended, as it provides a strong isolation boundary for security, billing, and access

Aws_aspr 👍 1

Asked 18 July 24 WIthout security best practices word. So C is correct answer for this.

65703c1 👍 1 Selected: B

B is the correct amswer.

SerialiDr 👍 1 Selected: C

This approach involves configuring a resource-based policy (also known as a Lambda function policy) that explicitly defines which resources (in this case, S3 buckets) can invoke the Lambda function. By specifying only the production S3 bucket in the resource policy of the production Lambda function, you ensure that only events from the designated production S3 bucket can trigger the production Lambda function. This prevents development or other non-production buckets from inadvertently invoking production Lambda functions, thus maintaining environment integrity and security best practices.

KarBiswa 👍 2 Selected: D

I feel it is D as there is no doubt we need to separately create two accounts for DEV & PROD. After that there must lambda execution roles where we can the specific policies. Resource based policies more of a Cross Account access. https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html https://repost.aws/knowledge-center/lambda-execution-role-s3-bucket As the question demands the best practices scenario so option D fulfils that.

SD_CS 👍 4 Selected: B

I initially thought C, but after going through the below, I dont think there is any scope for doubt. stablish common guardrails and isolation between environments (such as production, development, and test) and workloads through a multi-account strategy. Account-level separation is strongly recommended, as it provides a strong isolation boundary for security, billing, and access https://docs.aws.amazon.com/en_us/wellarchitected/latest/framework/sec_securely_operate_multi_accounts.html

rrshah83 👍 1 Selected: C

new accounts not necessary...

Certified101 👍 2 Selected: B

B - following best practices

Mimi666 👍 1 Selected: B

Keeping the security best-practices.

tqiu654 👍 1 Selected: B

ChatGPT: B

Rameez1 👍 4 Selected: B

Moving the Dev and Prod environments to separate Accounts will make them totally isolated with cross account Lambda invocations. Whereas in Option C though Prod Lambda won't trigger with Dev S3 bucket Event, Dev Lambda may still get mistakenly invoked by Prod S3 Bucket event and perform unwanted actions.

Nagasoracle 👍 1 Selected: B

Sorry it is B As it mentions to follow security practice

Chicote 👍 1

COMO CHINGAS

Nagasoracle 👍 1 Selected: A

Answer : A As it mentions to follow best security practice

Millie024 👍 1

B seems to be the correct one https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_multi_accounts.html Establish common guardrails and isolation between environments (such as production, development, and test) and workloads through a multi-account strategy. Account-level separation is strongly recommended, as it provides a strong isolation boundary for security, billing, and access.

fossil123 👍 1 Selected: C

C meets the contextual security requirements.

stilloneway 👍 1 Selected: B

See the question, in terms of "Security best practices", Answer is B. It could be C for 2nd option if separate AWS account is not possible.

love777 👍 2

C. Add a resource policy to the production Lambda function to allow only the production environment S3 bucket to invoke the function. Explanation: In this scenario, the goal is to prevent unwanted invocations of production Lambda functions by development S3 buckets. Adding a resource policy directly to the production Lambda function that restricts invocations to only the production S3 bucket ensures that the function is only invoked by the intended bucket. ChatGPT

rodrigo35 👍 1

La frase: "El equipo debe seguir las mejores prácticas de seguridad" es la que lleva a muchos a escoger B. Pero si AWS hubiera querido que la respuesta fuera B, normalmente la opción también habría restringido la invocación al bucket específico de producción. En cambio, B deja una superficie de acceso más amplia ("cualquier bucket de la misma cuenta"), lo cual contradice el principio de mínimo privilegio.

maurice2005 👍 1

There is nowhere mentioned in the question that workload is the problem!

csG13 👍 23 Selected: B

I choose B because it says that the team should follow the best security practices. AWS well-architected framework suggests separation. For reference see the link below: https://wa.aws.amazon.com/wat.question.SEC_1.en.html

AgboolaKun 👍 31 Selected: C

B is a wrong answer because I do not understand the need to move the environments to separate AWS accounts. The resource policy in the production environment can be used to control which S3 bucket invokes the function. In my understanding, the answer choice C fulfills the security best practices requirement in the question.

wh1t4k3r 👍 3

"The team must follow security best practices" Security best practices state that prod should be separated from non prod environments.

jipark 👍 3

resource policy totally fulfill requirement

MrPie 👍 15

It's a best practice: Best Practices: Separate workloads using accounts: Establish common guardrails and isolation between environments (such as production, development, and test) and workloads through a multi-account strategy. Account-level separation is strongly recommended, as it provides a strong isolation boundary for security, billing, and access. https://wa.aws.amazon.com/wat.question.SEC_1.en.html

loctong 👍 1 Selected: B

chatgpt said

junrun3 👍 1 Selected: B

Answer is B

Comments & Corrections

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

Expert Analysis

Why the Answer Is Correct

Option C is the correct solution because it directly addresses the root cause: the production Lambda function lacks restrictions on which S3 buckets can invoke it. By attaching a resource-based policy to the production Lambda function that explicitly allows invocation only from the production S3 bucket's ARN, you enforce strict access control without changing the account structure. This aligns with AWS security best practices for scoping permissions.

Why the Other Options Are Wrong

Option A modifies the execution role, which controls what the Lambda function does after invocation, not who can trigger it. Options B and D suggest moving environments into separate accounts. While multi-account strategies are a valid long-term best practice for isolation, the question asks for a solution to prevent these specific invocations following best practices in the current context. Adding a resource policy is the standard, immediate remediation for this specific permission gap. Furthermore, Option D adds unnecessary complexity regarding execution roles for reading data, which doesn't solve the invocation trigger issue.

Community Comment Notes

Community consensus is split, with many users favoring Option B due to the phrase "security best practices," interpreting it as a mandate for account separation. However, as noted by user AgboolaKun, "the resource policy in the production environment can be used to control which S3 bucket invokes the function," making C the technically precise answer for the stated problem. User SD_CS also highlights that while separation is good, the resource policy "fulfill[s] requirement" directly. The key is recognizing that the question describes a permission misconfiguration solvable by IAM/Resource policies rather than an infrastructure design flaw requiring account migration.

Official Reference

https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html

Exam Strategy

When a question specifies a technical failure (like unwanted invocations) and asks for a solution adhering to best practices, look for the most direct permission control mechanism first (e.g., Resource Policies). Do not jump to complex architectural changes like multi-account setups unless the question explicitly demands complete tenant isolation or mentions billing/account-level boundaries.

Frequently Asked Questions

Why isn't separating accounts required?

Account separation is a broad best practice, but a resource policy provides immediate, granular control over who can invoke the function, solving the specific leak described.

Does modifying the execution role help?

No, the execution role defines permissions for actions inside the function (e.g., writing to S3), not permissions for external services triggering the function.

More DVA-C02 FAQ →

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