Lesson 28 of 30

Serverless IaC with SAM

Q: How would you define, test, and deploy a Lambda function that reads from an S3 bucket and is triggered by an API request — entirely as code, without manually clicking through the console?

A strong answer covers: Names SAM's AWS::Serverless::Function and explains it expands into the function, an IAM role, and trigger wiring; Mentions a scoped policy (e.g. a policy template) rather than a broad, hand-authored IAM policy for the S3 access; Describes testing locally with sam local before deploying, and what that does and doesn't validate; Understands that sam deploy is a real CloudFormation deployment underneath, not a separate mechanism.

A hand-written CloudFormation template for one Lambda function with a trigger and a role runs to dozens of lines. SAM's whole purpose is collapsing that into a handful — and letting you run it locally before it ever deploys.

10 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A SAM template declares one `AWS::Serverless::Function` resource with an `Api` event. What actually gets provisioned when it's deployed?

The Lambda function, an IAM execution role, and the API Gateway route wiring — SAM's transform expands one resource into all threeOnly the Lambda function itself — the IAM role and API Gateway route have to be declared as separate resources for it to workA running container in ECS that hosts the function code, since SAM deploys serverless workloads as containers

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Serverless IaC with SAM

What interviewers actually ask about this, and what a strong answer has to cover.

How would you define, test, and deploy a Lambda function that reads from an S3 bucket and is triggered by an API request — entirely as code, without manually clicking through the console?

A strong answer covers

Names SAM's AWS::Serverless::Function and explains it expands into the function, an IAM role, and trigger wiring
Mentions a scoped policy (e.g. a policy template) rather than a broad, hand-authored IAM policy for the S3 access
Describes testing locally with sam local before deploying, and what that does and doesn't validate
Understands that sam deploy is a real CloudFormation deployment underneath, not a separate mechanism

Likely follow-ups

sam local says the function works, but it fails once deployed. What kinds of issues would sam local not have caught?
When would you reach for CDK instead of SAM for a project like this?

Practice these with the AI interviewer →

The plain-language idea

SAM (Serverless Application Model) is a shorthand extension of CloudFormation, purpose-built for Lambda-centric stacks. It isn't a separate deployment system — a SAM template still deploys through CloudFormation; sam deploy runs a real CloudFormation stack deployment underneath, with all the stack and change-set concepts from this track's CloudFormation lesson still applying unchanged. What SAM adds is a small set of higher-level resource types that expand into the verbose CloudFormation a serverless app would otherwise need written by hand.

The core one is AWS::Serverless::Function: a single resource declaring a function's code, runtime, and its triggers. SAM's transform expands that one declaration into everything CloudFormation actually needs — the Lambda function resource itself, an IAM execution role (often auto-generated with scoped, named policy templates rather than hand-written policy JSON), and the wiring for whatever triggers it (an API Gateway route, an S3 event notification, an EventBridge rule) — resources that, written directly in CloudFormation, would each need their own separate, verbose block.

SAM also ships sam local: a CLI that runs functions in a Docker container emulating the real Lambda runtime, so a function can be invoked and tested (sam local invoke, or sam local start-api for a whole API) without a deploy round-trip.

Worth placing next to the CDK (Cloud Development Kit), a different IaC tool this platform covers separately: CDK lets you define infrastructure imperatively in a general-purpose language (TypeScript, Python, and others), which it then synthesizes into CloudFormation. SAM's YAML shorthand is narrower and serverless-specific by design; CDK is broader, covers any CloudFormation-supported resource, and trades SAM's simplicity for the full expressiveness of a real programming language.

See it in a real thing: one resource, several things provisioned

Resources:
  ResizeImageFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/
      Handler: resize.handler
      Runtime: nodejs20.x
      Policies:
        - S3ReadPolicy:
            BucketName: user-uploads
      Events:
        UploadTrigger:
          Type: Api
          Properties:
            Path: /resize
            Method: post

This one AWS::Serverless::Function block expands into a Lambda function, an IAM execution role scoped by the S3ReadPolicy policy template to read-only access on exactly user-uploads (not a hand-written IAM policy document), and an API Gateway route wiring POST /resize to invoke it — three separate CloudFormation resources a hand-written template would need declared and connected individually.

sam build
sam local start-api
# POST http://localhost:3000/resize now invokes the real handler,
# in a container emulating the Lambda runtime — before any deploy.

What people usually miss

Watch out

SAM doesn't replace CloudFormation — it's a transform layered on top of it. sam deploy is a real CloudFormation deployment as its underlying mechanism; the stack, change-set, and drift concepts from this track's CloudFormation lesson still apply exactly as they do for a hand-written template.
Policy templates generate a scoped policy from a name and a couple of parameters — but it's worth knowing what they actually grant. S3ReadPolicy on a bucket name expands into a real IAM policy behind the scenes; trusting the shorthand blindly without checking what it actually allows undercuts the least-privilege reasoning from this track's IAM lesson, even though the shorthand is convenient.
sam local emulates the Lambda runtime closely, but it isn't a full substitute for a real deployed test. IAM permission boundaries, VPC networking constraints, and real cold-start timing don't show up in a local container — it catches a real class of bugs, not every class.
SAM's shorthand is scoped to serverless resources specifically. A stack that's mostly EC2, RDS, or general infrastructure gets little benefit from SAM, since the resource types it abbreviates (functions, their triggers, their execution roles) are the serverless-specific ones — SAM isn't a general CloudFormation shorthand for everything.

Why this matters in interviews

"How would you define, test locally, and deploy a Lambda function along with its trigger and permissions, entirely as code?" tests fluency with IaC specifically for serverless — naming SAM's AWS::Serverless::Function shorthand and the sam local testing loop is a more concrete answer than vaguely gesturing at "CloudFormation" or "Infrastructure as Code" in the abstract.