Development with AWS Services

Development with AWS Services is the largest slice of DVA-C02 (32%, the biggest of the four domains), and almost every stem reduces to one of three choices. First, the compute model: does the code run as event-driven, sub-15-minute functions on AWS Lambda, or as long-lived, stateful, or steady-throughput work on containers (Fargate/ECS) or EC2. Second, the integration model: how independent components hand work to each other without failing together. Third, the persistence model: which managed data store fits the read/write pattern. The three subtopics map one-to-one onto these decisions, so a question that names a timeout, a queue, a partition key, or a fanout is signalling which of the three it is testing.

Lambda is the default serverless compute when work is event-triggered, bursty, and each unit finishes well within the hard 15-minute (900-second) timeout; you pay per millisecond and never manage servers. Memory is the single tuning dial because CPU is allocated proportionally to it (about one full vCPU at 1,769 MB), so raising memory on CPU-bound code can cut both duration and cost. The moment work needs to run longer than 15 minutes, hold durable local state, or sustain steady high-throughput compute, the answer shifts to Fargate, ECS, or EC2: Lambda's /tmp and execution environment are ephemeral and not a reliable store. The execution environment is reused warm, so initialization code outside the handler runs once and is shared across invocations.

Two components are tightly coupled when the caller invokes the worker directly and waits; if the worker stalls, the caller fails with it. The fix is a managed intermediary so the producer hands off and returns immediately. Which intermediary depends on who must read each message: Amazon SQS is a poll-based queue where one consumer from a competing pool claims each message (work distribution, load leveling); Amazon SNS is push pub/sub that fans one message out to every subscriber in parallel; Amazon EventBridge routes by rules that match fields inside the event JSON and integrates SaaS/AWS event sources with archive and replay. When a workflow needs ordered, visible, exactly-once steps, centralize control in an AWS Step Functions Standard state machine rather than tracing scattered events.

Every async hop in this domain (SQS standard queues, SNS, EventBridge, async Lambda invokes) guarantees at-least-once delivery, meaning a message can arrive more than once and standard queues only promise best-effort ordering. A consumer must therefore be idempotent: processing the same message twice yields the same result as once, typically by deduplicating on a message ID with a DynamoDB conditional write. Only switch to an SQS FIFO queue when strict ordering and exactly-once processing inside a deduplication window are mandatory, accepting its lower throughput ceiling. The same discipline covers transient errors: lean on the AWS SDK's built-in retry-with-exponential-backoff-and-jitter rather than hand-rolled sleep loops.

Match the store to how the application reads and writes: DynamoDB for single-digit-millisecond key/value lookups at any scale, RDS/Aurora for joins and ad hoc multi-column filters, Amazon S3 for large objects fetched by key (keep only the key in the database), and OpenSearch for full-text search. A workload routing most traffic through one known key is a DynamoDB signal; one that filters and joins across columns is a relational signal. DynamoDB reads are eventually consistent by default: request strong consistency only where the latest write must be seen, because an eventually consistent read costs half a strongly consistent one. When the same items are read far more than written, put DynamoDB Accelerator (DAX) in front of DynamoDB or ElastiCache in front of a relational backend, but a cache accelerates a durable store, it never replaces one.

Whichever compute, messaging, or storage service a question lands on, application code calls it through the language-specific AWS SDK (Boto3, AWS SDK for JavaScript v3, and so on), which signs requests with temporary credentials pulled from the default credential provider chain. For Lambda that is the function's execution role. The execution role defines what the function may do outbound; a separate resource-based policy controls who may invoke it inbound, and the two are frequently confused on the exam. Hardcoding long-lived access keys is the wrong answer in every variant of these scenarios. This is the through-line that stitches the three subtopics together: same SDK, same credential model, same retry behaviour across compute, integration, and data.