AWS DVA-C02: Build, Secure and Debug Applications

The AWS Certified Developer – Associate (DVA-C02) exam is about application behavior on AWS. A developer needs to write code that uses cloud services correctly, authorizes operations narrowly, responds safely to retries, and can be deployed and investigated when something fails. A serverless function that returns the correct answer once is not yet a dependable application. The distinction becomes obvious when an event is delivered twice, a downstream service throttles requests, a secret is rotated, or a deployment breaks one user-facing endpoint.

DVA-C02 remains the current Developer – Associate exam as of October 2026. AWS's guide divides scored content into Development with AWS Services (32%), Security (26%), Deployment (24%), and Troubleshooting and Optimization (18%). It describes 50 scored questions plus 15 unscored questions, 130 minutes, and a passing scaled score of 720. AWS also identifies emerging AI-assisted developer practices that can appear as unscored pretest material, not as a newly weighted scored content domain. The official versioned content outline, rather than an unrelated cloud-engineering tutorial, should govern exam preparation.

Code should express the workload's actual behavior

Before selecting an AWS application service, describe how requests enter the system and what must happen next. A web checkout might accept a synchronous API call, store an order, send a confirmation event and trigger downstream fulfillment. Those actions have different latency, reliability and consistency requirements. Returning an acknowledgment after an order is durably stored may be appropriate; waiting synchronously for every fulfillment system may create unnecessary coupling. A developer should know which part of a process requires an immediate answer and which can progress asynchronously.

AWS Lambda can run event-driven application code and scale according to the event source and concurrency configuration. That removes conventional server management but adds other constraints: execution duration, cold-start behavior, concurrent execution, downstream capacity and event-specific retry rules. It is unsafe to assume that every invocation is unique or that returning a success code means the business transaction is complete. Lambda concurrency and resilient serverless design provide context for balancing parallelism with downstream limits.

Amazon API Gateway can expose application endpoints with authorization, validation and traffic-management capabilities, but it does not turn insecure business logic into a secure application. If a caller can request another tenant's order by changing a path parameter, authentication alone will not prevent the data leak. The application must check authorization for the requested record. Developers must understand how API authentication, application authorization, error mapping and throttling work together, and which concern belongs at each layer.

AWS SDKs hide much of the underlying HTTP ceremony, yet the developer still controls request semantics. Client retries are useful for transient failures but dangerous for non-idempotent operations. Creating a payment twice after an ambiguous timeout is a classic example. Use stable operation identifiers and server-side idempotency strategies where the service and application permit them. Distinguish failures that merit another attempt from invalid requests, permissions errors and quota conditions that require a different response. Exponential backoff and jitter reduce synchronized retry storms, but do not make unlimited retries safe.

Asynchronous applications need explicit delivery semantics

Amazon SQS, Amazon SNS and Amazon EventBridge solve different integration problems. SQS decouples consumers through a queue; SNS can distribute messages to subscribers; EventBridge routes events according to event patterns and rules. A fan-out workflow may combine them. The correct architecture depends on whether each consumer should receive a copy, whether producers need to know the consumer, how failures are retried and what evidence is retained. SQS, SNS and EventBridge integration patterns are useful when an exam case involves more than one downstream application.

Queues shift the time of processing; they do not guarantee that bad messages disappear. A dead-letter queue can isolate messages that exhaust a configured retry policy, but operators still need to diagnose the payload and replay safely. Visibility timeouts should reflect actual consumer processing and extension behavior. If the timeout is shorter than a slow operation, another consumer may receive the message while the first is still working. Duplicate delivery must therefore be treated as part of the design rather than as evidence that SQS is broken.

Event ordering also requires care. Some business processes need exact sequence within a logical entity; others can tolerate independent event processing. FIFO capabilities, where supported, bring specific ordering and deduplication features with throughput and design considerations. Do not promise global ordering across unrelated streams, queues and databases without establishing how the end-to-end system actually preserves it. Reliable application design defines what to do with late events and out-of-order updates instead of assuming they never occur.

Persistence choices determine correctness and performance

DynamoDB fits many key-value and document access patterns, but its schema should follow known access requirements. Partition-key selection shapes distribution and performance; a hot partition can throttle otherwise modest workloads. Global secondary indexes help support different query patterns, but introduce write overhead and operational decisions. The developer should understand conditional writes, optimistic concurrency and the difference between strongly consistent and eventually consistent reads in supported contexts. DynamoDB partition keys and capacity design are particularly important when an application behaves correctly at test scale but degrades under production traffic.

Relational storage remains useful for transactions, joins and constraints that fit SQL models. RDS and DynamoDB are not competing answers to every database question. A relational transaction may offer a clear consistency boundary for a workflow that needs multiple coordinated updates. DynamoDB conditional expressions may be more appropriate for a simple high-volume state transition. The candidate should examine access patterns, constraints, latency and recovery before selecting a data store.

Caching can lower response time and reduce calls to a database, but cached values can become stale. A shopping cart, inventory count and financial balance may have very different tolerance for staleness. An application must decide whether to invalidate a cache on write, use a time-to-live, tolerate temporary inconsistency or read through to the source of truth when correctness is essential. Optimization is meaningful only when the developer can explain which behavior may change as a result.

Secrets and permissions belong outside the source code

Application credentials should not be compiled into artifacts, committed to repositories or casually logged during debugging. On AWS, roles and temporary credentials can allow applications to call services without embedding long-lived access keys. AWS Secrets Manager and Systems Manager Parameter Store provide related but distinct configuration and secret-management workflows. Secret rotation adds its own application responsibilities: a process that caches a password forever may fail after an otherwise successful rotation. The comparison of Secrets Manager and Parameter Store shows why storage location is only one part of credential lifecycle design.

Least privilege should be expressed in actions, resources and conditions appropriate to the application's behavior. A function that reads one S3 object prefix should not routinely receive administrator permissions for an entire account. A developer also needs to understand which resource policies, identity policies, permission boundaries and encryption-key permissions affect the call. IAM policy evaluation provides the conceptual basis for diagnosing a denied request without reflexively granting broad access.

Data protection includes TLS where appropriate, encryption at rest, careful logging and application-specific validation. Encryption is not authorization: an encrypted object can still be disclosed to an unauthorized caller who has decryption permission. Conversely, correct IAM access to an object may not be enough if a customer-managed KMS key policy prevents decrypt. The candidate should trace the actual request path from caller to API to execution role to data access instead of viewing security as one checkbox.

Deployment is a controlled software change

Build artifacts should be reproducible and tied to versioned source. A CI pipeline can compile, test and package code; a CD process can deploy approved artifacts to an environment. AWS CodeBuild, CodePipeline and CodeDeploy support different parts of delivery depending on architecture. Knowing the role of each helps candidates interpret a deployment failure and locate the faulty stage. A failure in artifact permissions requires a different response from a healthy artifact whose runtime dependencies are incompatible with the target environment.

Staged deployment patterns limit the impact of change. Canary delivery sends a small share of traffic to a new version; linear rollout gradually increases exposure; blue/green strategies separate an existing environment from a replacement before switching traffic. Each pattern needs a health signal and rollback decision. The details of deployment strategies using CodeDeploy demonstrate that rolling out more slowly is not a substitute for checking the right application outcome.

Developers should also think about immutable versions, environment-specific configuration, dependencies, packaging and testing. If production uses an external secret or database endpoint, the build must not accidentally bake a developer's local credentials into the artifact. A staging environment that differs radically from production may fail to reveal a deployment problem. Build and deployment logs should reveal version and change identity without leaking sensitive values. The advanced task of designing an organization's complete CI/CD platform belongs more to AWS DevOps Engineer – Professional (DOP-C02) than to the core developer exam, though application developers still depend on the pipeline's behavior.

Troubleshooting means finding the failing boundary

A 500 response at an API endpoint can originate in request validation, Lambda runtime, authorization, a database connection, downstream service throttling or response-format mapping. A useful investigation correlates request identifiers, structured logs, relevant metrics, traces and deployment versions. Merely adding more log lines is not enough if they do not connect a failed user request to its downstream operations. CloudWatch and tracing tools are useful when their telemetry corresponds to the real application journey.

Rate limits and resource quotas are another source of deceptive errors. A Lambda process may be healthy while concurrent invocations exceed limits; an SQS consumer may fall behind because its database cannot accept more writes. Increasing concurrency without checking downstream capacity can deepen the incident. The correct optimization may be batching, backpressure, caching, changing an access pattern or configuring retry behavior rather than scaling every layer indiscriminately.

Debugging should distinguish deterministic software errors from intermittent infrastructure behavior. A consistently rejected API call often indicates incorrect request structure or permissions; an occasional timeout may require examination of dependency availability and retry policy. Reproduce failures using representative data, then verify the fix under concurrency and failure conditions. If a change resolves latency but breaks idempotency, the application is not truly improved.

A preparation path built around application scenarios

Practice by following an order through an API, a function, a database, a queue and a downstream consumer. At each boundary, identify the authorization policy, failure type, retry semantics, logging evidence and recovery action. Then alter one condition: the database becomes slow, a message is duplicated, a secret rotates, or a deployment begins failing its health check. State what you would measure before selecting the next step. That is closer to developer work than memorizing maximum service limits without understanding why they matter.

The official DVA-C02 guide remains the authoritative source for scored competencies. Its newer reference to AI-assisted coding, reviews, security and testing is explicitly framed as emerging unscored pretest content; do not mislabel it as a replacement for the four scored domains. For broader application design, AWS Solutions Architect – Associate (SAA-C03) may provide useful context, but DVA-C02's differentiator remains code-level correctness in an AWS environment. Passing the exam should correspond to the ability to diagnose what an application actually does under failure, not only what it is supposed to do in the happy path.