Sec. 8: AWS Fundamentals: RDS + Aurora + ElastiCache

Amazon RDS supports the following databases, EXCEPT:

• MongoDB

• MySQL

• MariaDB

• Microsoft SQL Server

Answer explanation

RDS supports MySQL, PostgreSQL, MariaDB, Oracle, MS SQL Server, and Amazon Aurora.

You're planning for a new solution that requires a MySQL database that must be available even in case of a disaster in one of the Availability Zones. What should you use?

• Create Read Replicas

• Enable Encryption

• Enable Multi-AZ

Answer explanation

Multi-AZ helps when you plan a disaster recovery for an entire AZ going down. If you plan against an entire AWS Region going down, you should use backups and replication across AWS Regions.

We have an RDS database that struggles to keep up with the demand of requests from our website. Our million users mostly read news, and we don't post news very often. Which solution is NOT adapted to this problem?

• An ElastiCache Cluster

• RDS Multi-AZ

• RDS Read Replicas

Answer explanation

Be very careful with the way you read questions at the exam. Here, the question is asking which solution is NOT adapted to this problem. ElastiCache and RDS Read Replicas do indeed help with scaling reads.

You have set up read replicas on your RDS database, but users are complaining that upon updating their social media posts, they do not see their updated posts right away. What is a possible cause for this?

• There must be a bug in your application

• Read Replicas have Asynchronous Replication, therefore it's likely your users will only read Eventual Consistency

• You should have setup Multi-AZ instead

Which RDS (NOT Aurora) feature when used does not require you to change the SQL connection string?

• Read Replicas

• Multi-AZ

Answer explanation

Multi-AZ keeps the same connection string regardless of which database is up.

Read Replicas add new endpoints with their own DNS name. We need to change our application to reference them individually to balance the read load.

Your application running on a fleet of EC2 instances managed by an Auto Scaling Group behind an Application Load Balancer. Users have to constantly log back in and you don't want to enable Sticky Sessions on your ALB as you fear it will overload some EC2 instances. What should you do?

• Use your own custom Load Balancer on EC2 instances instead of using ALB

• Store session data in RDS

• Store session data in ElastiCache

• Store session data in a shared EBS volume

Answer explanation

Storing Session Data in ElastiCache is a common pattern to ensuring different EC2 instances can retrieve your user's state if needed.

An analytics application is currently performing its queries against your main production RDS database. These queries run at any time of the day and slow down the RDS database which impacts your users' experience. What should you do to improve the users' experience?

• Setup a Read Replica

• Setup Multi-AZ

• Run the analytics queries at night

Answer explanation

Read Replicas will help as your analytics application can now perform queries against it, and these queries won't impact the main production RDS database.

You are running an ElastiCache Redis cluster which you want to ensure it is high available. What should you do?

• Add Read Replicas

• Enable Multi-AZ

How can you enhance the security of your ElastiCache Redis Cluster by forcing users to enter a password when they connect?

• Use Redis Auth

• Use IAM Auth

• Use Security Groups

Your company has a production Node.js application that is using RDS MySQL 5.6 as its database. A new application programmed in Java will perform some heavy analytics workload to create a dashboard on a regular hourly basis. What is the most cost-effective solution you can implement to minimize disruption for the main application?

• Enable Multi-AZ for the RDS database and run the analytics workload on the standby database

• Create a Read Replica in a different AZ and run the analytics workload on the replica database

• Create a Read Replica in a different AZ and run the analytics workload on the source database