Domain 3 of the AWS Developer Associate exam — Deployment — is roughly a quarter of your score, and for serverless applications the tool the exam expects you to reach for is the AWS Serverless Application Model (SAM). SAM is where “I wrote a Lambda function” turns into “I packaged it, deployed it repeatably, and rolled it out safely.” Candidates who only ever clicked Deploy in the Lambda console tend to lose points here, because the exam asks about the mechanics: what a SAM template expands into, how sam build and sam deploy differ, and the simplest way to add gradual, automatically-rolled-back deployments to a function.
This guide is deliberately SAM-focused. It assumes you already know the serverless services themselves — Lambda, API Gateway, DynamoDB — from the DVA-C02 serverless guide, and it deliberately leaves the CI/CD orchestration tools (CodePipeline, CodeBuild, CodeDeploy) to the AWS CI/CD deployment guide. If you want the whole-exam map first, start with the AWS Developer Associate exam guide for 2026 and sequence your prep with the DVA-C02 study plan.
SAM Is CloudFormation With Serverless Shorthand
The one sentence to anchor everything else: a SAM template is a CloudFormation template with a transform macro and serverless shorthand. You write far less YAML; at deploy time the SAM transform expands it into full, ordinary CloudFormation.
Two things make a template a SAM template:
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31 # <-- this line turns it into a SAM templateThat Transform line invokes the SAM macro. When you deploy, CloudFormation runs the macro, which rewrites every AWS::Serverless::* resource into the underlying primitives — Lambda functions, IAM roles, API Gateway REST APIs, permissions, and so on. Because the end product is a normal CloudFormation stack, you inherit everything CloudFormation gives you: change sets (a preview of what will change before it happens), automatic rollback on failure, drift detection, and lifecycle management of the whole application as one unit.
That relationship is the most common single-fact exam question: what does SAM transpile to? The answer is CloudFormation. SAM is a developer-experience layer, not a separate provisioning engine. (The same is true of the CDK — both compile down to CloudFormation. For the DevOps-Professional-level treatment of raw CloudFormation, StackSets, and drift, see the cross-referenced DOP-C02 configuration management & IaC guide; for DVA-C02 you need the SAM layer, which is what follows.)
The Serverless Resource Types
SAM’s shorthand is a small set of AWS::Serverless::* resources. Knowing what each one expands into is the exam-relevant part:
| SAM resource | Expands into (roughly) |
|---|---|
AWS::Serverless::Function | Lambda function + execution IAM role + event source wiring |
AWS::Serverless::Api | API Gateway REST API + stage + deployment |
AWS::Serverless::HttpApi | API Gateway HTTP API (cheaper, lower-latency) |
AWS::Serverless::SimpleTable | A DynamoDB table with a primary key |
AWS::Serverless::StateMachine | A Step Functions state machine + role |
AWS::Serverless::LayerVersion | A Lambda layer |
The magic most candidates underestimate is event sources. Declare an Events block of type Api on a function and SAM generates the entire API Gateway for you — the REST API, the method, the integration, the stage, and the AWS::Lambda::Permission that lets API Gateway invoke the function:
Resources:
GetOrderFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: src/get-order/
Handler: app.handler
Runtime: python3.12
Events:
GetOrder:
Type: Api # SAM creates the whole API Gateway from this
Properties:
Path: /orders/{id}
Method: getThose ~12 lines expand to well over a hundred lines of CloudFormation. That compression is the entire point of SAM.
Globals and Policy Templates: Less YAML, Safer IAM
Two SAM features show up constantly on the exam because they solve real developer pain.
The Globals section applies shared configuration to every function so you don’t repeat yourself:
Globals:
Function:
Runtime: python3.12
Timeout: 15
MemorySize: 256
Tracing: Active # turns on AWS X-Ray for every function
Environment:
Variables:
TABLE_NAME: !Ref OrdersTablePolicy templates are SAM’s shorthand for least-privilege IAM. Instead of hand-writing an IAM policy document, you reference a named, scoped template and SAM generates a tightly-scoped policy for exactly that resource:
GetOrderFunction:
Type: AWS::Serverless::Function
Properties:
# ...
Policies:
- DynamoDBReadPolicy: # scoped read-only access to ONE table
TableName: !Ref OrdersTable
- SQSPollerPolicy:
QueueName: !GetAtt JobQueue.QueueNameDynamoDBCrudPolicy, DynamoDBReadPolicy, S3ReadPolicy, SQSPollerPolicy, and dozens more each expand into a minimal IAM policy bound to the named resource. This is the exam’s preferred answer to “how do you grant a Lambda function least-privilege access to a specific table?” — a policy template, not AdministratorAccess, and not a hand-rolled wildcard policy. Least-privilege IAM is a recurring DVA-C02 theme; it also connects to the security material in the AWS Developer Associate security guide.
The Local Iteration Loop: sam build and sam local
The SAM CLI is what makes serverless development feel local. Four commands cover the day-to-day loop, and the exam expects you to know what each does:
sam init # scaffold a new project from a template
sam validate # lint the template (add --lint for cfn-lint checks)
sam build # install dependencies & assemble artifacts in .aws-sam/build
sam local invoke GetOrderFunction -e events/event.json # run one function in Docker
sam local start-api # run the whole API Gateway + Lambda locally on :3000The distinction the exam probes: sam build compiles your code and dependencies into a deployable artifact under .aws-sam/build; it does not talk to AWS. sam local invoke and sam local start-api then run those artifacts inside a Docker container that emulates the Lambda runtime, so you can test a function — or the full API — on your laptop before deploying. sam local generate-event produces realistic sample events (an S3 PutObject event, an SQS message, an API Gateway request) to feed into invoke.
This local loop is why teams choose SAM for Lambda-centric projects: the edit-build-test cycle happens in seconds, locally, instead of a deploy-and-check-CloudWatch round trip.
Packaging and Deploying: sam deploy
Deployment is a two-part idea, and conflating the parts is a classic exam mistake.
- Package — your function code has to live somewhere CloudFormation can reach it.
sam deploy(like the oldersam package) uploads the built artifacts to an S3 bucket (or, for container-image functions, pushes to Amazon ECR) and rewrites eachCodeUrifrom a local path into the uploaded location. - Deploy — SAM then creates and executes a CloudFormation change set to provision or update the stack.
The guided first deploy walks you through it and saves your answers:
sam deploy --guided
# prompts for stack name, region, confirm-changeset, S3 bucket, IAM capabilities
# writes samconfig.toml so future deploys are just: sam deployTwo flags worth memorising:
--capabilities CAPABILITY_IAM(orCAPABILITY_NAMED_IAM) — you must acknowledge that the stack creates IAM resources, because SAM generates execution roles for your functions. Without it, the deploy fails.--confirm-changeset— pauses to show you the change set before it executes, so you see exactly what will be created, modified, or deleted.
For rapid inner-loop development against a real (dev) stack, sam sync --watch pushes code changes in near-real-time without a full CloudFormation deploy each time — handy locally, not something to use against production.
Safe Rollouts: AutoPublishAlias + DeploymentPreference
This is the highest-value SAM topic on the DVA-C02, and it comes up again and again as “the simplest way to add safe, gradual deployments to a serverless application.” The answer is two properties on the function:
GetOrderFunction:
Type: AWS::Serverless::Function
Properties:
# ...
AutoPublishAlias: live
DeploymentPreference:
Type: Canary10Percent5Minutes
Alarms:
- !Ref ErrorRateAlarm # roll back automatically if this fires
Hooks:
PreTraffic: !Ref PreValidationFn # validate before shifting traffic
PostTraffic: !Ref PostValidationFn # validate afterHere is what SAM wires up for you behind those two properties:
AutoPublishAlias: live— on every deploy, SAM publishes a new Lambda version and points thelivealias at it. Aliases are the stable ARN your clients call; versions are the immutable snapshots.DeploymentPreference— SAM configures AWS CodeDeploy to shift traffic from the old version to the new one gradually, using the alias.Canary10Percent5Minutessends 10% of traffic to the new version for five minutes, then the rest.Linear10PercentEvery1Minuteramps 10% at a time.AllAtOncecuts over immediately.Alarms— if a referenced CloudWatch alarm fires mid-shift (error rate, latency), CodeDeploy automatically rolls back to the previous version.Hooks—PreTrafficandPostTrafficLambda functions run validation before and after the shift and can abort the deployment.
The exam framing to lock in: weighted alias traffic shifting is done by CodeDeploy, and SAM’s DeploymentPreference is the declarative shorthand that configures it. You get canary/linear rollouts with automatic rollback from a handful of YAML lines — no pipeline required. The deeper traffic-shifting mechanics and CodeDeploy hooks are covered from the pipeline side in the CI/CD deployment guide.
SAM vs. Raw CloudFormation: When Each Wins
| Consideration | Raw CloudFormation | AWS SAM |
|---|---|---|
| Serverless boilerplate | Verbose — full resources by hand | Shorthand AWS::Serverless::* |
| Local testing | None built in | sam local invoke / start-api |
| IAM for functions | Hand-written policies | Policy templates |
| Safe Lambda rollouts | Wire up CodeDeploy manually | DeploymentPreference (one block) |
| Non-serverless resources | Full support | Supported (SAM is a superset) |
| Under the hood | — | Transpiles to CloudFormation |
You can mix them freely: any valid CloudFormation resource works inside a SAM template, so you can declare a AWS::Serverless::Function next to a plain AWS::SQS::Queue in the same file. SAM is a superset, which is why “SAM is CloudFormation with serverless shorthand” is both the mental model and the correct exam answer.
Practice Under Exam Conditions
SAM questions on the DVA-C02 reward hands-on familiarity: you should be able to look at a template and know what it expands into, know that sam build doesn’t touch AWS while sam deploy creates a change set, and instantly recognise AutoPublishAlias + DeploymentPreference as the canary-deployment answer. That recognition comes from writing and deploying a few SAM apps, not from reading about them.
The most efficient way to convert this into exam-ready recall is repetition under time pressure. Sailor.sh’s AWS Certified Developer Associate Mock Exam Bundle provides full-length, exam-style question banks across all four DVA-C02 domains — including deployment scenarios that test SAM templates, policy templates, and safe rollout strategies — so you walk in having already seen the patterns the exam favours.
To round out Domain 3, pair this with the CI/CD deployment guide for the pipeline tooling, and the DVA-C02 exam topics breakdown for the full domain weighting. The official AWS SAM developer guide and the SAM specification are the authoritative references for template syntax.
Frequently Asked Questions
What does an AWS SAM template transpile into?
CloudFormation. The Transform: AWS::Serverless-2016-10-31 line invokes a macro that expands every AWS::Serverless::* resource into standard CloudFormation resources at deploy time. The deployed result is an ordinary CloudFormation stack, which is why SAM inherits change sets, rollback, and drift detection.
What is the difference between sam build and sam deploy?
sam build compiles your function code and installs its dependencies into deployable artifacts under .aws-sam/build — it runs entirely locally and never contacts AWS. sam deploy then uploads those artifacts to S3 (or ECR for container images), rewrites the CodeUri values, and creates and executes a CloudFormation change set to provision or update the stack.
How do I test a Lambda function locally with SAM?
Run sam build, then sam local invoke <FunctionName> -e event.json to execute one function inside a Docker container that emulates the Lambda runtime, or sam local start-api to run the whole API Gateway plus Lambda locally on port 3000. Use sam local generate-event to produce realistic sample events for services like S3, SQS, and API Gateway.
What is the simplest way to add canary or gradual deployments to a Lambda function?
Add AutoPublishAlias and a DeploymentPreference (for example Type: Canary10Percent5Minutes) to the AWS::Serverless::Function. SAM publishes a new version and alias on each deploy and configures AWS CodeDeploy to shift traffic gradually, with optional CloudWatch alarms for automatic rollback and pre/post-traffic hooks for validation — no pipeline required.
What are SAM policy templates?
Policy templates are named, pre-scoped IAM shorthands (such as DynamoDBCrudPolicy, DynamoDBReadPolicy, S3ReadPolicy, and SQSPollerPolicy) that you reference under a function’s Policies. SAM expands each into a least-privilege IAM policy bound to the specific resource you name, so you grant scoped access without hand-writing IAM JSON.
Do I need the —capabilities flag when deploying SAM?
Yes, when the stack creates IAM resources — which SAM does, because it generates an execution role per function. Pass --capabilities CAPABILITY_IAM, or CAPABILITY_NAMED_IAM if any of those roles have custom names. sam deploy --guided prompts for this and saves the choice in samconfig.toml.
Is SAM only for serverless resources?
No. SAM is a superset of CloudFormation, so any standard CloudFormation resource (an SQS queue, an S3 bucket, a DynamoDB table declared the long way) can live in the same template alongside AWS::Serverless::* resources. SAM simply adds serverless shorthand on top of everything CloudFormation already supports.