Development with AWS Services practice questions

Amazon Q Developer is the AWS AI assistant that supports developers with code generation, explanation, test suggestions, and security scanning.

The requirements — IDE-based AI assistance, code generation, unit-test suggestions, and security scanning — describe Amazon Q Developer, which is newly in scope for DVA-C02. CloudShell is a terminal in the browser, useful for running AWS CLI commands but with no code-generation capability. X-Ray belongs to observability: it traces requests across services. CodeBuild is the managed build service in the CI/CD family — it runs your build and test commands but does not help write them. Knowing each tool's purpose is enough; the exam is unlikely to probe deep Q Developer features.

1. List the asks: AI assistance in the IDE, code generation, test suggestions, security scanning.
2. Match them to Amazon Q Developer, the AWS AI development assistant.
3. Eliminate CloudShell (terminal), X-Ray (tracing), and CodeBuild (CI builds) as tools with different jobs.
4. Remember Q Developer is available in the IDE, CLI, and console.

Exam tip: Amazon Q Developer is the AWS AI development assistant: it generates and explains code, suggests unit tests, and scans for security issues.

Loose coupling with a queue: SQS buffers work between components so producers and consumers scale and fail independently.

The trigger words — absorb spikes, no data loss, process at its own pace — all point at an asynchronous, queue-based answer. SQS durably holds every job, levels the load, and lets the backend pull messages when it has capacity; a job is only deleted after successful processing, so nothing is lost. Bigger instances keep the synchronous coupling and just move the failure threshold while overprovisioning off-peak. Synchronous retries fail for the duration of a sustained spike because the backend never gets headroom. SNS push delivery re-creates the original problem: events arrive at the consumer at spike rate, and there is no durable buffer the consumer drains on its own schedule unless a queue is added behind the topic.

1. Spot the trigger words: absorb spikes, no job lost, backend works at its own pace.
2. Recognize these as the case for asynchronous decoupling with a buffer.
3. Choose SQS: durable storage of each job, pull-based consumption, retry until deleted.
4. Reject vertical scaling and synchronous retries (coupling remains) and bare SNS push (no consumer-paced durable buffer).

Exam tip: Buffer, absorb spikes, and no data loss during downstream saturation are SQS cues — put a queue between the producer and the overwhelmed consumer.

Choosing synchronous versus asynchronous communication: work the client does not need immediately should be handed off asynchronously.

The scenario states the deciding fact: the confirmation does not need to be sent instantly. That makes it asynchronous work — hand it to a queue and return, and a consumer sends the email on its own schedule with its own retries. Checkout latency then depends only on checkout. Increasing the timeout and adding synchronous backoff retries both make the customer wait longer, not shorter, when the email service degrades. Scaling the email service treats the symptom but keeps the coupling: any future slowness still surfaces directly in checkout response times. The exam pattern is consistent: emails, order processing, and similar deferrable work are the canonical asynchronous examples, while login or a price check — where the client needs the answer now — stay synchronous.

1. Ask whether the caller needs the result of the email send before responding — it does not.
2. Classify the email as deferrable work, which belongs on an asynchronous path.
3. Move it behind a queue so a consumer sends it independently, with failures retried outside the checkout flow.
4. Reject options that keep the synchronous dependency: longer timeouts, in-request retries, or scaling the dependency.

Exam tip: If the client does not need the result now, take the work off the synchronous path — hand it to a queue and respond immediately.

Idempotent consumers: queues deliver at least once, so handlers must make reprocessing a duplicate message harmless.

SQS standard queues deliver at least once, and any redelivery — for example when slow processing outlives the visibility timeout — hands the same message to the consumer again. The durable fix is idempotency: carry a key such as the order ID with each payment, record processed keys, and on a duplicate skip the charge or return the stored result. FIFO content-based deduplication is tempting but addresses a different problem: it suppresses duplicate publishes within a deduplication window, while redelivery of an in-flight message after visibility-timeout expiry still occurs, so double-charging remains possible without an idempotent handler. Raising maxReceiveCount only changes when a failing message is shunted to the DLQ. Shortening the visibility timeout actively worsens the incident that caused the duplicates.

1. Recall that SQS standard queues are at-least-once: duplicates are guaranteed to occur eventually.
2. Identify the failure mode: slow processing let the visibility timeout expire, so the message was redelivered.
3. Conclude the consumer must be idempotent — record an idempotency key and skip already-processed messages.
4. Reject FIFO deduplication (covers duplicate sends, not redelivery), maxReceiveCount (DLQ threshold), and a shorter visibility timeout (more redelivery).

Exam tip: At-least-once delivery means duplicates are inevitable — design consumers to be idempotent with a recorded idempotency key rather than trying to prevent redelivery.

Exponential backoff with jitter: transient-error retries should wait progressively longer, with randomized waits so many clients do not retry simultaneously.

The described failure — a recovering service knocked over by simultaneous retries — is exactly what jitter exists to prevent. Exponential backoff doubles the wait after each attempt so a struggling service gets breathing room, and jitter randomizes each wait so clients that failed at the same moment retry at different moments. Backoff without jitter fixes only half the problem: the waves still align at each doubled interval. A fixed interval keeps every client in lockstep, and raising the attempt count with immediate retries maximizes the thundering herd. Note that the AWS SDKs already implement backoff with jitter for throttling and 5xx errors; this pattern must also be applied in your own retry code for business operations and non-AWS calls.

1. Identify the anti-pattern: immediate, synchronized retries from many clients after throttling.
2. Apply exponential backoff so each client waits progressively longer between attempts.
3. Add jitter so the waits are randomized and clients desynchronize.
4. Remember to retry only transient errors (throttling, 5xx, timeouts) — retrying a 4xx validation error just repeats the failure.

Exam tip: Retry transient errors with exponential backoff plus jitter — backoff protects the service, jitter breaks up the synchronized retry waves.

Dead-letter queues solve the poison-pill problem: a message that can never succeed is sidelined after a configured number of receives.

A malformed payload will fail every retry forever — the classic poison pill. The purpose-built answer is a redrive policy: once the message has been received more than maxReceiveCount times, SQS moves it to the dead-letter queue, unblocking the main queue while preserving the message for inspection, fixing, and replay. Long polling is an efficiency feature for empty-queue receives and is irrelevant here. Raising the visibility timeout merely spaces out the failures. Content-based deduplication applies to FIFO queues and to duplicate publishes, not to failing messages. Production guidance goes one step further: every production queue should have a DLQ plus an alarm on its depth.

1. Recognize the poison-pill pattern: a message that fails processing on every receive and blocks the queue.
2. Recall that SQS handles this with a redrive policy: maxReceiveCount plus a dead-letter queue.
3. Configure the DLQ so failing messages are sidelined automatically and kept for inspection and replay.
4. Eliminate options that tune receive behavior (long polling, visibility timeout) rather than removing the failing message.

Exam tip: A repeatedly failing message is a poison pill — configure a redrive policy with maxReceiveCount and a dead-letter queue, and alarm on DLQ depth.