Amazon SOA-C02: Serverless and Application Integration — Study Guide

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Part of the AWS SysOps Administrator Associate SOA-C02 — Study Guide. Practice with verified answers in the Amazon exam hub, or take timed practice tests on ExamRoll.io.

Serverless and application integration covers running event-driven applications without managing servers and connecting services reliably. Operational importance lies in managing scale, latency, failure modes and least-privilege access while keeping costs predictable. This domain focuses on Lambda behavior (cold starts, concurrency), reliable event delivery (EventBridge, SNS, SQS), security controls (execution roles and permissions), and observability for asynchronous flows.

AWS Lambda operational aspects and concurrency

Lambda performance and availability hinge on cold starts, concurrency limits, and throttling controls. Cold starts occur when Lambda must initialize a new execution environment; reduce impact by using provisioned concurrency (aws lambda put-provisioned-concurrency-config –function-name MyFn –qualifier 1 –provisioned-concurrent-executions 10) for latency-critical paths, and prefer lighter runtimes or smaller initialization work. Reserve and limit concurrency with reserved concurrency (aws lambda put-function-concurrency –function-name MyFn –reserved-concurrent-executions 50) to protect downstream services and enforce per-function quotas; monitor ConcurrentExecutions and Throttles CloudWatch metrics.

Retry and invocation models differ by mode: synchronous invites (API Gateway, direct Invoke) return errors immediately; asynchronous invokes (EventBridge, SNS, S3 async notifications) use Lambda’s async retry policy (two retries with backoff) and can use DLQs or destinations. For event source mappings (SQS, Kinesis, DynamoDB streams), Lambda’s poller retries until the message expires or the event source’s redrive policy triggers a dead-letter. Configure timeout and memory conservatively (aws lambda update-function-configuration –function-name MyFn –timeout 30 –memory-size 1024) and set SQS visibility timeout > function timeout (recommend visibility >= function timeout * 2) to reduce duplicate processing.

Event-driven architectures with EventBridge

EventBridge provides a managed event bus with flexible routing, schema registry, cross-account delivery, and retry/DLQ settings. Use custom event buses for domain separation and partner event buses for SaaS integrations; create rules with patterns (aws events put-rule –name orderEvents –event-pattern file://order-pattern.json –event-bus-name customBus) and attach targets with dead-letter and retry configuration (targets JSON supports DeadLetterConfig and RetryPolicy). Use the schema registry to discover and enforce event shapes; register schemas when producers are well-defined, and use Code Bindings to generate typed models where helpful.

Choose EventBridge when you need:

• Complex routing and filtering with rich event patterns or cross-account/event-bus isolation
• Native support for multiple targets (Lambda, Step Functions, Kinesis, SQS, SNS)
• Schema discovery and governance across teams

Choose direct SNS/SQS when you need simpler fan-out or guaranteed queue semantics:

• SNS for fan-out to many subscribers and push semantics
• SQS for durable, pull-based processing with visibility timeout and redrive policies

Messaging with SNS and SQS (DLQs, visibility timeout)

SNS is a pub/sub push service; SQS is a durable queue with pull semantics. For high-reliability processing prefer SNS -> SQS -> Lambda patterns to decouple ingestion from processing and gain control over retries and visibility. Configure SQS redrive policy (aws sqs set-queue-attributes –queue-url URL –attributes file://redrive.json) to move messages to a DLQ after maxReceiveCount, and ensure visibility timeout is long enough to avoid premature re-delivery (visibility >= function timeout * 2 recommended). For FIFO needs, use SQS FIFO or SNS FIFO with message group IDs to preserve order and deduplication IDs to avoid duplicates.

Dead-letter handling options and where to use them:

• Lambda async invocations: configure DeadLetterConfig or Destinations (AsyncEventInvokeConfig) to send failures to SQS/SNS or invoke another Lambda.
• SQS: configure redrive policy to SQS DLQ for poison messages and set appropriate maxReceiveCount.
• EventBridge: set DeadLetterConfig and RetryPolicy on rule targets to capture undeliverable events.

Idempotency is essential: implement idempotent handlers using DynamoDB conditional writes (PutItem with ConditionExpression attribute_not_exists(pk)), idempotency tokens stored with TTL, or SQS FIFO deduplication for exactly-once semantics.

Function permissions, roles, and least privilege

Apply least privilege to Lambda execution roles and function resource policies. Start with AWSLambdaBasicExecutionRole for CloudWatch Logs, then grant explicit resource ARNs for services (e.g., dynamodb:PutItem on arn:aws:dynamodb:region:acct:table/MyTable). Avoid wildcards like Resource: “*” when specific ARNs are possible. Use managed or custom policies scoped by action and resource, and include conditions (aws:SourceAccount, aws:SourceArn) when adding invoke permissions for services:

• Add invocation permission for EventBridge: aws lambda add-permission –function-name MyFn –principal events.amazonaws.com –statement-id ev1 –action lambda:InvokeFunction –source-arn arn:aws:events:region:acct:rule/MyRule
• For SNS: use source-arn condition to limit which topic can invoke the function

Decision criteria:

• Use function resource-based policies to allow service invocations (EventBridge, SNS, CloudWatch Events)
• Use IAM execution role for runtime permissions (DynamoDB, S3, Secrets Manager)
• Prefer resource-level permissions and conditional constraints to reduce blast radius

Observability and troubleshooting for serverless

Observability must cover metrics, logs, traces, and async delivery status. Key CloudWatch metrics: Invocations, Duration, Errors, Throttles, ConcurrentExecutions, IteratorAge (for stream and SQS triggers). For async failure visibility monitor “AsyncEventInvoke” metrics and set up CloudWatch Alarms on DeadLetterErrors and Throttles. Enable X-Ray tracing (aws lambda update-function-configuration –function-name MyFn –tracing-config Mode=Active) to get end-to-end traces across services and visualize cold-starts, downstream latencies and exceptions.

Use structured JSON logs and CloudWatch Logs Insights queries to quickly find error patterns; instrument idempotency checks and record correlation IDs in logs. For distributed tracing, propagate trace IDs explicitly in event payloads for EventBridge/SNS flows if automatic context is lost. For SQS event-source mappings, monitor ApproximateAgeOfOldestMessage and set alarms if it grows, indicating backpressure or throttling. Capture and alert on Lambda Throttles metric, and track provisioned concurrency usage/cost trade-offs.

Common Pitfalls and Decision Criteria

• Not configuring DLQs or relying only on default retries: configure DLQs or Destinations for async Lambdas and SQS redrive for queues to capture poison messages for manual inspection.
• Incorrect visibility timeout on SQS leading to duplicate processing: set visibility timeout >= function timeout * 2 and account for retries and downstream calls to avoid duplicates.
• Over-permissive Lambda execution roles: avoid Resource: “*” and add service/source conditions (aws:SourceArn, aws:SourceAccount) to invocation and resource policies.
• Ignoring concurrency limits causing throttling: use reserved concurrency to cap functions, provisioned concurrency for latency-sensitive functions, and monitor ConcurrentExecutions/Throttles.
• Missing tracing across async boundaries: add correlation IDs to events and enable X-Ray or propagate trace headers to reconstruct flows.
• Misusing SNS direct-to-Lambda for durability needs: prefer SNS->SQS->Lambda when you need durable buffering, visibility control, and easier DLQ handling.

Practical Problem: Use-Case Scenario

AcmePayments receives high-volume payment events via EventBridge and experiences intermittent Lambda throttling and duplicate processing during peak. They need reliable processing, no data loss, and bounded downstream load on DynamoDB.

1. Create an EventBridge custom bus and rule to match payment events; add an SQS FIFO queue as a durable target with DeadLetterConfig and RetryPolicy in the target configuration.
2. Configure Lambda to poll the SQS queue (event source mapping) with batch size tuned to downstream capacity and visibility timeout set to >= function timeout * 2.
3. Reserve concurrency for the Lambda (aws lambda put-function-concurrency …) to limit DynamoDB write bursts; implement provisioned concurrency for a small pool if low latency is required.
4. Implement idempotency using DynamoDB conditional writes keyed by payment-id and store idempotency records with TTL for cleanup.
5. Enable X-Ray tracing and structured logs with a correlation ID in the event to trace processing; set CloudWatch alarms on ApproximateAgeOfOldestMessage, Throttles, and DLQ metrics.

Rationale: Decoupling EventBridge to SQS provides durable buffering and retry semantics; reserved concurrency protects downstream DynamoDB from bursts, idempotency prevents duplicates, and tracing/alarms provide operational visibility into failure modes.

← Databases and Caching · All domains · Cost Management and Resource Tagging →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Amazon →