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.
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
C is the correct Option
1
0
C.
Elastic Beanstalk is good for dev and test environment, but not for production environment, so A is not correct. As explain here:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.RDS.html
At option D, all instances in the subnet can access RDS, while at option C, only specified instances in the new security group can access RDS. So C is the correct answer.
4
0
C is correct.
1.To decouple your database instance from your environment, you can run a database instance in Amazon Relational Database Service instead of running Amazon RDS instances in your Elastic Beanstalk environment .
2.If just adding a rule to your database’s security group that allows ingress from the autogenerated security group that Elastic Beanstalk attaches to your environment’s Auto Scaling group, it would be a problem when you attempt to terminate the environment, Elastic Beanstalk will be unable to delete the environment’s security group because the database’s security group is dependent on it.
2
0
C
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html
DB Security Groups
DB security groups are used with DB instances that are not in a VPC and on the EC2-Classic platform. Each DB security group rule enables a specific source to access a DB instance that is associated with that DB security group. The source can be a range of addresses (for example, 203.0.113.0/24), or an EC2 security group. When you specify an EC2 security group as the source, you allow incoming traffic from all EC2 instances that use that EC2 security group. DB security group rules apply to inbound traffic only; outbound traffic is not currently permitted for DB instances.
You don’t need to specify a destination port number when you create DB security group rules. The port number defined for the DB instance is used as the destination port number for all rules defined for the DB security group. DB security groups can be created using the Amazon RDS API actions or the Amazon RDS page of the AWS Management Console.
For more information about working with DB security groups, see Working with DB Security Groups (EC2-Classic Platform).
5
0
c
0
0