Course menuDVA-C03

Exams / DVA-C03 / Study guide / SDKs, retries and error handling

SDKs, retries and error handling: DVA-C03 study notes and practice questions

What to know about SDKs, retries and error handling for the DVA-C03 exam, from the Development with AWS Services domain (30% of the exam guide), then 2 free questions to test it. Part of the DVA-C03 study guide.

Last verified against current AWS documentation ·How we write our questions

What to know for the exam

Resilience questions in Domain 1 ask what the application code should do when an AWS call fails. The answer usually depends on whether the error is transient, whether the operation is safe to repeat and whether the caller can keep working without the result.

Retries

  • Retry only transient errors, such as throttling (ThrottlingException) and temporary server errors (HTTP 503). Access denied, validation and not-found errors return the same result every time, so retrying only adds delay.
  • Use exponential backoff with jitter. The growing wait reduces load on the service, the random element stops many workers from retrying together, and a maximum attempt count stops endless retries.
  • SDK retry modes: standard retries throttled and transient calls with backoff. adaptive adds a client-side rate limiter so a throttled client slows its request rate in advance. Use adaptive when one client keeps hitting throttling.
  • The SDK attempt count can be set in code or with an environment variable such as AWS_MAX_ATTEMPTS, without touching the code.

Safe retries

  • A retry is safe only if the operation is idempotent. Give each logical request an idempotency token, store it with the result, and return the stored result on a repeat.
  • A conditional write (for example, a write that succeeds only if the item does not exist) makes a repeat harmless.
  • Partial successes need checking. BatchWriteItem can succeed while returning UnprocessedItems, and PutRecords can return HTTP 200 with failed records. Resubmit only the failed items, with backoff.

Graceful degradation and circuit breakers

  • A circuit breaker opens after repeated failures and fails calls at once, then tests the service again later.
  • Graceful degradation serves a fallback when a dependency fails, such as a cached value or a reduced feature.

Stacked retries

Retries multiply. Lambda asynchronous retries combined with several SDK attempts per call can produce many more calls than expected. Lower one layer, such as Lambda’s asynchronous retries.

Serialization

Code converts data to the formats AWS services expect, such as JSON for API and Lambda payloads and typed attribute values for DynamoDB. Prefer the SDK’s document or marshalling helpers over hand-built formats.

Credentials and pagination

  • The default credential provider chain stops at the first credentials it finds. Environment variables come before the instance profile or task role, so stale keys in the environment hide the role. Remove them, and the chain reaches the role with no code change.
  • List calls are paged. ListObjectsV2 returns up to 1,000 keys per response; keep calling with NextContinuationToken while IsTruncated is true.

Common traps

  • Retrying every error, including access denied.
  • Adaptive mode to fix a retry storm when the question only asks for a larger attempt count.
  • Retrying a payment or write without an idempotency key.
  • Treating UnprocessedItems as success.
  • Fixing credential errors with more retries. Check which credentials the chain picks first.

Try the 2 practice questions

A photo-tagging service runs 300 workers that call an AWS API at the same time.

During busy periods many of the calls fail with ThrottlingException. The batch must finish before the morning publishing run, so the calls cannot simply be dropped. The developer is writing custom retry code around one of these calls.

Which approach does AWS recommend for retrying the call?

Choose one answer.

  1. A. Retry straight away in a tight loop until the call succeeds.
  2. B. Retry after a fixed one-second delay, with no limit on how many attempts are made.
  3. C. Retry with exponential backoff and random jitter, up to a fixed maximum number of attempts.
  4. D. Treat ThrottlingException as a permanent error and fail the job straight away, so the workers stop sending requests.
Show the answer and explanation

Answer: C

  • A. Wrong: Immediate retries add load to a service that is already throttling, which makes the problem worse. Retries should wait before they are sent.
  • B. Wrong: A fixed delay keeps every worker retrying at the same moments, and with no limit a call could retry forever.
  • C. Right: Correct. Growing delays ease the pressure on the service, random jitter spreads out the retries from many workers, and a maximum stops endless retrying. Learn more: Retry behavior in the AWS SDKs (opens in a new tab)
  • D. Wrong: Throttling is a transient error that the SDKs retry. Failing at once gives up on requests that would have succeeded a moment later.

Explanation

AWS recommends exponential backoff with jitter for throttling errors. The growing wait reduces the load on the service, the random element stops many workers retrying together, and a limit on attempts keeps the job from retrying forever.

Study

A reporting service runs on an Amazon EC2 instance and uploads CSV files to an Amazon S3 bucket.

Its S3 client is created without explicit credentials, so the AWS SDK default credential provider chain applies. The instance profile role allows s3:PutObject on the bucket.

A former operator set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in the service environment, using an IAM user whose S3 permissions were removed, so uploads now fail with AccessDenied. The application code must not change.

What should the developer do?

Choose one answer.

  1. A. Remove the two variables from the service environment and restart it, so the SDK falls through to the instance role.
  2. B. Add a bucket policy statement that grants PutObject to the former IAM user, so that uploads made with its stale keys succeed.
  3. C. Attach a policy to the instance role that denies PutObject to the environment keys, so that the SDK skips them for uploads.
  4. D. Pass the instance role's ARN to the S3 client constructor in code, so that the SDK assumes the role directly for each request.
Show the answer and explanation

Answer: A

  • A. Right: Correct. Environment variables are checked before the instance profile in the default chain. Once they are removed, the SDK finds and uses the role's temporary credentials. Learn more: Set credentials in Node.js (opens in a new tab)
  • B. Wrong: This adds permissions to a user whose key should not be used at all. The stale key would still take precedence over the instance role.
  • C. Wrong: IAM policies control what a principal may do, not which credentials the SDK selects. The environment keys would still be used, and their requests would still fail.
  • D. Wrong: The code must not change, and the default chain already finds the instance profile's role without any role ARN. Extra configuration is not needed.

Explanation

The default chain stops at the first credentials it finds, and environment variables come before the instance profile. The stale user keys therefore win, and the role is never used. Removing the variables lets the chain reach the role without any code change.

Study

Want more on SDKs, retries and error handling? The 5 full-length practice sets have 10 more SDKs, retries and error handling questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets

Study SDKs, retries and error handling

More Development with AWS Services topics