DVA-C02 - Development with AWS Services (32% of the exam) - Section 1.3

Apply stateless design and choose between synchronous and asynchronous, tightly and loosely coupled patterns when writing application code.

Distinguish stateless from stateful application design and understand why externalising session state enables horizontal scaling. Choose between synchronous and asynchronous coupling, and between loose and tight coupling, based on latency, reliability, and throughput requirements.

Stateless applicationsLoose couplingSynchronous versus asynchronousSession state externalisation

Practice question for this objective

Free sampleDevelopment with AWS Servicesmedium

A developer runs a web application on several EC2 instances behind an Application Load Balancer in an Auto Scaling group. The application currently keeps each user's logged-in session in memory on the instance that first served them, so scale-in events log users out. The developer wants the application to be stateless so any instance can serve any request. Where should the session data be stored?

AIn an Amazon ElastiCache for Redis cluster that all instances read and write, keying each session by a token in the user's cookie. Correct
BOn a shared Amazon EBS volume mounted by every instance so each request reads and writes the same on-disk session files.
CIn the local instance store of each instance, with sticky sessions on the load balancer pinning each user to one instance for their lifetime.
DIn a process-level in-memory cache replicated by a background thread that gossips session entries to the other running instances.

Externalise session state to a shared data store so the application stays stateless and any instance can serve any request. A stateless application keeps no client session in instance memory, so moving sessions to a shared low-latency store such as ElastiCache for Redis lets the load balancer route a request to any instance and lets Auto Scaling add or remove instances without losing sessions.

Why A is correct: Externalising session data to a shared ElastiCache for Redis store makes every instance stateless, so any instance can serve any request and scale-in no longer drops sessions.

Why B is wrong: A single EBS volume cannot be attached read-write to many instances at once, so this neither shares sessions reliably nor removes the per-instance state the requirement targets.

Why C is wrong: Sticky sessions keep state on one instance, so a scale-in or failure of that instance still loses the session and leaves the application stateful as before.

Why D is wrong: Custom in-memory gossip replication is fragile, races during scale events, and still keeps authoritative state inside instances rather than in an external shared store.

See more DVA-C02 practice questions, answers explained.

Exam traps in Development with AWS Services

Answers that look right on this material and are not. Each one is a distractor from a different question in the DVA-C02 bank for this domain.

On a larger local EBS volume per instance, with a nightly job that copies finished files to the other instances in the group for redundancy.
Why it is wrong: Per-instance EBS volumes still tie files to one instance and a nightly copy leaves recent files unavailable, so scale-in continues to break downloads.
Enable Application Load Balancer sticky sessions so each user is always routed back to the instance that holds their cart in local memory.
Why it is wrong: Stickiness is tempting because it preserves in-memory state, but it keeps state on the instance, so scale-in still loses the cart and the tier stays stateful.
Switch every read to a strongly consistent read, because expired items are returned only by eventually consistent reads during the TTL deletion lag.
Why it is wrong: Read consistency governs whether a read reflects recent writes, not whether expired items appear, so strong reads still return items that TTL has not yet physically deleted.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.