AWS Certified Developer - Associate (DVA-C02) #6 Domain 1-5 Development with AWS Services — SDK Development Patterns

If #2 through #5 looked at individual services, this post is about the patterns that commonly recur when you call those services in code. The exam regularly asks questions not about a specific service but about “the correct way to call an API.” Pagination, retries, idempotency, S3 uploads, and credential supply are the core of it.

Pagination #

AWS APIs have a limit on the number of results returned at once. Calls like ListObjectsV2, Query, Scan, and DescribeInstances truncate results when there are many, and return a token pointing to the next page along with them.

• If the response has a NextToken (or LastEvaluatedKey, or IsTruncated + ContinuationToken), it means there are more results.
• Put that token into the next request and call repeatedly.
• Most SDKs provide a paginator to automate this iteration.

Exam trap: the cause of a “only part of the results come back” bug is usually not handling pagination — code that reads only the first page and stops.

Exponential backoff and jitter #

For throttling (ThrottlingException, ProvisionedThroughputExceededException, 429, 503) or transient errors, you must not retry immediately. If everyone retries at the same moment, the load grows even larger (thundering herd).

• Exponential backoff — increase the retry interval exponentially, like 1s, 2s, 4s.
• Jitter — add randomness to the interval to spread out retry timings.

The good news is that the AWS SDK has exponential backoff + jitter retries built in by default. You can adjust the retry count and mode (legacy/standard/adaptive) via configuration. The answer to “how do you handle throttling?” is almost always retry with exponential backoff, and it’s recommended to handle it via SDK configuration rather than implementing it yourself.

Idempotency #

As seen in #2 and #5, asynchronous and queue-based delivery can deliver the same request multiple times (at-least-once). Side-effecting operations must be made idempotent.

• Idempotency key — the client assigns a unique key per request (e.g., an order ID, a UUID), and the server identifies duplicates by that key.
• Implement with conditional writes — use the DynamoDB attribute_not_exists condition to enforce “process only when the key is seen for the first time.”
• Some AWS APIs directly support idempotency token parameters like ClientRequestToken.

S3 development patterns #

Multipart upload #

Large objects (recommended: 100 MB and up, required: over 5 GB) are uploaded in parts via multipart upload.

• Upload parts in parallel to speed things up, and resend only the failed parts.
• Incomplete multipart uploads incur storage cost, so it’s recommended to clean up incomplete uploads with a lifecycle rule.

presigned URL #

The server issues a temporary signed URL so the client can upload/download directly to S3 without AWS credentials for a set period.

• It’s the standard way to grant S3 access to mobile/web clients without distributing IAM keys.
• The URL carries the permissions and expiration of the principal that issued it.

The answer to “I need to upload a large file from the browser directly to S3, without going through the server” is a presigned URL.

S3 consistency #

S3 now provides strong read-after-write consistency for new object PUTs and for overwrites and deletes (the previous eventual-consistency model no longer applies). That said, when the same key is written concurrently, the last write wins.

SDK credential provider chain #

The SDK looks for credentials in a fixed priority order. The exam asks “how do you supply credentials without hardcoding keys in code?”

1. Credentials passed explicitly in code
2. Environment variables (AWS_ACCESS_KEY_ID, etc.)
3. Shared credentials file (~/.aws/credentials)
4. IAM Role (EC2 instance profile, ECS task role, Lambda execution role)

The production recommendation is an IAM Role. On EC2, ECS, and Lambda, if you attach a Role, the SDK automatically fetches temporary credentials, so there’s no need to store keys. That’s why the answer to “code on EC2 accesses S3” is always a Role.

Other exam points #

• Region/endpoint — the SDK client must specify a region. The wrong region is a common bug.
• CLI --dry-run — checks only permissions without actually executing.
• The request ID in error responses — attach x-amz-request-id for support inquiries and debugging.

Exam question patterns #

• “A list API returns only part of the results.” → Pagination not handled.
• “How do you handle throttling?” → Exponential backoff + jitter (SDK default retries).
• “Queue messages are delivered in duplicate and processed twice.” → Idempotency key + conditional write.
• “Upload directly from the browser to S3, without distributing keys.” → presigned URL.
• “Reliably upload a file over 5 GB.” → Multipart upload.
• “How do you give an access key to code on EC2?” → IAM Role (no storage).
• “A 400 InvalidRequest keeps recurring.” → Fix the request/permissions, don’t retry (4xx retries are pointless).

Wrap-up #

What this post locked in:

• Pagination — iterate following the token. Code that reads only the first page is a bug
• Exponential backoff + jitter — for throttling/5xx. Built into the SDK; 4xx retries are pointless
• Idempotency key + conditional write to defend against at-least-once duplicates
• S3 — multipart for large files, presigned URL for direct client access
• Credential provider chain — in production, an IAM Role with no stored keys

Next — Domain 2-1 Authentication and Authorization #

We’ve finished the development domain. Next is security, which carries 26%. In #7 Authentication and Authorization, I’ll revisit IAM Roles from a code perspective, the division of roles between Cognito User Pools and Identity Pools, and STS temporary credentials and federation.