Study guide
Serverless, Decoupling, Purpose-Built Databases, and Integration Services
AWS Certified Solutions Architect - Professional SAP-C02
Track your progress as you read
Finished sections get a check mark.
1 Introduction and SAP-C02 Exam Facts
Current SAP-C02 Exam Facts Exam Format, Scoring, and Retakes Candidate Profile and Four Exam Domains
2 Multi-Account Governance
Multi-Account Strategy, Account Topologies, and OU Hierarchies Service Control Policies, Inheritance, and Permission Guardrails Control Tower, Landing Zones, Central Logging, and Resource Sharing
3 Hybrid and Inter-VPC Connectivity
Transit Gateway, VPC Connectivity, and PrivateLink Direct Connect, VPN, and Hybrid Redundancy Hybrid DNS with Route 53 Resolver Segmentation, Traffic Monitoring, and Service Endpoints
4 Identity Federation and Cross-Account Access
IAM Identity Center, External IdPs, and Workforce Federation Cross-Account Roles, STS, and Resource Policies Permissions Boundaries, Delegated Administration, and Least Privilege at Scale
5 Data Protection, Encryption, and Compliance
KMS, Multi-Region Keys, Envelope Encryption, and Certificates Encryption in Transit, Security Groups, NACLs, and VPC Endpoints Centralized Audit, Security Hub, GuardDuty, Inspector, and Access Analyzer
6 Deployment, Compute, Containers, and Serverless
Infrastructure as Code, CI/CD, Change Management, and Rollback EC2 Families, Auto Scaling, and Managed Compute ECS, EKS, Fargate, and ECR at Enterprise Scale Lambda, Step Functions, API Gateway, and Configuration Management
7 Storage, Caching, and Edge Performance
S3 Storage Classes, Object Lock, Replication, and Access Paths EBS, EFS, FSx Family, and Storage Gateway CloudFront Behaviors, Origin Access, Edge Compute, and Global Accelerator ElastiCache, MemoryDB, DAX, and Buffering versus Cache versus Replicas
8 Purpose-Built and Global Databases
Aurora Storage, Replicas, and Global Database DynamoDB Keys, Global Tables, and DAX Purpose-Built Database Selection
9 Integration, Messaging, and Streaming
API Gateway Architectures Decoupled Messaging with Amazon SQS and Amazon SNS Event-Driven Design with Amazon EventBridge Streaming Analytics with Amazon Kinesis and Amazon MSK
10 Resilience and Disaster Recovery
Disaster Recovery Patterns Route 53 Routing and Application Recovery Controller Backup, Replication, and Service Quotas High Availability, Failover, Chaos, and Self-Healing
11 Operational Excellence and Automation
CloudWatch Centralized Telemetry Distributed Tracing with AWS X-Ray Systems Manager Automation Deployment Strategies and Auto-Remediation
12 Cost Optimization and Visibility
Cost Explorer, Budgets, CUR, and Allocation Tags Savings Plans, Reserved Instances, Coverage, and Sharing Spot, Mixed Auto Scaling, Compute Optimizer, and Storage Lens Data Transfer Modeling: NAT, Endpoints, CloudFront, and Hybrid
13 Improve Security and Performance
Secrets, Least Privilege Audits, and Traceability Config Rules, Patching, Backup, and Regulatory Controls Performance Tuning for Existing Workloads
14 Migration Assessment and Wave Planning
Seven Migration Strategies (7 Rs) and Workload Selection Application Discovery, Migration Hub, and Migration Evaluator Wave Planning, Prioritization, and Assessment Governance
15 Migration Tools and Data Transfer
AWS Application Migration Service (MGN) AWS DMS, SCT, and Change Data Capture Large-Scale Data Transfer and Landing-Zone Prerequisites
16 Target Architecture, Modernization, and Cutover
Selecting Compute, Storage, and Database Platforms for Migrated Workloads Container Modernization: ECS, EKS, Fargate, ECR, and Strangler Fig Serverless, Decoupling, Purpose-Built Databases, and Integration Services Cutover, Rollback, and Unscored Emerging AI Topics
Serverless, Decoupling, Purpose-Built Databases, and Integration Services
Key Takeaways Explain This Topic AI
SAP-C02 Task 4.4 skills are to identify decoupling, serverless, container, purpose-built database, and application-integration opportunities on workloads that already exist—not to rebuild every rehosted VM in the first wave.
AWS Lambda fits event-sized work with a maximum 15-minute duration; long-running portal processes stay on ECS, EKS, or EC2 until they are broken into events.
Amazon SQS buffers competing consumers; Amazon SNS fans out notifications; Amazon EventBridge routes on event content across buses with archive and replay; AWS Step Functions orchestrates branches, retries, and waits that a pile of Lambda functions should not encode in application code.
Purpose-built databases in the Task 4.4 list include Amazon DynamoDB, Amazon Aurora Serverless, and Amazon ElastiCache; pick them from access patterns, not from a slogan that relational stores are obsolete.
Aurora Serverless measures capacity in Aurora capacity units (about 2 GiB of memory per ACU), scales in fine increments (including half ACUs), and can use a 0–256 ACU range with auto-pause on supported versions—use it for spiky or uncertain load, not as a silent engine conversion.
Last updated: September 2026
Task 4.4 is an opportunity hunt
SAP-C02 Task 4.4 asks you to determine opportunities for modernization and enhancements . The exam guide’s knowledge list is AWS Lambda , containers (ECS, EKS, Fargate), Amazon S3 and Amazon EFS , purpose-built databases ( DynamoDB , Amazon Aurora Serverless , Amazon ElastiCache ), and integration services ( Amazon SQS , Amazon SNS , Amazon EventBridge , AWS Step Functions ). The skills list is the exam’s real scoring lens: identify decoupling , identify serverless , select a container service, identify purpose-built databases , and select an application integration service.
Independent ExamFinch material treats Task 4.4 as a second pass on Meridian’s estate after Task 4.3 landed the workload. AWS Prescriptive Guidance still warns that refactor during a large migration is the most complex R. The Professional move is often: rehost or replatform first, then peel a bottleneck into Lambda and a queue once the application is reachable in a VPC.
Identify decoupling before you identify Lambda
A coupled clinic-order flow looks like this: the portal process calls billing, which calls insurance eligibility, which writes a PDF, which sends email, all in one synchronous thread with a 30-second client timeout. Modernization is not “wrap each hop in a Lambda and keep the synchronous chain.” That produces a distributed monolith with worse timeouts.
Decouple with an integration service that matches the failure domain:
Service What it is Modernization tell
Amazon SQS Pull queue; competing consumers; delay and visibility timeout; dead-letter queues on standard and FIFO queues Billing workers should absorb a 10× spike without taking down the portal; FIFO when order of insurance submissions must be preserved per patient
Amazon SNS Push topic; fan-out to SQS, Lambda, HTTP, and other subscribers “Claim submitted” must notify billing, analytics, and a paging channel independently
Amazon EventBridge Event bus with content-based rules, partner and SaaS sources, archive/replay, and Pipes Many producers, many consumers, you route on detail-type and payload rather than building a custom dispatcher
AWS Step Functions State machine: sequence, parallel, choice, retries, catch, wait Multi-step clinic onboarding with compensating actions; do not bury that graph in Lambda code
Amazon MQ exists on the in-scope list for native JMS/AMQP broker lifts; it is a replatform of a broker , not the first choice when the stem wants cloud-native fan-out. Prefer SQS/SNS/EventBridge unless the application must keep that broker protocol this wave.
A Meridian pattern that SAP-C02 rewards: portal writes an order placed event to EventBridge → a rule enqueues an SQS queue for billing workers on ECS or Lambda → SNS notifies the clinic operations topic → Step Functions runs the exception path when a dead-letter message needs a human-scale workflow (the human-approval mechanics return in the next section’s pretest AI discussion; scored Task 4.4 still uses Step Functions as orchestration ).
Identify serverless—and when not to
AWS Lambda is the Task 4.4 serverless compute example. It fits short, event-driven units of work: image thumbnailing to S3, a stream filter, an API that was already a single function, a queue consumer. Lambda’s maximum configurable duration is 15 minutes . A portal request that renders a 40-minute report is not a Lambda. Neither is a process that needs GPU, a sticky in-memory session for thousands of concurrent websocket users (without an external store), or a binary that cannot run in the Lambda execution environment.
Serverless storage on the Task 4.4 list is S3 and EFS . Moving PDF archives from a rehosted Windows disk to S3 (with CloudFront if patients download them) is modernization. Mounting EFS under Lambda or ECS so a legacy Java library can keep POSIX files is a bridge , not a failure to be cloud-native.
Do not “serverless-wash” a rehost wave: 120 MGN-cutover guests do not become 120 Lambda functions on Friday night. Identify the one spiky, event-shaped seam (eligibility checks, PDF generation, notification) and peel that first.
Purpose-built databases and Aurora Serverless
Task 4.3 asked where the existing engine lives. Task 4.4 asks whether a different engine matches the access pattern better.
Amazon DynamoDB is for key-value and document items with known partition and sort keys, on-demand or provisioned capacity, and optional Global Tables. Session tokens, device registries, and a patient-profile lookup by patientId are DynamoDB-shaped. Ad-hoc clinic reporting across ten normalized tables is not.
Amazon ElastiCache (Redis OSS / Valkey / Memcached as currently offered in the account) is an in-memory store for session caches, leaderboards, and hot keys you should stop hitting RDS for on every page load. It is not the system of record for encounter attachments.
Amazon Aurora Serverless is an on-demand autoscaling configuration for Aurora. AWS documents capacity in Aurora capacity units (ACUs) . Each ACU is a combination of approximately 2 GiB of memory , corresponding CPU, and networking. Scaling can add or remove as little as 0.5 ACU . Supported capacity ranges depend on engine and platform version; AWS currently documents ranges including 0.5–128 , 0.5–256 , and 0–256 ACUs, with 0 ACU enabling automatic pause and resume when idle on versions that support it. You set a minimum and maximum range; storage scales separately from compute. Mixed clusters can combine serverless and provisioned writers or readers. Aurora Serverless can participate in Multi-AZ designs, reader scaling, and Aurora global databases. It is especially useful for spiky , multi-tenant , new , or dev/test databases where provisioning a fixed instance class is guesswork.
Aurora Serverless is not a different database engine. It does not convert SQL Server to PostgreSQL by itself. It does not replace DynamoDB for a key-value workload. It is a capacity mode for Aurora MySQL or Aurora PostgreSQL after you have already chosen that engine (often via AWS Database Migration Service and Schema Conversion Tool in the previous chapter).
A Meridian scheduling database that is quiet at 02:00 and slammed when clinics open is an Aurora Serverless candidate once it is on Aurora. A claims reporting warehouse that runs heavy analytical scans might belong on Amazon Redshift (in-scope, but not the Task 4.4 example list)—do not cram it into DynamoDB because “purpose-built” sounded fashionable.
Integration plus data: a worked clinic seam
After rehost, Meridian’s portal still generates insurance PDFs inside the web process. Modernization:
Portal publishes document.requested on EventBridge.
A rule starts a Step Functions standard workflow (durable, not Express) that waits, retries, and records failure causes.
A Lambda (or Fargate task if the PDF library needs more than 15 minutes or a special binary) writes the PDF to S3 and an object URL to DynamoDB keyed by patientId + documentId .
SNS notifies the clinic printer queue (SQS) and the patient email path.
RDS keeps the encounter system of record until a later bounded-context split.
That design uses every Task 4.4 skill without pretending the monolith vanished.
- Exam traps
- Chained synchronous Lambdas as “decoupling.”
Lambda for a 40-minute report or a GPU imaging pipeline.
EventBridge when you needed a durable competing-consumer queue (SQS), or SQS when you needed content-based routing across many domains (EventBridge).
DynamoDB for multi-join reporting; ElastiCache as a system of record; Aurora Serverless as an engine converter.
Refactoring 120 applications to serverless during the lease-exit weekend.
Inventing an unpublished AWS exam pass-rate percentage as proof the modernization worked.