The correct answer is A. Use Amazon ElastiCache to manage and store session data. In order to support distributed session data management in this scenario, it is necessary to use a distributed data store such as Amazon ElastiCache. This will allow the session data to be stored and accessed by multiple EC2 instances across multiple Availability Zones, which is necessary for a scalable and highly available architecture. Option B, using session affinity (sticky sessions) of the ALB, would not be sufficient because this would only allow the session data to be stored on a single EC2 instance, which would not be able to scale across multiple Availability Zones. Options C and D, using Session Manager and the GetSessionToken API operation in AWS STS, are not related to session data management and would not be appropriate solutions for this scenario.

A is the correct answer because it allows to manage distributed sessions

A is in scope of question as company is willing to make code changes. B would have been correct if no code changes were allowed and scaling could be compromised. C is wrong technology (cloud management) D is also wrong technology (AWS IAM or account management).

A is correct B is not correct as session affinity allow web user stick to a EC2 instance for a period time, that EC2 could go down then the session data will lost, so doesn't fit this use case C is wrong as Session Manager is for admins users to manage EC2 CLI access, it's not for web end users D is wrong as GetSessionToken API is for use case such as you need to grant user access to a S3 bucket with customized code

Yap agree with go you guys, this is one of the use cases for Amazon ElastiCache. It was designed to store ephemeral session data to quickly personalize gaming, e-commerce, social media, and online applications with microsecond response times. https://aws.amazon.com/elasticache/#:~:text=Store-,ephemeral,-session%20data%20to

The correct answer is A. Use Amazon ElastiCache to manage and store session data.

ElastiCache is a managed in-memory data store service that is well-suited for managing session data in a distributed architecture. It provides high-performance, scalable, and durable storage for session data, allowing multiple EC2 instances to access and share session data seamlessly. By using ElastiCache, the application can offload the session management workload from the EC2 instances and leverage the distributed caching capabilities of ElastiCache for improved scalability and performance. Option B, using session affinity (sticky sessions) of the ALB, is not the best choice for distributed session data management because it ties each session to a specific EC2 instance. As the instances scale up and down frequently, it can lead to uneven load distribution and may not provide optimal scalability. Options C and D are not applicable for managing session data. AWS Systems Manager's Session Manager is primarily used for secure remote shell access to EC2 instances, and the AWS STS GetSessionToken API operation is used for temporary security credentials and not session data management.

ElastiCache is a managed in-memory data store service that is well-suited for managing session data in a distributed architecture. It provides high-performance, scalable, and durable storage for session data, allowing multiple EC2 instances to access and share session data seamlessly. By using ElastiCache, the application can offload the session management workload from the EC2 instances and leverage the distributed caching capabilities of ElastiCache for improved scalability and performance. Option B, using session affinity (sticky sessions) of the ALB, is not the best choice for distributed session data management because it ties each session to a specific EC2 instance. As the instances scale up and down frequently, it can lead to uneven load distribution and may not provide optimal scalability. Options C and D are not applicable for managing session data. AWS Systems Manager's Session Manager is primarily used for secure remote shell access to EC2 instances, and the AWS STS GetSessionToken API operation is used for temporary security credentials and not session data management.

A. Use Amazon ElastiCache to manage and store session data. - Correct. - Session data is managed at the application-layer, and a distributed cache should be used B. Use session affinity (sticky sessions) of the ALB to manage session data. - Wrong. This tightly couples the individual EC2 instances to the session data, and requires additional logic in the ALB. When scale-in happens, the session data stored on individual EC2 instances is destroyed

correct answer is A as instance are getting up and down.

야 근데 210문제는 어딧냐 ..?

Amazon ElastiCache to manage and store session data.

https://www.examtopics.com/discussions/amazon/view/46412-exam-aws-certified-solutions-architect-associate-saa-c02/

A Amazon ElastiCache to manage and store session data. This solution will allow the application to automatically scale across multiple Availability Zones without losing session data, as the session data will be stored in a cache that is accessible from any EC2 instance. Additionally, using Amazon ElastiCache will enable the company to easily manage and scale the cache as needed, without requiring any changes to the application code. Option C is not correct because,Session Manager from AWS Systems Manager will not provide the necessary support for distributed session data management. Session Manager is a tool for managing and tracking sessions on EC2 instances, but it does not provide a mechanism for storing and managing session data in a distributed environment.

better justification found here... https://www.examtopics.com/discussions/amazon/view/46412-exam-aws-certified-solutions-architect-associate-saa-c02/

why not C?

ALB sticky session can keep request accessing to the same backend application. But it says "distributed session management" and company "will to change code", so I think A is better