Your team has a tomcat-based Java application you need to deploy into development, test and production
environments. After some research, you opt to use Elastic Beanstalk due to its tight integration with your
developer tools and RDS due to its ease of management. Your QA team lead points out that you need to roll a
sanitized set of production data into your environment on a nightly basis. Similarly, other software teams in your
org want access to that same restored data via their EC2 instances in your VPC.
The optimal setup for persistence and security that meets the above requirements would be the following.
A.
Create your RDS instance as part of your Elastic Beanstalk definition and alter its security group to allow
access to it from hosts in your application subnets.
B.
Create your RDS instance separately and add its IP address to your application’s DB connection strings in
your code Alter its security group to allow access to it from hosts within your VPC’s IP address block.
C.
Create your RDS instance separately and pass its DNS name to your app’s DB connection string as an
environment variable. Create a security group for client machines and add it as a valid source for DB traffic
to the security group of the RDS instance itself.
D.
Create your RDS instance separately and pass its DNS name to your’s DB connection string as an
environment variable Alter its security group to allow access to It from hosts in your application subnets.
C: is the right answer.
A: is an example for bad practice! If you rebuild your Beanstalk, the Database will also rebuild. WTF is with the Data in it?
D is the answer coz allowing subnet will be easy instead of allowing individual hosts
sorry C is the answer
C