AWS Certified Developer Associate: A Practical DVA-C02 Guide

Effective DVA-C02 exam preparation organizes AWS knowledge around an application’s lifecycle rather than a service catalog. Start with development: choosing compute, writing SDK calls, and integrating storage or messaging. Add security: identifying callers and limiting their permissions. Then consider deployment: packaging artifacts, promoting configurations, and rolling back changes. Finally, practice troubleshooting and optimization through logs, metrics, traces, and controlled experiments. Consult the current official AWS exam guide before scheduling, because exam scope and policies can change independently of a training course.

For the example application, distinguish acceptance from completion. POST /orders can return HTTP 202 after the order and its durable processing intent are recorded; it does not need to wait for fulfillment. GET /orders/{id} exposes progress. This separation reduces coupling to slow downstream systems, but introduces eventual completion and failure states. Define PENDING, PROCESSING, COMPLETED, and FAILED transitions, including which component owns each transition. A good architecture makes these states explicit instead of hiding them behind a long-running HTTP request.

Amazon API Gateway provides an HTTP-facing boundary, while AWS Lambda runs application code without requiring you to manage servers. Choose between API Gateway HTTP APIs and REST APIs according to required features, authorization options, and operational requirements; they are not interchangeable feature sets. Authenticate requests using an appropriate authorizer, then validate input inside the application’s trust boundary. For POST /orders, derive the customer identity from verified claims rather than accepting a customer identifier as authoritative merely because it appears in the request body.

A practical handler parses the request, validates item quantities, performs a conditional database operation, and returns a stable response. Initialize SDK clients outside the handler so warm execution environments can reuse them, but never depend on that environment surviving. Set SDK timeouts below the remaining execution budget and treat temporary files as disposable. Lambda memory allocation also affects available CPU, so benchmark representative workloads rather than selecting the smallest setting automatically. For a synchronous API invocation, do not assume Lambda will retry a failed business operation: client retries require an explicit idempotency design.

DynamoDB design begins with queries, not normalized tables. Suppose the application must retrieve one customer’s order and list that customer’s recent orders. A possible key design is PK = CUSTOMER#123 and SK = ORDER#2026-09-20T10:30:00Z#abc. A GetItem request needs the full key, while Query can retrieve a customer’s order range in sort-key order. Design a separate lookup or index if callers only know an order ID. Avoid replacing missing access-pattern design with repeated Scan operations. Consider traffic concentration too: one unusually active customer can make a customer-based partition key problematic.

For a worked idempotency example, require a request token and use TransactWriteItems to create both an order and an idempotency record, with conditions preventing either intended item from being overwritten. Store a hash of the request payload and the resulting order identifier in the idempotency record. If the transaction fails because the token already exists, read that record: return the previous result for the same payload, or reject conflicting reuse. This gives a retrying client a stable outcome. Use a strongly consistent base-table read when immediate visibility matters; global secondary indexes do not support strongly consistent reads.

Amazon SQS decouples request acceptance from background work, but a standard queue provides at-least-once delivery and best-effort ordering. Workers must tolerate duplicates. There is also a dual-write problem: writing an order and then sending a message can fail between the two operations. One solution is a transactional outbox. Write the order and an outbox item in the same DynamoDB transaction, then relay outbox changes through DynamoDB Streams to SQS. The relay can still send duplicates, so consumers remain idempotent. Configure stream failure handling and reconciliation so a prolonged relay failure does not silently strand work.

Consider a worker that calls a fulfillment provider successfully but crashes before acknowledging its queue message. When the visibility timeout expires, another worker may repeat the call. Use a stable order identifier as the provider’s idempotency key when supported, and persist workflow progress. Marking a message processed before the external call risks losing work; marking it afterward cannot alone prevent duplicate external effects. With Lambda’s SQS integration, enable partial batch responses so successful records are not retried alongside failures. Size visibility timeout for processing and retry behavior, and route repeatedly failing messages to a monitored dead-letter queue.

AWS IAM separates who can act from which actions and resources are allowed. Give the API handler, queue worker, and deployment process distinct roles. The handler may need DynamoDB transaction permissions without needing access to fulfillment secrets. The worker may need queue-consumption permissions, selected table operations, and access to one secret. Prefer temporary credentials supplied through execution or task roles rather than embedding access keys. Identity policies, resource policies, permissions boundaries, and organization controls interact; an explicit deny overrides an allow. When debugging authorization, inspect the actual assumed role and exact resource ARN.

Keep user authentication separate from service authorization. A verified token establishes a caller’s identity, but application logic must still check whether that caller owns the requested order. Store credentials in a service such as AWS Secrets Manager, and plan for rotation and cache refresh rather than fetching secrets unnecessarily on every invocation. Encryption at rest does not replace access control: customer-managed KMS keys introduce their own policy and permission requirements. Redact credentials and sensitive payloads from logs. Treat observability destinations as data stores with access rules and retention requirements, not as harmless debugging output.

Serverless architecture is valuable, but not every workload belongs in Lambda. Amazon ECS is often appropriate for long-running workers, applications requiring a particular container runtime, or processing that exceeds Lambda’s execution limits. Fargate removes the need to manage the underlying EC2 instances, while leaving task sizing, networking, scaling, and application health in your hands. Distinguish the ECS task execution role, used for supported startup activities such as pulling images and publishing logs, from the task role used by application code to call AWS services. Container packaging does not make those identities interchangeable.

AWS CI/CD pipelines should produce an immutable artifact, test it, and promote that same artifact through environments. Define infrastructure with tools such as AWS SAM, AWS CDK, or CloudFormation instead of depending on console changes. For Lambda, publish a version and deploy through an alias; weighted traffic shifting and alarm-driven rollback can limit exposure to a regression. For ECS, configure health checks and a deployment strategy appropriate to the service. Include unit tests, integration tests, and failure-path tests. Design schema and event changes for backward compatibility because old and new application versions may run simultaneously.

Cloud observability combines three different views. Metrics show patterns such as Lambda throttling, API latency, DynamoDB throttled requests, and queue age. Structured logs explain individual decisions and errors. Distributed traces connect service calls and expose where time is spent. Propagate a correlation identifier through the HTTP request, order record, and queue message, without assuming one request always maps to one execution. Instrument supported services with tracing tools such as AWS X-Ray or OpenTelemetry-based instrumentation. Track business outcomes too: a technically healthy function can still reject every valid order because of a configuration mistake.

Suppose orders remain PENDING while API latency looks normal. First inspect queue depth and oldest-message age, then worker errors, concurrency limits, and dead-letter messages. If workers are running but database calls are throttled, investigate access patterns and capacity before raising worker concurrency and amplifying pressure. Reproduce the failure in a controlled environment, change one variable, and verify recovery with the same signals that exposed the problem. This investigation-driven workflow is central to Erudex’s course approach: learn the service mechanisms, implement a complete path, and explain how it behaves when dependencies slow down or fail.