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.
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
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.
1
0
Above document part you mentioned said that it is not ideal for production so why not choose option D ?
0
1
c
https://acloud.guru/course/aws-certified-solutions-architect-associate/discuss/-KOGCEbhvIg8JmpacOy8/need-help-with-a-question
2
0
Key word is consistency- Java application… Keyword would be elastic beanstalk
1
0
Agree with Chef
2
0
It can’t be A as explained here: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.RDS.html
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.
It can’t be D because RDS is opened to all “hosts in your application subnets” where C only opens RDS to specific client machines in a specific security group.
C is the correct answer.
4
1
C is the correct,
Security group allows instances to access the RDS with new instances launched without any changes
1
1
C
1
1
C
1
1
Obviously it’s between C and D, but I’m reading the key indicators for D just a touch differently than others, specifically 1) the alter vs create verbs in C vs D, 2) evidence from documentation around subnet access and alter/create verbs, and finally 3) EBS’s core asset is its application focus, which means EBS can scale your application without your direct involvement or if you have selected a specific EBS deploy type then it requires new instances every deploy so adding client IPs is way too inflexible for a production environment. It should be secure to allow a subnet that ONLY has application instances that ALL need access to RDS while maintaining your production environment’s flexibility.
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.RDS.html#rds-external-defaultvpc
Title: EBS: Launching and Connecting to an External RDS Instance in a Default VPC
“The only additional requirements are that your environment and DB instance are in the same subnet, or in subnets that are allowed to communicate with each other.”
…
“Next, modify the security group attached to your DB instance to allow inbound traffic on the appropriate port. This is the same security group that you will attach to your Elastic Beanstalk environment later, so the rule that you add will grant ingress permission to other resources in the same security group.”
My take aways are:
1) The EBS environment MUST be in the same subnet or a subnet that can communicate with the external RDS. Thus, the application subnet is okay to talk to RDS, but “A” subnet is certainly required. Also, if the application has its own subnet with nothing else in it then you want everything on that subnet to be able to talk to your RDS instance as instances come up and down with application deploys potentially or scaling events. EBS’s default deploy is rolling, which uses existing instances, but what if EBS scales your app or you have chosen a different deploy mechanism? see link:(http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.deploy-existing-version.html)
2) You will Modify/Alter the security group attached to your DB instance and NOT “Create” a new one.
Answer: D
All of this makes me think D is the answer not C. I’m open to other interpretations or detailed readings of the link/s I have provided or other relevant links.
1
0
C ; security wise, opening to specific clients is better than to the entire subnet. Also separate security group provides for better management and tracking.
1
1