Which three services could you use to achieve this?

D: At this level they are looking to see if you know what stateless means and which AWS services will help you.

Do some research in to state-full and state-less, but basically you want your main customer facing components to be disposable without causing impact to customers. That means that you need to not store data on the web / app servers, and deal only with transactions. As mike said, the old model was to store information about the user, and what they were doing, (shopping list, screen colour, current data feeds being processed, on the web / app server. If that server went down or had to be taken down the session and all the work to date would be lost because no other server in the fleet was aware , or could access it..

In a stateless world we store that information where it can be retrieved by the next web/app server to pick up the session, and the user is unaware that they have moved hosts.

Now this session data needs to be able to be retrieved fast, and be resilient. So consider what services that AWS provide that provide fast access to data , is resilient to the app design (could be seconds or could be days).

Elasticache is fast, but has limited durability and limited volume capacity (in Bytes of cache).

DynamoDB is fast but not as fast, but has good durability, and good volume capacity (MB – GB)

RDS is slow, but has excellent durability and capacity. But if combined with Elasticache can be a good result.

Which is best will depend in the use case.

There is good information in the AWS documentation. Dig it out and have a read. It should take you less than an hour to figure out the key aspects.

I suggest that you start with the white papers on architecture best practice, and storage.

we can store session information in ElastiCache and other data in RDS and use ELB for load balancing , what is the wrong in it? we can go for REdis if we need persistence