Exam AWS Certified Solutions Architect - Associate SAA-C03 topic 1 question 390 discussion

It is A and D. Proof is in link below. https://aws.amazon.com/caching/session-management/

I did not get why A is most voted? The question did not mention anything about fixed routing target so the ALB should route traffic randomly to each server. Then we just need to provide cache session management to avoid session lost issue instead of using sticky session.

First of all - application MUST STORE session DATA. We should get some storage on backend side. Just Band D can do it.

Avoid sticky sessions: While using sticky sessions on an Application Load Balancer (ALB) might seem like a solution, it can hinder scalability as it ties a user to a specific instance, which could become a bottleneck if traffic spikes. Dynamodb and Elastic cache are best i think

A is not right, the question is to where to save user session, the sticky session is used for ALB to send the request of the same client to the same target.

People select AD because they think it is combine A and D to make a final solution. if the expectation is that each selected option should independently meet the requirements, then B and D. I think "Which solutions will meet these requirements?" should mean two independent solutions.

session management during transaction ---> DynamoDB and ElastiCache

We are not looking here for a combination of options, just two independent solutions. Because of the "durability" requirement - B - DynamoDB is durable D - ElastiCache for Redis although mostly used as in-memory cache, ElastiCache for Redis provides options for data persistence - RDB (Redis Database Backup) and AOF (Append-Only File). RDB periodically saves a snapshot of the dataset to disk, while AOF logs every write operation and replays it in case of a restart. ElastiCache for Redis also allows configuring replication groups with Multi-AZ and read replicas, providing additional redundancy and failover options.

AD First consider the durability requirement of a session. It's never meant to be kept after the session terminates, tha5 said. You wouldn't need a pamanent database for a session. You would only require a catche, so that it can expire after a while when the session has already completed. That is why D is correct. A is required in the first place in order to initialize the use of the catche.

Option A suggests using sticky sessions (session affinity) on the Application Load Balancer (ALB). While sticky sessions can help route requests from the same client to the same backend server, it doesn't directly address the requirement for durable storage of session data. Sticky sessions are typically used to maintain session state at the load balancer level, but they do not provide data durability in case of server failures or restarts. Option A - is not correct ! ! ! So answer is option B and D ! ! !

why does it matter to store user sessions durably? they EXPIRE, why would a company care about storing user sessions, thats not something thats done in the real world, those things are usually data dumped, or overwritten with new session tokens LOL, this whole question is &^%&*^$#@%^

I think the question is intended to mean "Combination of services", as some answers say "to store" or "to manage". So i am going for A+B, as sticky sessions are intended to manage the sessions and DynamoDB to store durably.

Going for AB. Sticky Sessions to "optimize customer session management during transactions" and DynamoDB to "store session data durably". D, ElastiCache does NOT allow "durable" storage. Just because there's an article that contains both words "ElastiCache" and "durable" does not prove the contrary. C and E, Cognito and Systems Manager, have nothing to do with the issue.

I don't understand what Sticky Session has to do with session storage. For the intent of the problem, I think DynamoDB and Redis are appropriate.

Chatgpt4 says B and D Option A (Sticky sessions) is more for ensuring that a client's requests are sent to the same target once a session is established, but it doesn't provide a mechanism for durable session data storage across multiple instances. Option C (Amazon Cognito) is more for user identity management rather than session data storage during transactions. Option E (AWS Systems Manager Application Manager) is not a suitable or standard choice for session management in applications.

Well, this documentation says it all. Option A is obvious, and D ElastiCache for Redis, can even support replication in case of node failure/session data loss. https://aws.amazon.com/caching/session-management/

It is A and D. Proof is in link below. https://aws.amazon.com/caching/session-management/