Complete Study Guide
All Four Domains

Developers interact with IAM primarily through roles and the STS credential chain. Understanding how services assume roles and how temporary credentials flow is fundamental to DVA-C02.

• 1. Code-level credentials (never use in production)
• 2. Environment variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN
• 3. AWS credentials file: ~/.aws/credentials
• 4. AWS config file: ~/.aws/config
• 5. ECS container credentials (task role via metadata endpoint)
• 6. EC2 Instance Profile / Lambda execution role (IMDS endpoint)

• Default = implicit Deny
• Explicit Deny always wins — overrides any Allow
• Action allowed only when: explicit Allow exists AND no Deny blocks it at any level (SCP → Permission Boundary → Identity Policy → Resource Policy)

AWS KMS is the foundation of encryption on AWS. Every developer must understand the three key types, envelope encryption, and how to call KMS APIs from code.

• KMS can only encrypt data up to 4 KB directly. For larger data, use envelope encryption:
• Step 1: Call GenerateDataKey → KMS returns a plaintext data key (DEK) AND an encrypted DEK
• Step 2: Encrypt your data locally with the plaintext DEK (AES-256)
• Step 3: Store the encrypted DEK alongside the encrypted data. Discard the plaintext DEK.
• Decryption: Call Decrypt with the encrypted DEK → get plaintext DEK → decrypt data locally

• Optional additional authenticated data (AAD) — key-value pairs sent with encrypt/decrypt calls
• If you encrypt with context {"purpose":"payments"}, you must provide the same context to decrypt
• Appears in CloudTrail logs — useful for auditing which application/service used a key

• Every KMS key has a key policy (resource-based policy). Unlike IAM, the key policy must explicitly allow the AWS account or it has no access — even root.
• Cross-account: Key policy must allow the external account → then IAM policy in that account must also allow kms:Decrypt

Choosing between Secrets Manager and Parameter Store is a common DVA-C02 scenario. Secrets Manager is purpose-built for secrets with rotation; Parameter Store is for configuration and simple secrets.

• Rotation uses a Lambda function (AWS provides templates for RDS, Redshift, DocumentDB)
• Rotation schedule: interval in days or cron expression
• On rotation: new secret version is created → application fetches latest automatically using the AWSCURRENT label
• Versions: AWSCURRENT (active), AWSPREVIOUS (just rotated), AWSPENDING (being created)

# Fetch secret once at Lambda cold start — cache for warm invocations
import boto3, json
client = boto3.client('secretsmanager')
secret = json.loads(client.get_secret_value(
    SecretId='prod/myapp/db'
)['SecretString'])
DB_PASSWORD = secret['password']  # cached globally

AWS SAM is a shorthand extension of CloudFormation for serverless apps. The exam tests SAM template syntax, local testing, and the build/deploy workflow.

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31   # Declares this is a SAM template
Globals:
  Function:
    Timeout: 30
    Runtime: python3.12
    Environment:
      Variables:
        TABLE_NAME: !Ref MyTable
Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.lambda_handler
      CodeUri: ./src/
      Events:
        ApiEvent:
          Type: Api
          Properties:
            Path: /hello
            Method: get

• sam init — scaffold a new SAM app from a template
• sam build — package code and dependencies into .aws-sam/build
• sam local invoke — run a Lambda function locally with a test event JSON
• sam local start-api — start a local API Gateway emulator
• sam deploy --guided — deploy to AWS; creates/updates CloudFormation stack
• sam logs — tail Lambda logs from CloudWatch

• Deploy same API to dev, test, and prod stages — each stage is an independent deployment
• Stage Variables: Use ${stageVariables.lambdaAlias} in Lambda integration ARN to route each stage to a different Lambda alias
• Canary deployments on stages: Route X% of traffic to a new deployment version while keeping the rest on stable — built into API GW stage settings

• Use SAM CLI event templates: sam local generate-event s3 put — generates sample S3 event JSON
• For SQS: sam local generate-event sqs receive-message
• Test Lambda → SQS → Lambda pipelines locally with sam local start-lambda + real SQS queue in dev account

• Publishing a version creates an immutable snapshot of the function code + config
• Versions are numbered: :1, :2, :3 …
• $LATEST is the mutable, unpublished version — always points to the latest code
• You cannot update a published version — it is read-only

• Named pointers to specific versions (e.g., live → v5, beta → v6)
• Weighted routing: An alias can split traffic between two versions — e.g., live = 90% v5 + 10% v6. Used for blue/green and canary testing.
• API Gateway stage variable or event source mapping references the alias — swap the version behind the alias without changing integrations

• Lambda supports container images up to 10 GB (vs 250 MB for ZIP)
• Images stored in Amazon ECR — tag with :latest, :v1.2.0, or commit SHA for traceability
• CI/CD pipeline: build → push to ECR with version tag → update Lambda to use new image URI → run tests → promote tag to :stable

The four Code* services form the AWS-native CI/CD toolchain. Know each service's role and how they integrate in a pipeline.

version: 0.2
phases:
  install:
    commands:
      - pip install -r requirements.txt
  build:
    commands:
      - python -m pytest tests/
      - sam build
  post_build:
    commands:
      - sam package --s3-bucket $ARTIFACT_BUCKET
artifacts:
  files:
    - packaged-template.yaml

version: 0.0
Resources:
  - MyLambdaFunction:
      Type: AWS::Lambda::Function
      Properties:
        Name: MyFunction
        Alias: live
        CurrentVersion: !Ref Version1
        TargetVersion: !Ref Version2
Hooks:
  - BeforeAllowTraffic: PreTrafficHookFunction
  - AfterAllowTraffic: PostTrafficHookFunction

CloudWatch Logs is the primary log aggregation service on AWS. Knowing how to query, filter, and act on logs is a key DVA-C02 skill.

• Log Group: Container for related log streams (e.g., one per Lambda function or ECS service). Retention configured here (1 day – 10 years, or never expire).
• Log Stream: Sequence of log events from a single source (e.g., one Lambda execution environment, one EC2 instance).
• Log Event: A single timestamped record.

# Find Lambda errors in the last hour
fields @timestamp, @message
| filter @message like /ERROR/
| sort @timestamp desc
| limit 20

# Calculate p99 Lambda duration
filter @type = "REPORT"
| stats pct(@duration, 99) as p99Duration by bin(5m)

# Count errors by error type
filter @message like /Exception/
| parse @message "* Exception: *" as exType, exMsg
| stats count(*) by exType

• Extract numeric values from log events and publish them as CloudWatch custom metrics
• Example: Count occurrences of ERROR in logs → create metric ErrorCount → set alarm on it
• Pattern: { $.level = "ERROR" } (JSON log format) or simple text pattern ERROR
• One metric filter = one CloudWatch metric per log group

• Lambda automatically sends stdout/stderr to CloudWatch Logs (/aws/lambda/functionName)
• Lambda Logs format: START, END, REPORT lines contain requestId, duration, billed duration, memory used, init duration (cold start)
• CloudWatch Lambda Insights: Enhanced monitoring — CPU, memory, disk, network utilization via a Lambda layer

Publishing custom metrics lets you monitor business-level KPIs alongside infrastructure metrics. EMF is the modern, cost-effective approach for Lambda functions.

# Emit custom metric: order processing time
cw = boto3.client('cloudwatch')
cw.put_metric_data(
    Namespace='MyApp/Orders',
    MetricData=[{
        'MetricName': 'ProcessingDuration',
        'Value': processing_ms,
        'Unit': 'Milliseconds',
        'Dimensions': [{
            'Name': 'Environment',
            'Value': 'prod'
        }]
    }]
)

• Embed metric values in structured log JSON — CloudWatch automatically extracts them as metrics
• Zero additional API calls — metrics are extracted from your existing logs
• No extra cost for the PutMetricData API call; you only pay for the log ingestion
• Use the aws-embedded-metrics library (Python/Node.js/Java)

# Python EMF — metrics extracted automatically from logs
from aws_embedded_metrics import metric_scope

@metric_scope
def lambda_handler(event, context, metrics):
    metrics.set_namespace("MyApp")
    metrics.put_dimensions({"Service": "OrderProcessor"})
    metrics.put_metric("OrderCount", 1, "Count")
    metrics.put_metric("ProcessingTime", elapsed_ms, "Milliseconds")

• OK: Metric is within the threshold
• ALARM: Metric has breached the threshold for the configured datapoints-to-alarm
• INSUFFICIENT_DATA: Not enough data points yet (common with new metrics or long evaluation periods)

Concurrency management is one of the most tested Lambda optimization topics. Understanding reserved vs. provisioned concurrency and throttling behavior is essential.

• Each in-flight request uses one concurrent execution
• Account default limit: 1,000 concurrent executions (soft limit — can be increased via Service Quotas)
• Burst limit: Initial burst capacity (500–3,000 depending on region); after burst, scales by 500 per minute
• When concurrency limit is hit → throttling → TooManyRequestsException (HTTP 429)

• Open-source tool (AWS Lambda Power Tuning) runs your function at multiple memory sizes
• Finds the optimal memory setting for cost, speed, or both
• More memory ≠ always slower; often reducing duration pays for memory increase
• Rule: Cost = duration × memory. Higher memory may run faster enough to be cheaper overall.