A 3-tier e-commerce web application is current deployed on-premises and will be migrated to AWS for greater
scalability and elasticity The web server currently shares read-only data using a network distributed file system
The app server tier uses a clustering mechanism for discovery and shared session state that depends on IP
multicast The database tier uses shared-storage clustering to provide database fall over capability, and uses
several read slaves for scaling Data on all servers and the distributed file system directory is backed up weekly
to off-site tapes
Which AWS storage and database architecture meets the requirements of the application?
A.
Web servers, store read-only data in S3, and copy from S3 to root volume at boot time App servers snare
state using a combination or DynamoDB and IP unicast Database use RDS with multi-AZ deployment and one
or more Read Replicas Backup web and app servers backed up weekly via Mils database backed up via DB
snapshots.
B.
Web servers store -read-only data in S3, and copy from S3 to root volume at boot time App servers share
state using a combination of DynamoDB and IP unicast Database, use RDS with multi-AZ deployment and one
or more read replicas Backup web servers app servers, and database backed up weekly to Glacier using
snapshots.
C.
Web servers store read-only data In S3 and copy from S3 to root volume at boot time App servers share
state using a combination of DynamoDB and IP unicast Database use RDS with multi-AZ deployment Backup
web and app servers backed up weekly via AM is. database backed up via DB snapshots
D.
Web servers, store read-only data in an EC2 NFS server, mount to each web server at boot time App servers
share state using a combination of DynamoDB and IP multicast Database use RDS with multl-AZ deployment
and one or more Read Replicas Backup web and app servers backed up weekly via Mils database backed up via
DB snapshots
I understand last part which is backing up to Glacier could be the main reason for selecting C.
Why not leave the data on S3 and use it as a static Webserver instead of copying the static data to root during boot? There could be gigabytes of static data that would increase the boot time significantly and having in case of webserver failure.
0
0
James it has to be B, in option C you have lost the read replicas.
As far as you mention about S3 I agree. Even better this is ready only and static then why bother to spin EC2 for that, you can just distribute via cloud front using S3 bucket as origin. Save the money and light weight highley scalable.
0
0
seems answer b
0
0
Whilst B seems like the obvious choice, it is incorrect. You cannot backup to Glacier using snapshots.
C does not fulfill the read replica requirements.
D seems like it would be incorrect to use EC2 with NFS over S3.
Which leaves A as the correct answer. It fulfills all requirements.
1
0
answer is
Web servers: store read-only data in S3, and copy from S3 to root volume at boot time. App servers:share state using a combination of DynamoDB and IP unicast. Database: use RDS with multi-AZ deployment and one or more Read Replicas. Backup: web and app servers backed up weekly via AMIs,database backed up via DB snapshots.
Here is my explanation
Amazon RDS Multi-AZ deployments provide enhanced availability and durability for Database (DB) Instances, making them a natural fit for production database workloads. When you provision a Multi-AZ DB Instance, Amazon RDS automatically creates a primary DB Instance and synchronously replicates the data to a standby instance in a different Availability Zone (AZ). Each AZ runs on its own physically distinct, independent infrastructure, and is engineered to be highly reliable. In case of an infrastructure failure (for example, instance hardware failure, storage failure, or network disruption), Amazon RDS performs an automatic failover to the standby, so that you can resume database operations as soon as the failover is complete. Since the endpoint for your DB Instance remains the same after a failover, your
application can resume database operation without the need for manual administrative intervention.
2
0
your answer is c? or a?
0
0
Answer is B,
database backup can be taken into Glacier, moreover the question points to offsite backup solution. So I thin B is the idle choice here.
0
0
sorry wrong answer A will be correct
snapshots cant be back up in glacier
http://superuser.com/questions/555929/moving-ebs-snapshots-to-glacier
0
0
Answer is A
Source:
https://d0.awsstatic.com/whitepapers/Storage/AWS%20Storage%20Services%20Whitepaper-v9.pdf
Amazon Glacier doesn’t suit all storage situations. Listed following are a few
storage needs for which you should consider other AWS storage options instead
of Amazon Glacier.
Data that must be updated very frequently might be better served by a storage solution with lower read/write latencies, such as Amazon EBS, Amazon RDS, Amazon DynamoDB, or relational databases running on EC2.
0
0
C doesn’t work because it misses DB read replicas.
B has a problem that you can’t backup EBS snapshots to Glacier.
A is the right answer.
2
0
A doesn’t do full fill requirement of backed up weekly
to off-site tapes.
As the database tier uses shared-storage clustering to provide database fall over capability, that means the Database is not on EBS volume and it’s using NFS or some other distributed file system. So the answer should be D.
0
0
What is the purpose of coping read-only data from S3 to EC2’s root volume? It looks like this methodology is very redundant, cumbersome, and time cosuming.
1
0
The app was written to work on a file system. S3 is an object store that can structure keys to look like a file system. If the app wants to read a directory file, there is actually no such file in S3. The app would instead need to be able to parse the key to understand data hierarchy (which is really just flat in S3).
Instead of changing the app, they are giving it what it expects. Also, presumably, the data in S3 has to change at some time (e.g. maybe it is created monthly by another application. Or maybe it changes with new releases of the software). This allows you to use S3 as the master data and not have to maintain data in multiple locations.
0
0
B: can’t directly backup EBS snapshots to Glacier.
C: misses DB read replicas
D: AWS does not support IP Multicast.
Thus, A is the right answer.
4
0
The answer is B
Because the backup software is AWS-aware, it will back up the
data from the on-premises servers directly to Amazon S3 or Amazon Glacier.
0
0
Very poorly worded answers again ..
A is right on its own but it doesnt meet the requirement to back up to tape unless you assume there will be a lifecycle policy to move S3 data to glacier (which has a 30 day min so cant be weekly)
B is wrong on its own but you could i suppose assume there is an intermediary step between the S3 backup and the move to Glacier
So i’d have to say A but dont like it !
1
0
Go with B for this one, it’s not completely worded but this is the case for most of the answers.
0
0
A is the right answer fully agree with Blah.
James raised an interesting point why copy to WebServer at boot time instead why not serve from S3?
Ans: To save cost, S3 is charged based on PUT/GET request apart from the bandwdith , instead you copy it to root volume once every time a machine boots and serve from EC2.
0
0
Backup via Mils? What is Mils? If this is a typo, would someone care to translate?
0
0
Mils = AMIs
0
0
A
0
0
Answer is A
0
0
Answer is A
Most of the answers at the top are wrong. I’ve gone through the trouble of correcting all 400 of them for my own study purposes. If you would like a digital copy of this dump please send $40 to paypal.me/lyannabear
0
0
are you sure this is an associate question? looks like a professional exam questuion to me
0
0