Domain 1: Development with AWS Services

AWS Certified Developer – Associate (DVA-C02)

Domain 1: Development with AWS Services

Exam Code: DVA-C02  |  Level: Associate
Domain Weight: 32%  |  Total Domains: 4  |  Passing Score: 720/1000

---

Table of Contents

1. AWS Lambda
   • 1.1 Core Concepts
   • 1.2 Invocation Models
   • 1.3 Execution Environment & Lifecycle
   • 1.4 Concurrency & Throttling
   • 1.5 Lambda Layers & Destinations
2. Amazon API Gateway
   • 2.1 REST API vs HTTP API vs WebSocket API
   • 2.2 Integration Types
   • 2.3 Stages, Deployments & Canary
   • 2.4 Throttling, Caching & CORS
3. Amazon DynamoDB
   • 3.1 Data Model & Key Design
   • 3.2 Read/Write Capacity & On-Demand Mode
   • 3.3 Indexes — GSI & LSI
   • 3.4 DynamoDB Streams & TTL
   • 3.5 Transactions & Conditional Writes
   • 3.6 DynamoDB Accelerator (DAX)
4. Amazon S3
   • 4.1 Storage Classes
   • 4.2 Object Lifecycle, Versioning & Replication
   • 4.3 Pre-signed URLs & Access Patterns
   • 4.4 S3 Events & Notifications
5. Amazon SQS
   • 5.1 Standard vs FIFO Queues
   • 5.2 Visibility Timeout, DLQ & Polling
6. Amazon SNS
   • 6.1 Topics, Subscriptions & Fan-out Pattern
   • 6.2 Message Filtering & FIFO Topics
7. Amazon EventBridge
   • 7.1 Event Bus, Rules & Targets
   • 7.2 EventBridge vs SNS vs SQS
8. AWS Step Functions
   • 8.1 State Machine Types
   • 8.2 State Types & Error Handling
9. Amazon Kinesis
   • 9.1 Kinesis Data Streams
   • 9.2 Kinesis Firehose & Analytics
10. AWS SAM — Serverless Application Model
    • 10.1 SAM Template Anatomy
    • 10.2 SAM CLI Commands
11. AWS SDK — Patterns & Error Handling
    • 11.1 Exponential Backoff & Retry Logic
    • 11.2 Pagination Patterns
12. Exam Tips & Quick Reference

---

1. AWS Lambda

Lambda is the backbone of serverless development on AWS. It runs code in response to events without you provisioning or managing servers. You are billed per request and per GB-second of compute.

1.1 Core Concepts

┌─────────────────────────────────────────────────────────────────┐
│                     Lambda Execution Model                       │
│                                                                   │
│  Event Source ──► Lambda Service ──► Execution Environment       │
│                        │                    │                     │
│                   (trigger,             ┌───────────┐            │
│                   routing)              │  Init Phase│ ◄── Cold  │
│                                         │  (INIT)    │    Start  │
│                                         └─────┬──────┘           │
│                                               │                  │
│                                         ┌─────▼──────┐           │
│                                         │ Invoke Phase│          │
│                                         │ (handler)  │           │
│                                         └─────┬──────┘           │
│                                               │                  │
│                                         ┌─────▼──────┐           │
│                                         │  Shutdown  │           │
│                                         │  Phase     │           │
│                                         └────────────┘           │
└─────────────────────────────────────────────────────────────────┘

Critical Concept: Code placed outside the handler function runs during the Init Phase. This includes database connections, SDK clients, and configuration loading. Reusing these across invocations (within the same warm execution environment) significantly reduces latency and cost.

1.2 Invocation Models

Lambda has three fundamental invocation models. The exam frequently tests which model a given event source uses.

┌─────────────────────────────────────────────────────────────────────────┐
│               Lambda Invocation Model Decision Tree                      │
│                                                                           │
│  ┌───────────────────┐   ┌───────────────────┐   ┌───────────────────┐  │
│  │   SYNCHRONOUS     │   │   ASYNCHRONOUS    │   │  EVENT SOURCE     │  │
│  │   (Push)          │   │   (Fire & Forget) │   │  MAPPING (Poll)   │  │
│  ├───────────────────┤   ├───────────────────┤   ├───────────────────┤  │
│  │ • API Gateway     │   │ • S3              │   │ • SQS             │  │
│  │ • ALB             │   │ • SNS             │   │ • DynamoDB Stream │  │
│  │ • CloudFront      │   │ • EventBridge     │   │ • Kinesis         │  │
│  │ • Cognito         │   │ • SES             │   │ • Kafka (MSK)     │  │
│  │ • SDK (RequestResponse)│ • CloudWatch Logs│   │ • SQS FIFO        │  │
│  ├───────────────────┤   ├───────────────────┤   ├───────────────────┤  │
│  │ Caller WAITS for  │   │ Lambda retries    │   │ Lambda polls the  │  │
│  │ response. Errors  │   │ 2x on failure.    │   │ source. Managed   │  │
│  │ returned to caller│   │ DLQ supported     │   │ by Lambda service │  │
│  └───────────────────┘   └───────────────────┘   └───────────────────┘  │
└─────────────────────────────────────────────────────────────────────────┘

Exam Trap: For SQS → Lambda, the Lambda service internally polls SQS using long polling. The consumer is Lambda's event source mapping, not your code.

1.3 Execution Environment & Lifecycle

Cold Start occurs when Lambda provisions a new execution environment. The Init Phase includes downloading the code package, starting the runtime, and running initialization code (outside the handler). A warm start reuses an existing environment, skipping the Init Phase.

Strategies to Minimize Cold Starts:

• Use Provisioned Concurrency — pre-warms a set number of execution environments. Eliminates cold starts. Billed even when idle.
• Reduce deployment package size (fewer dependencies to load).
• Choose runtimes with faster startup: Node.js and Python start faster than Java.
• Keep initialization code lean.

Key Concept: /tmp storage persists within an execution environment across multiple invocations of the same warm instance. Do NOT store sensitive data in /tmp unless it is short-lived. Use it for caching large files or compiled artifacts between warm invocations.

1.4 Concurrency & Throttling

┌──────────────────────────────────────────────────────────────────────┐
│                     Lambda Concurrency Model                          │
│                                                                        │
│  Account Default: 1,000 concurrent executions (soft limit, regional)  │
│                                                                        │
│  ┌─────────────────────────────────────────────────────────────┐      │
│  │                    Account Concurrency Pool                  │      │
│  │                                                               │      │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────────┐   │      │
│  │  │ Reserved     │  │ Provisioned  │  │   Unreserved     │   │      │
│  │  │ Concurrency  │  │ Concurrency  │  │   Concurrency    │   │      │
│  │  │ (guaranteed) │  │ (pre-warmed) │  │ (shared pool)    │   │      │
│  │  └──────────────┘  └──────────────┘  └──────────────────┘   │      │
│  └─────────────────────────────────────────────────────────────┘      │
│                                                                        │
│  Throttle: 429 TooManyRequestsException                                │
│  Burst Limit: 3,000 (us-east-1, us-west-2), 1,000 (other regions)     │
└──────────────────────────────────────────────────────────────────────┘

Critical: Setting Reserved Concurrency to 0 effectively disables a Lambda function (no invocations allowed). Use this to throttle non-critical functions during incidents.

Concurrency Calculation:

Concurrent Executions = (Invocations per second) × (Average Duration in seconds)
Example: 100 req/s × 0.5s duration = 50 concurrent executions needed

1.5 Lambda Layers & Destinations

Lambda Layers package reusable code (shared libraries, custom runtimes, configuration) separately from function code. Up to 5 layers per function. Total unzipped size (function + layers) must not exceed 250 MB.

Lambda Destinations (for asynchronous invocations) send the result of a function execution to a target — regardless of success or failure. More powerful than DLQs because they capture both success and failure with full event context.

Exam Tip: DLQ only captures failures. Lambda Destinations capture both success and failure events with full event context. Prefer Destinations for modern serverless architectures.

---

2. Amazon API Gateway

API Gateway is a fully managed service that acts as the front door for your backend services. It handles authentication, throttling, caching, and monitoring at the edge.

2.1 REST API vs HTTP API vs WebSocket API

Exam Tip: If the question says "lower cost", "lower latency", or "simpler Lambda proxy" — choose HTTP API. If it requires request validation, usage plans, or API keys — choose REST API.

2.2 Integration Types

AWS Service Integration Example (SQS):

Client ──► API Gateway ──► SQS Queue (no Lambda!)
           (transforms      (direct integration)
            to SQS action)

Critical Concept: AWS Service Integration (e.g., API Gateway → DynamoDB directly) is a powerful cost and latency optimization. The exam may present a scenario asking you to eliminate Lambda and test whether you recognize direct integration as a valid option.

2.3 Stages, Deployments & Canary

A deployment is a snapshot of your API configuration. A stage is a named reference to a deployment (e.g., dev, staging, prod). Deployments must be made explicit — changes to the API are NOT live until deployed.

Stage Variables act like environment variables for stages. They allow a single API definition to route to different Lambda aliases or HTTP endpoints per stage.

# Stage Variable Example: Lambda Alias Routing
# In integration URI:
arn:aws:lambda:us-east-1:123456789:function:MyFunc:${stageVariables.lambdaAlias}

# dev stage → lambdaAlias = dev
# prod stage → lambdaAlias = prod

Canary Deployments on REST APIs allow you to route a percentage of traffic to a new API deployment while the rest goes to the current stable version. Configure the canary percentage in the stage settings. This maps directly to Lambda alias traffic shifting.

2.4 Throttling, Caching & CORS

Throttling:

When throttled: HTTP 429 Too Many Requests.

Caching:

• Enable at the stage level. Cache capacity: 0.5 GB – 237 GB.
• TTL: 0–3600 seconds. Default: 300 seconds.
• Cache is keyed on method and URL. Add query strings or headers as cache keys.
• Clients can invalidate cache by passing Cache-Control: max-age=0 (requires IAM permission).

CORS (Cross-Origin Resource Sharing):

• For Lambda Proxy integration: Lambda function must return the Access-Control-Allow-Origin header.
• For non-proxy integration: Enable CORS in the API Gateway console (adds an OPTIONS method).
• Browser sends a preflight OPTIONS request before the actual request. OPTIONS must return 200.

Common Trap: CORS errors appear in the browser. If you enable CORS on API Gateway but your Lambda still returns the response without the CORS header in proxy integration, the browser will still reject the response.

---

3. Amazon DynamoDB

DynamoDB is a fully managed, serverless, key-value and document NoSQL database designed for single-digit millisecond performance at any scale.

3.1 Data Model & Key Design

The Primary Key uniquely identifies every item in a table. Two forms exist:

┌─────────────────────────────────────────────────────────────────────┐
│                     DynamoDB Key Design                              │
│                                                                       │
│  Option 1: Simple Primary Key (Partition Key only)                   │
│  ┌─────────────────────────────────────────┐                         │
│  │  PK (Partition Key)  │  Attributes...   │                         │
│  │  UserID = "U-001"    │  name, email...  │                         │
│  └─────────────────────────────────────────┘                         │
│  → PK must be unique per item. Best for simple lookups.              │
│                                                                       │
│  Option 2: Composite Primary Key (Partition Key + Sort Key)          │
│  ┌──────────────┬───────────────────┬──────────────┐                 │
│  │  PK           │  SK               │ Attributes   │                 │
│  │  (Partition)  │  (Sort)           │              │                 │
│  │  OrderID-001  │  2024-01-15       │  amount...   │                 │
│  │  OrderID-001  │  2024-02-20       │  amount...   │                 │
│  │  OrderID-001  │  2024-03-10       │  amount...   │                 │
│  └──────────────┴───────────────────┴──────────────┘                 │
│  → PK + SK must be unique. Multiple items per PK sorted by SK.       │
└─────────────────────────────────────────────────────────────────────┘

Partition Key Design Best Practices:

• High cardinality — many distinct values prevent hot partitions.
• Avoid sequential IDs if they lead to monotonic writes to one shard.
• Use techniques like write sharding: append a random suffix (UserID#1, UserID#2) and fan-out reads.

Key Concept: DynamoDB distributes data across partitions based on the partition key hash. All items with the same partition key are stored on the same partition and sorted by the sort key. A "hot partition" (too many writes to one PK) will throttle your table even if overall capacity is adequate.

3.2 Read/Write Capacity & On-Demand Mode

Capacity Unit Definitions:

RCU Calculation Example:

Read: 10 items/second, each item is 10 KB, strongly consistent
→ Each item requires: CEIL(10 KB / 4 KB) = 3 RCU per item
→ Total: 10 items/s × 3 RCU = 30 RCU needed

WCU Calculation Example:

Write: 20 items/second, each item is 3.5 KB
→ Each item requires: CEIL(3.5 KB / 1 KB) = 4 WCU per item
→ Total: 20 items/s × 4 WCU = 80 WCU needed

3.3 Indexes — GSI & LSI

Critical Exam Trap: LSIs must be created with the table — you cannot add them later. GSIs can be added at any time. Strongly consistent reads are only possible on the base table and LSIs, NOT on GSIs.

Sparse Indexes (GSI Best Practice):
Create a GSI on an attribute that only some items have. Only those items appear in the index. This is efficient for queries like "all orders with status=PENDING" if most orders are COMPLETED and don't have the PENDING attribute.

3.4 DynamoDB Streams & TTL

DynamoDB Streams capture a time-ordered sequence of item-level modifications (INSERT, MODIFY, REMOVE) in a table. Retention: 24 hours.

DynamoDB Table ──► Streams ──► Lambda ──► ElasticSearch / DynamoDB (cross-region) / SNS
                   (24h TTL)   (polls up
                                to 2 concurrent
                                shards per shard)

Time to Live (TTL):

• Designate any Number attribute as the TTL attribute. Store value as Unix epoch timestamp.
• DynamoDB automatically deletes expired items within 48 hours (not guaranteed to the second).
• Deletes do NOT consume WCU.
• Deletions appear in Streams as REMOVE events (use this to trigger cleanup logic).

Exam Tip: TTL deletions are NOT guaranteed to be instant. Applications reading expired items before deletion must filter on the TTL attribute in their code.

3.5 Transactions & Conditional Writes

DynamoDB Transactions allow all-or-nothing (ACID) operations across multiple items and tables.

Transactions consume 2x the normal capacity units (RCU/WCU).

Conditional Writes:

# Only update if the item's version matches (Optimistic Locking)
table.update_item(
    Key={'PK': 'item-001'},
    UpdateExpression='SET price = :newprice, version = :newver',
    ConditionExpression='version = :currentver',
    ExpressionAttributeValues={
        ':newprice': 99,
        ':newver': 2,
        ':currentver': 1
    }
)
# Raises ConditionalCheckFailedException if version doesn't match

Common DynamoDB API Operations:

Critical: Scan reads every item in the table before applying filters. Always prefer Query (requires knowing the partition key). Use Parallel Scan only for full-table ETL operations with adequate capacity.

3.6 DynamoDB Accelerator (DAX)

DAX is an in-memory, DynamoDB-compatible caching layer that provides microsecond read latency for cached data (vs. single-digit milliseconds for DynamoDB directly).

Application ──► DAX Cluster (in-memory cache) ──► DynamoDB
                      │
                 Cache Hit → return immediately
                 Cache Miss → fetch from DynamoDB → cache → return

Exam Tip: DAX does NOT support strongly consistent reads. If the question requires the latest data from DynamoDB at all times, DAX is NOT the answer. Use DAX for caching eventually-consistent reads.

---

4. Amazon S3

S3 is the foundational object storage service. For the DVA-C02 exam, focus on access patterns, pre-signed URLs, events, and lifecycle management.

4.1 Storage Classes

4.2 Object Lifecycle, Versioning & Replication

Versioning:

• Enabled at the bucket level. Once enabled, cannot be disabled — only suspended.
• Each PUT/DELETE creates a new version. DELETE adds a delete marker (does not remove versions).
• To permanently delete, you must delete the specific version ID.
• Versioning is required for Replication and MFA Delete.

Lifecycle Rules:

• Transition actions: Move objects between storage classes after N days.
• Expiration actions: Delete objects or old versions after N days.
• Can filter rules by prefix or tags.

Replication:

Critical: Replication only applies to new objects after replication is enabled. Existing objects must be replicated manually via S3 Batch Replication. Delete markers are NOT replicated by default.

4.3 Pre-signed URLs & Access Patterns

Pre-signed URLs allow temporary access to a private S3 object without requiring AWS credentials. The requester inherits the permissions of the IAM entity that generated the URL.

# Generate a pre-signed URL for a GET (download)
url = s3_client.generate_presigned_url(
    'get_object',
    Params={'Bucket': 'my-bucket', 'Key': 'my-key'},
    ExpiresIn=3600  # 1 hour
)

# Generate a pre-signed URL for PUT (upload)
url = s3_client.generate_presigned_url(
    'put_object',
    Params={'Bucket': 'my-bucket', 'Key': 'upload-key'},
    ExpiresIn=900   # 15 minutes
)

S3 Multipart Upload:

• Recommended for objects > 100 MB. Required for objects > 5 GB.
• Upload parts independently and in parallel.
• Parts must be between 5 MB and 5 GB (last part can be any size).
• Use lifecycle rules to abort incomplete multipart uploads after N days.

S3 Transfer Acceleration:

• Routes uploads through CloudFront edge locations to the S3 bucket via AWS backbone.
• Enabled per bucket. Generates a separate endpoint (bucket.s3-accelerate.amazonaws.com).

4.4 S3 Events & Notifications

S3 can trigger events on object creation, removal, replication, and lifecycle transitions. Event destinations:

Key Concept: S3 event notifications vs. EventBridge: S3 notifications are simpler but limited in filtering. EventBridge for S3 supports filtering on object metadata, prefix, suffix, tags, and can route to 20+ AWS services. For complex routing, always prefer EventBridge.

---

5. Amazon SQS

SQS is a fully managed message queue service for decoupling microservices and distributed systems.

5.1 Standard vs FIFO Queues

FIFO Message Groups:
Use MessageGroupId to parallelize processing within a FIFO queue. Messages in the same group are processed in order. Messages in different groups can be processed in parallel.

5.2 Visibility Timeout, DLQ & Polling

Visibility Timeout:
When a consumer reads a message, it becomes invisible to other consumers for the visibility timeout duration. If the consumer fails to delete the message within the timeout, the message reappears in the queue for redelivery.

Default: 30 seconds
Min: 0 seconds
Max: 12 hours

Consumer picks message → message hidden for 30s → Consumer deletes it (success)
                                                 → Timeout expires (no delete) → message reappears

Best Practice: Set visibility timeout to at least 6× the average processing time of your Lambda function. If your Lambda timeout is 5 minutes, set visibility timeout to 30+ minutes.

Dead-Letter Queue (DLQ):
After a message fails processing N times (maxReceiveCount), it's moved to the DLQ. Configure maxReceiveCount on the source queue's redrive policy, not on the DLQ itself.

Polling Modes:

Key Setting: ReceiveMessageWaitTimeSeconds > 0 enables long polling. Set to maximum of 20 seconds.

Message Size: Max 256 KB. For larger payloads, use the S3 Extended Client Library — store payload in S3, send a pointer in the SQS message.

---

6. Amazon SNS

SNS is a fully managed pub/sub messaging service. Publishers send messages to a topic; subscribers receive messages from that topic.

6.1 Topics, Subscriptions & Fan-out Pattern

Supported Subscriber Protocols:
SQS, Lambda, HTTP/HTTPS, Email, Email-JSON, SMS, Mobile Push (APNS, GCM), Kinesis Data Firehose.

Fan-out Pattern:
One SNS topic publishes to multiple SQS queues simultaneously. This decouples the publisher from multiple independent consumers.

                              ┌──────────────────────┐
                              │  SQS Queue A          │──► Consumer A (Order Processing)
S3 Event ──► SNS Topic ───────┤                       │
                              ├──────────────────────┤
                              │  SQS Queue B          │──► Consumer B (Inventory Update)
                              ├──────────────────────┤
                              │  SQS Queue C          │──► Consumer C (Analytics)
                              └──────────────────────┘

Best Practice: SNS → SQS fan-out is preferred over SNS → Lambda fan-out because SQS provides buffering, retry, and rate control for downstream Lambdas.

6.2 Message Filtering & FIFO Topics

Message Filtering (Subscription Filter Policies):
Each SQS or Lambda subscriber can define a filter policy — a JSON document that specifies which messages it wants to receive based on message attributes.

// Filter policy: only receive messages with type = "order" AND priority = "high"
{
  "type": ["order"],
  "priority": ["high"]
}

Without a filter policy, a subscriber receives all messages from the topic.

SNS FIFO Topics:

• Strictly ordered delivery to SQS FIFO queues only.
• Deduplication: 5-minute window.
• Throughput: 300 msg/s (same as SQS FIFO).
• Cannot fan-out to Lambda, HTTP, or Email — only to SQS FIFO queues.

---

7. Amazon EventBridge

EventBridge is a serverless event bus that connects applications using events. It supersedes CloudWatch Events and adds significant power.

7.1 Event Bus, Rules & Targets

Three Types of Event Buses:

Event Pattern Matching:
Rules filter events using pattern matching on event fields (source, detail-type, detail, region, account). Supports exact match, prefix match, numeric range, and anything-but conditions.

// Example: Catch all EC2 instance state changes to "stopped"
{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
    "state": ["stopped"]
  }
}

Targets (up to 5 per rule): Lambda, SQS, SNS, Kinesis, Step Functions, API Gateway, CloudWatch Logs, CodePipeline, EC2 Run Command, and more.

EventBridge Pipes: Point-to-point integration between a source (SQS, DynamoDB Streams, Kinesis) and a target with optional enrichment (Lambda or Step Functions) in the middle.

7.2 EventBridge vs SNS vs SQS

---

8. AWS Step Functions

Step Functions orchestrates distributed applications and microservices as visual, auditable workflows called State Machines.

8.1 State Machine Types

Express Subtypes:

Exam Tip: Standard workflows guarantee exactly-once execution. Express workflows support at-least-once execution. For financial transactions — use Standard.

8.2 State Types & Error Handling

Error Handling in Step Functions:

{
  "Type": "Task",
  "Resource": "arn:aws:lambda:...",
  "Retry": [
    {
      "ErrorEquals": ["Lambda.ServiceException", "Lambda.TooManyRequestsException"],
      "IntervalSeconds": 2,
      "MaxAttempts": 3,
      "BackoffRate": 2
    }
  ],
  "Catch": [
    {
      "ErrorEquals": ["States.ALL"],
      "Next": "ErrorHandlerState",
      "ResultPath": "$.error"
    }
  ]
}

Wait for Callback (Task Token Pattern):
Step Functions pauses until an external system calls SendTaskSuccess or SendTaskFailure with the task token. Ideal for human approval workflows or long-running third-party API calls.

Step Functions sends task token → External system/human does work → Calls SendTaskSuccess → Workflow continues

---

9. Amazon Kinesis

Kinesis handles real-time streaming data at scale. The DVA-C02 exam focuses primarily on Kinesis Data Streams.

9.1 Kinesis Data Streams

┌──────────────────────────────────────────────────────────────────────┐
│                       Kinesis Data Streams                            │
│                                                                        │
│  Producers                Shards                  Consumers           │
│  ┌──────────┐     ┌──────────────────────┐     ┌──────────────────┐  │
│  │ App/IoT  │────►│ Shard 1              │────►│ Lambda           │  │
│  │ Logs     │────►│ Shard 2              │────►│ Kinesis Analytics│  │
│  │ Metrics  │────►│ Shard N              │────►│ Firehose         │  │
│  └──────────┘     └──────────────────────┘     └──────────────────┘  │
│                                                                        │
│  • 1 shard = 1 MB/s write, 2 MB/s read, up to 1,000 records/s       │
│  • Retention: 24h (default), up to 365 days                           │
│  • Shard: unit of capacity — add shards to scale (reshard)           │
└──────────────────────────────────────────────────────────────────────┘

Kinesis Consumer Types:

Critical: Enhanced Fan-out uses a dedicated throughput per consumer per shard. If 3 Lambda functions all read from the same shard, with standard consumers they share 2 MB/s. With Enhanced Fan-out, each gets their own 2 MB/s.

Kinesis vs SQS Decision:

9.2 Kinesis Firehose & Analytics

Kinesis Data Firehose:

• Fully managed delivery stream — no shards, no consumers to manage.
• Batches, compresses, transforms, and delivers data to: S3, Redshift, OpenSearch, Splunk, HTTP endpoints.
• Near-real-time: minimum 60 second buffer or 1 MB (whichever comes first).
• Can invoke Lambda for data transformation before delivery.

Kinesis Data Analytics:

• Run standard SQL or Apache Flink queries on streaming data in real time.
• Sources: Kinesis Data Streams, Kinesis Firehose.
• Outputs: Kinesis Data Streams, Kinesis Firehose, Lambda.

---

10. AWS SAM — Serverless Application Model

SAM is an open-source framework that extends CloudFormation with simplified syntax for serverless resources. It transforms SAM templates into CloudFormation templates during deployment.

10.1 SAM Template Anatomy

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31      # ← Mandatory: signals SAM transform
Description: My Serverless App

Globals:                                    # ← Apply settings to all functions
  Function:
    Runtime: python3.12
    Timeout: 30
    MemorySize: 256
    Environment:
      Variables:
        TABLE_NAME: !Ref MyTable

Resources:

  # SAM Resource Type: AWS::Serverless::Function
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: src/handler.lambda_handler
      CodeUri: src/
      Events:
        ApiEvent:
          Type: Api
          Properties:
            Path: /users
            Method: GET
        SQSEvent:
          Type: SQS
          Properties:
            Queue: !GetAtt MyQueue.Arn
            BatchSize: 10

  # SAM Resource Type: AWS::Serverless::Api
  MyApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: prod
      Auth:
        DefaultAuthorizer: MyCognitoAuthorizer
        Authorizers:
          MyCognitoAuthorizer:
            UserPoolArn: !GetAtt MyUserPool.Arn

  # SAM Resource Type: AWS::Serverless::SimpleTable (DynamoDB)
  MyTable:
    Type: AWS::Serverless::SimpleTable
    Properties:
      PrimaryKey:
        Name: userId
        Type: String

SAM Resource Types (Shorthand vs CloudFormation):

10.2 SAM CLI Commands

Key Concept: sam deploy --guided creates a samconfig.toml file that saves your deployment preferences. Subsequent sam deploy commands use this config without the --guided flag.

---

11. AWS SDK — Patterns & Error Handling

11.1 Exponential Backoff & Retry Logic

AWS SDK retries on transient errors (network issues, throttling) automatically. However, understanding the retry mechanism is critical for the exam.

Throttling Errors (Retryable):

• ProvisionedThroughputExceededException (DynamoDB)
• ThrottlingException
• RequestLimitExceeded
• HTTP 429, HTTP 503 (Service Unavailable)
• HTTP 500 (Internal Server Error) — retryable

Non-Retryable Errors (Client Errors):

• ValidationException
• AccessDeniedException
• ResourceNotFoundException
• HTTP 400 (Bad Request) — generally non-retryable

Exponential Backoff Formula:

Wait Time = min(cap, base × 2^attempt) + random jitter

Example:
Attempt 1: wait 1s + jitter
Attempt 2: wait 2s + jitter
Attempt 3: wait 4s + jitter
Attempt 4: wait 8s + jitter

"Full Jitter": randomize the wait to spread out request storms
Wait = random(0, min(cap, base × 2^attempt))

Exam Tip: If you see ProvisionedThroughputExceededException from DynamoDB, the solution is exponential backoff — not to immediately increase capacity. Throttling often indicates a burst that can be absorbed by retrying.

11.2 Pagination Patterns

Many AWS API calls return paginated results. Always implement pagination in production code.

# DynamoDB Scan with pagination (Python)
paginator = dynamodb.get_paginator('scan')
pages = paginator.paginate(TableName='MyTable')
for page in pages:
    for item in page['Items']:
        process(item)

# Manual pagination using ExclusiveStartKey
response = table.scan()
items = response['Items']
while 'LastEvaluatedKey' in response:
    response = table.scan(ExclusiveStartKey=response['LastEvaluatedKey'])
    items.extend(response['Items'])

Common Mistake: Calling Scan or Query without handling LastEvaluatedKey will only retrieve the first page (~1 MB) of results. Always check for and use LastEvaluatedKey to iterate all pages.

---

12. Exam Tips & Quick Reference

Scenario-to-Answer Mapping

---

Common Traps

• Lambda timeout vs SQS visibility timeout: Lambda timeout is the max execution time. SQS visibility timeout is how long the message stays hidden. If Lambda timeout > visibility timeout, a second consumer may receive and process the same message concurrently. Always set visibility timeout ≥ Lambda timeout × 6.
• GSI vs LSI: LSI must be created at table creation. GSI can be added anytime. GSI only supports eventual consistency. Don't confuse them.
• SQS DLQ vs Lambda DLQ vs Lambda Destinations: SQS DLQ is on the queue. Lambda async DLQ is on the Lambda function. Lambda Destinations replaces Lambda DLQ for async invocations and supports both success and failure routing.
• Kinesis standard vs enhanced fan-out: Standard consumers share 2 MB/s per shard. Enhanced fan-out gives each consumer their own 2 MB/s per shard but costs more.
• SAM Transform: Transform: AWS::Serverless-2016-10-31 is mandatory in SAM templates. Without it, CloudFormation does not recognize SAM resource types.
• EventBridge vs CloudWatch Events: EventBridge is the evolution of CloudWatch Events. Both use the same underlying API, but EventBridge adds custom buses, SaaS partners, schema registry, and pipes. For new development, always use EventBridge.

---

Key Terms — Domain 1

---

End of Domain 1. Continue to Domain 2: Security →