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 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.

B.
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.
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.

D.
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.

Explanation:
Elastic Beanstalk provides support for running Amazon RDS instances in your Elastic Beanstalk
environment. This works great for development and testing environments, but is not ideal for a
production environment because it ties the lifecycle of the database instance to the lifecycle of
your application’s environment.
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.RDS.html