How to Isolate SAM Deployments to Avoid Impacting Pre-Production?

A developer works for a company that only has a single pre-production AWS account with an AWS CloudFormation AWS Serverless Application Model (AWS SAM) stack. The developer made changes to an existing AWS Lambda function specified in the AWS SAM template and additional Amazon Simple Notification service (Amazon SNS) topics. The developer wants to do a one-time deploy of the changes to test if the changes are working. The developer does not want to impact the existing pre-production application that is currently being used by other team members as part of the release pipeline. Which solution will meet these requirements?

Use the AWS SAM CLI to package and deploy the SAM application to the pre-production AWS account. Specify the debug parameter.
Use the AWS SAM CLI to package and create a change set against the pre-production AWS account. Execute the change set in a new AWS account designated for a development environment.
Use the AWS SAM CLI to package and deploy the SAM application to a new AWS account designated for a development environment. Source Reference Answer
Update the CloudFormation stack in the pre-production account. Add a separate stage that points to a new AWS account designated for a development environment.

Community Votes

100%

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

Community Insight

The question tests understanding of environment isolation in AWS SAM; the trap is choosing a change set or stack update in the same account, which still risks impacting shared resources.

This question tests how to safely test AWS SAM template changes without impacting an existing pre-production stack. The community strongly agrees that deploying to a separate, dedicated development AWS account is the correct isolation strategy.

Candidates often choose Option B (creating a change set in a new account) because it sounds cautious, but change sets still operate against the original stack in the pre-production account, risking unintended impact.

Community Discussion (6 comments)

SerialiDr 👍 6 Selected: C

This option meets the requirements by deploying the changes to a completely separate AWS account, ensuring that the pre-production application is not impacted. This approach allows the developer to test the changes in isolation.

Saurabh04 👍 1 Selected: B

I recommend Option B—create a change set in a separate development environment. This way, you can test your changes without affecting other team members.

65703c1 👍 1 Selected: C

C is the correct answer.

KarBiswa 👍 2 Selected: C

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/using-sam-cli-deploy.html B option seems to be by default

CrescentShared 👍 2 Selected: C

C is correct.

tgv 👍 2

best practice here is to sam pack and sam deploy to a new AWS account dedicated to development so in this case the developer wouldn't impact whatsoever the existing pre-prod application. option C

Comments & Corrections

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

Expert Analysis

Understanding the Requirement

The developer needs to test changes to an AWS SAM template (Lambda function + SNS topics) without impacting the existing pre-production stack used by other team members. The company only has one pre-production account, so the key is to find a deployment method that provides complete isolation.

Why Option C is Correct

Option C — using the AWS SAM CLI to package and deploy the SAM application to a new AWS account designated for a development environment — is the correct answer. By deploying to an entirely separate AWS account, the developer guarantees:

Zero impact on the pre-production stack, its Lambda functions, SNS topics, or any other resources.
Complete isolation of the test environment, allowing free experimentation.
Compliance with the requirement of a one-time deploy for testing.

The sam package and sam deploy commands, when pointed at a different account (via AWS CLI profiles or credentials), create an independent CloudFormation stack in that account.

Why the Other Options Fail

Option A: Using the --debug parameter during deployment does not provide isolation. It only outputs verbose logging. The deployment still targets the pre-production stack and will impact other team members.
Option B: Creating a change set against the pre-production account still modifies the existing CloudFormation stack in that account. Even if you later "execute" it elsewhere, the change set itself is tied to the original stack. This risks impacting the shared pre-production environment.
Option D: Updating the CloudFormation stack in the pre-production account and adding a "separate stage" is not a valid SAM/CloudFormation concept for cross-account isolation. It still modifies the existing stack and does not meet the requirement.

Community Consensus

The community overwhelmingly supports Option C (92% vote share). Commenters emphasize that deploying to a dedicated development account is the AWS best practice for safe, isolated testing without affecting shared environments.

Official Reference

https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/using-sam-cli-deploy.html

Exam Strategy

When a question emphasizes 'not impacting' a shared environment, always look for the option that provides complete resource isolation (separate account, separate stack name with full isolation). Avoid options that modify the existing stack, even partially.

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