Serverless, Decoupling, Purpose-Built Databases, and Integration Services
Key Takeaways
- 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.
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 OpenExamPrep 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.requestedon 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.
After a rehost, Meridian’s portal still calls billing, eligibility, PDF generation, and email in one synchronous thread. Clients time out when eligibility is slow. The architect must identify a decoupling opportunity that matches Task 4.4 integration services. Which design should they choose?
Meridian’s clinic-scheduling database is already on Amazon Aurora PostgreSQL. Traffic is near zero overnight and spikes when front desks open. Capacity planning with a fixed instance class keeps either wasting money at 02:00 or falling over at 08:00. Which Task 4.4 database opportunity matches that pattern?
A later modernization wave peels three access patterns out of Meridian’s bloated portal database: (1) per-request session blobs, (2) a patient-profile lookup by patient ID used on every page, and (3) multi-table financial reporting that still needs SQL joins. Which purpose-built combination matches Task 4.4 without pretending reporting is key-value?