Serverless Application Model (SAM) in AWS - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Understanding AWS SAM Template Structure

Given the following AWS SAM template snippet, what resource type is being defined?

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: index.handler
      Runtime: nodejs14.x
      CodeUri: ./src
      Events:
        ApiEvent:
          Type: Api
          Properties:
            Path: /hello
            Method: get

A An Amazon DynamoDB table with a primary key

B An Amazon SNS topic for messaging

C An Amazon S3 bucket configured for static website hosting

D An AWS Lambda function triggered by an API Gateway HTTP GET request

💡 Hint

Look at the Type and Events sections to identify the resource.

The resource type AWS::Serverless::Function defines a Lambda function. The Events section shows it is triggered by an API Gateway event on the GET method at path /hello.

❓ service_behavior

intermediate

SAM Deployment Behavior with CodeUri

When deploying an AWS SAM application, what happens if the CodeUri property points to a local directory?

A SAM packages the local code directory into a deployment artifact and uploads it to an S3 bucket automatically

B SAM directly uploads the local directory contents to the Lambda function without packaging

C SAM requires the user to manually upload the code to S3 before deployment

D SAM ignores the <code>CodeUri</code> and deploys an empty Lambda function

💡 Hint

Think about how SAM handles local code during deployment.

SAM automatically packages the local code directory specified in CodeUri into a zip file and uploads it to an S3 bucket during deployment.

❓ security

advanced

IAM Role Configuration in SAM

In an AWS SAM template, if you want to restrict a Lambda function's permissions to only read items from a specific DynamoDB table, which of the following IAM policy snippets correctly achieves this?

Policies:
  - Version: '2012-10-17'
    Statement:
      - Effect: Allow
        Action: dynamodb:GetItem
        Resource: arn:aws:dynamodb:us-east-1:123456789012:table/MyTable

A The policy allows all DynamoDB actions on all tables in the account

B The policy allows GetItem on all DynamoDB tables in the region

C The policy allows only the GetItem action on the specified DynamoDB table resource

D The policy denies all DynamoDB actions on the specified table

💡 Hint

Check the Action and Resource fields carefully.

The policy explicitly allows only the dynamodb:GetItem action on the specified table ARN, restricting permissions as intended.

❓ Configuration

advanced

SAM Template Environment Variables Configuration

Which of the following SAM template snippets correctly sets environment variables for a Lambda function?

Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.lambda_handler
      Runtime: python3.9
      Environment:
        Variables:
          STAGE: prod
          LOG_LEVEL: debug

A Environment variables must be set outside the Properties section

B The environment variables STAGE and LOG_LEVEL are correctly set for the Lambda function

C The environment variables are incorrectly nested and will cause a deployment error

D SAM does not support environment variables in Lambda functions

💡 Hint

Review the correct placement of environment variables in SAM templates.

Environment variables are set under Properties.Environment.Variables in the SAM template, as shown, which is correct.

✅ Best Practice

expert

Optimizing SAM Template for Multiple Environments

You want to deploy the same SAM application to multiple environments (dev, test, prod) with different configuration values like memory size and environment variables. Which approach follows best practices?

A Use one SAM template with parameterized values and pass environment-specific parameters during deployment

B Use separate SAM templates for each environment with duplicated resources and values

C Hardcode all environment values in the SAM template and manually edit before each deployment

D Deploy the SAM application once and manually change configuration in the AWS Console for each environment

💡 Hint

Think about maintainability and automation when managing multiple environments.

Using parameters in a single SAM template allows you to reuse the template and pass different values per environment, which is a best practice for maintainability and automation.

Practice

1. What is the main purpose of AWS Serverless Application Model (SAM)?

easy

A. To simplify building and deploying serverless applications using a single template

B. To manage virtual machines in the cloud

C. To create relational databases automatically

D. To monitor network traffic in AWS

Solution

1. Step 1: Understand SAM's role

   SAM is designed to help developers define serverless functions and their triggers in one file.

2. Step 2: Compare options

   Options A, B, and C describe unrelated AWS services or functions, while D correctly describes SAM's purpose.

3. Final Answer:

   To simplify building and deploying serverless applications using a single template -> Option A

4. Quick Check:

   SAM purpose = Simplify serverless apps [OK]

Hint: SAM = single template for serverless apps [OK]

Common Mistakes:

• Confusing SAM with EC2 or database services
• Thinking SAM manages infrastructure like VMs
• Assuming SAM is for monitoring

2. Which of the following is the correct syntax to define a Lambda function in a SAM template?

easy

A. MyFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: python3.8

B. MyFunction:
Type: AWS::Lambda::Function
Properties:
Handler: index.handler
Runtime: python3.8

C. MyFunction:
Type: AWS::EC2::Instance
Properties:
Handler: index.handler
Runtime: python3.8

D. MyFunction:
Type: AWS::S3::Bucket
Properties:
Handler: index.handler
Runtime: python3.8

Solution

1. Step 1: Identify SAM Lambda function resource type

   SAM uses the resource type AWS::Serverless::Function to define Lambda functions.

2. Step 2: Check other options

   MyFunction: Type: AWS::Lambda::Function Properties: Handler: index.handler Runtime: python3.8 uses AWS::Lambda::Function which is CloudFormation but not SAM shorthand. Options C and D are unrelated resource types.

3. Final Answer:

   MyFunction with Type AWS::Serverless::Function and correct properties -> Option A

4. Quick Check:

   SAM Lambda function type = AWS::Serverless::Function [OK]

Hint: SAM Lambda uses AWS::Serverless::Function type [OK]

Common Mistakes:

• Using AWS::Lambda::Function instead of AWS::Serverless::Function
• Confusing resource types like EC2 or S3 for Lambda
• Missing required properties like Handler or Runtime

3. Given this SAM template snippet, what event triggers the Lambda function?

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Handler: app.lambda_handler
    Runtime: python3.8
    Events:
      ApiEvent:
        Type: Api
        Properties:
          Path: /hello
          Method: get

medium

A. A scheduled timer triggers the Lambda

B. An S3 file upload triggers the Lambda

C. A DynamoDB table update triggers the Lambda

D. An HTTP GET request to /hello triggers the Lambda

Solution

1. Step 1: Identify event type in template

   The event type is Api with Path /hello and Method get, meaning an HTTP GET request triggers the function.

2. Step 2: Eliminate other event types

   S3 upload, scheduled timer, and DynamoDB update are different event types not shown here.

3. Final Answer:

   An HTTP GET request to /hello triggers the Lambda -> Option D

4. Quick Check:

   Api event with GET /hello = HTTP trigger [OK]

Hint: Api event with Method get means HTTP GET trigger [OK]

Common Mistakes:

• Confusing Api event with S3 or timer events
• Ignoring the Method and Path properties
• Assuming default triggers without checking Events

4. You wrote this SAM template but deployment fails. What is the error?

MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Handler: app.lambda_handler
    Runtime: python3.8
    Events:
      S3Event:
        Type: S3
        Properties:
          Bucket: my-bucket
          Events: s3:ObjectCreated:Put

medium

A. The Runtime python3.8 is not supported

B. The Handler property is missing

C. The Events property under S3Event should be a list, not a string

D. The Bucket name cannot be hardcoded

Solution

1. Step 1: Check S3 event syntax

   The Events property for S3 event must be a list of event types, but here it is a string.

2. Step 2: Verify other properties

   Handler is present, python3.8 is supported, and bucket names can be hardcoded in SAM templates.

3. Final Answer:

   The Events property under S3Event should be a list, not a string -> Option C

4. Quick Check:

   S3 Events property = list, not string [OK]

Hint: S3 Events must be a list, not a single string [OK]

Common Mistakes:

• Using string instead of list for S3 Events
• Removing required Handler property
• Assuming runtime version is invalid without checking

5. You want to deploy a serverless app with two Lambda functions triggered by different events: one by HTTP GET /users and another by S3 file upload to bucket 'data-bucket'. Which SAM template snippet correctly defines both functions?

hard

A. UserFunction:
Type: AWS::Serverless::Function
Properties:
Handler: user.handler
Runtime: python3.8
Events:
S3Event:
Type: S3
Properties:
Bucket: data-bucket
Events:
- s3:ObjectCreated:Put

UploadFunction:
Type: AWS::Serverless::Function
Properties:
Handler: upload.handler
Runtime: python3.8
Events:
ApiEvent:
Type: Api
Properties:
Path: /users
Method: get

B. UserFunction:
Type: AWS::Serverless::Function
Properties:
Handler: user.handler
Runtime: python3.8
Events:
ApiEvent:
Type: Api
Properties:
Path: /users
Method: get

UploadFunction:
Type: AWS::Serverless::Function
Properties:
Handler: upload.handler
Runtime: python3.8
Events:
S3Event:
Type: S3
Properties:
Bucket: data-bucket
Events:
- s3:ObjectCreated:Put

C. UserFunction:
Type: AWS::Lambda::Function
Properties:
Handler: user.handler
Runtime: python3.8
Events:
ApiEvent:
Type: Api
Properties:
Path: /users
Method: get

UploadFunction:
Type: AWS::Lambda::Function
Properties:
Handler: upload.handler
Runtime: python3.8
Events:
S3Event:
Type: S3
Properties:
Bucket: data-bucket
Events:
- s3:ObjectCreated:Put

D. UserFunction:
Type: AWS::Serverless::Function
Properties:
Handler: user.handler
Runtime: python3.8
Events:
ApiEvent:
Type: Api
Properties:
Path: /users
Method: post

UploadFunction:
Type: AWS::Serverless::Function
Properties:
Handler: upload.handler
Runtime: python3.8
Events:
S3Event:
Type: S3
Properties:
Bucket: data-bucket
Events:
- s3:ObjectCreated:Put

Solution

1. Step 1: Verify UserFunction HTTP event

   UserFunction must have Api event with Path /users and Method get. UserFunction: Type: AWS::Serverless::Function Properties: Handler: user.handler Runtime: python3.8 Events: ApiEvent: Type: Api Properties: Path: /users Method: get UploadFunction: Type: AWS::Serverless::Function Properties: Handler: upload.handler Runtime: python3.8 Events: S3Event: Type: S3 Properties: Bucket: data-bucket Events: - s3:ObjectCreated:Put matches this exactly.

2. Step 2: Verify UploadFunction S3 event

   UploadFunction must have S3 event with Bucket data-bucket and Events as a list including s3:ObjectCreated:Put. UserFunction: Type: AWS::Serverless::Function Properties: Handler: user.handler Runtime: python3.8 Events: ApiEvent: Type: Api Properties: Path: /users Method: get UploadFunction: Type: AWS::Serverless::Function Properties: Handler: upload.handler Runtime: python3.8 Events: S3Event: Type: S3 Properties: Bucket: data-bucket Events: - s3:ObjectCreated:Put correctly defines this.

3. Step 3: Check other options

   UserFunction: Type: AWS::Serverless::Function Properties: Handler: user.handler Runtime: python3.8 Events: S3Event: Type: S3 Properties: Bucket: data-bucket Events: - s3:ObjectCreated:Put UploadFunction: Type: AWS::Serverless::Function Properties: Handler: upload.handler Runtime: python3.8 Events: ApiEvent: Type: Api Properties: Path: /users Method: get swaps triggers between functions. UserFunction: Type: AWS::Lambda::Function Properties: Handler: user.handler Runtime: python3.8 Events: ApiEvent: Type: Api Properties: Path: /users Method: get UploadFunction: Type: AWS::Lambda::Function Properties: Handler: upload.handler Runtime: python3.8 Events: S3Event: Type: S3 Properties: Bucket: data-bucket Events: - s3:ObjectCreated:Put uses AWS::Lambda::Function instead of AWS::Serverless::Function. UserFunction: Type: AWS::Serverless::Function Properties: Handler: user.handler Runtime: python3.8 Events: ApiEvent: Type: Api Properties: Path: /users Method: post UploadFunction: Type: AWS::Serverless::Function Properties: Handler: upload.handler Runtime: python3.8 Events: S3Event: Type: S3 Properties: Bucket: data-bucket Events: - s3:ObjectCreated:Put uses Method post instead of get for UserFunction.

4. Final Answer:

   Correctly defines both functions with proper triggers -> Option B

5. Quick Check:

   Correct event types and methods = UserFunction: Type: AWS::Serverless::Function Properties: Handler: user.handler Runtime: python3.8 Events: ApiEvent: Type: Api Properties: Path: /users Method: get UploadFunction: Type: AWS::Serverless::Function Properties: Handler: upload.handler Runtime: python3.8 Events: S3Event: Type: S3 Properties: Bucket: data-bucket Events: - s3:ObjectCreated:Put [OK]

Hint: Match event types and methods exactly for each function [OK]

Common Mistakes:

• Swapping event triggers between functions
• Using AWS::Lambda::Function instead of AWS::Serverless::Function
• Wrong HTTP method for API event