Preserving Test Results for AWS CloudFormation Load Testing Stack
Question
A gaming company adopted AWS Cloud Formation to automate load-testing of their games.
They have created an AWS Cloud Formation template for each gaming environment, including one for the load-testing stack.
The load-testing stack creates an Amazon Relational Database Service (RDS) Postgres database and two web servers running on Amazon Elastic Compute Cloud (EC2) that send HTTP requests, measure response times, and write the results into the database.
A test run usually takes between 15 and 30 minutes.
Once the tests are done, the AWS Cloud Formation stacks are torn down immediately.
The test results written to the Amazon RDS database must be preserved for visualization and analysis.
Select possible solutions that allow access to the test results after the AWS Cloud Formation load -testing stack is deleted.
(Select TWO)
Answers
Explanations
Click on the arrows to vote for the correct answer
A. B. C. D. E.Answer - C and D.
Option A is incorrect because (a) the creation of read replicas is not needed in this scenario, and (b) they would anyways be deleted after the stacks get deleted.
So there is no need to define any dependency in the template.
Option B is incorrect because the UpdatePolicy attribute is only applicable to certain resources like AutoScalingGroup, AWS Lambda Alias.
It does not apply to RDS.
Option C is CORRECT because the RDS resources would be preserved for the visualization and analysis after the stack gets deleted with the Retain deletion policy.
Option D is CORRECT because, with the Snapshot deletion policy, a snapshot of the RDS instance would be created for visualization and analysis later after the stack is deleted.
Option E is incorrect because automated snapshots are not needed in this case.
All that is needed is a single snapshot of the RDS instance after the test is finished, which can be taken via the Snapshot deletion policy.
NOTE: This question is asking for two possible answers.
It does not say that both need to be used at the same time.
Hence both C and D are valid options.
For more information on deletion policy, please visit the below URL-
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-attribute-deletionpolicy.htmlSure, I'll provide a detailed explanation for each of the possible solutions that allow access to the test results after the AWS Cloud Formation load-testing stack is deleted.
A. Define an Amazon RDS Read-Replica in the load-testing AWS CloudFormation stack and define a dependency relation between master and replica via the DependsOn attribute. This solution involves creating a read-replica of the RDS Postgres database in the load-testing AWS CloudFormation stack. A read-replica is a copy of the database that can be used for read operations. By defining a dependency relation between the master and replica databases using the DependsOn attribute, the replica database will be created before the master database, and any read operations performed on the replica will be consistent with the master. This solution allows for access to the test results after the AWS CloudFormation stack is deleted because the read-replica database will still exist and can be used to query the test results.
B. Define an update policy to prevent the deletion of the Amazon RDS database after the AWS CloudFormation stack is deleted. This solution involves defining an update policy in the AWS CloudFormation stack to prevent the deletion of the RDS Postgres database after the stack is deleted. This will ensure that the database is not deleted inadvertently and that the test results are preserved. However, it's important to note that this solution does not guarantee access to the test results after the AWS CloudFormation stack is deleted.
C. Define a deletion policy of type Retain for the Amazon RDS resource to assure that the RDS database is not deleted with the AWS CloudFormation stack. This solution involves defining a deletion policy of type Retain for the RDS Postgres database in the AWS CloudFormation stack. This will ensure that the database is not deleted when the stack is deleted, and the test results are preserved. However, it's important to note that this solution does not guarantee access to the test results after the AWS CloudFormation stack is deleted.
D. Define a deletion policy of type Snapshot for the Amazon RDS resource to assure that the RDS database can be restored after the AWS CloudFormation stack is deleted. This solution involves defining a deletion policy of type Snapshot for the RDS Postgres database in the AWS CloudFormation stack. This will create a snapshot of the database before it's deleted with the stack. The snapshot can then be used to restore the database, including the test results, after the stack is deleted. This solution guarantees access to the test results after the AWS CloudFormation stack is deleted.
E. Define automated backups with a backup retention period of 30 days for the Amazon RDS database and perform point-in-time recovery of the database after the AWS CloudFormation stack is deleted. This solution involves defining automated backups for the RDS Postgres database in the AWS CloudFormation stack with a backup retention period of 30 days. This will create backups of the database at regular intervals, including the test results. After the AWS CloudFormation stack is deleted, point-in-time recovery can be performed to restore the database to a specific point in time, including the test results. This solution guarantees access to the test results after the AWS CloudFormation stack is deleted.
In conclusion, the possible solutions that allow access to the test results after the AWS Cloud Formation load-testing stack is deleted are A and D. Solution A involves creating a read-replica of the RDS Postgres database, while solution D involves defining a deletion policy of type Snapshot for the RDS Postgres database. Both solutions guarantee access to the test results after the AWS CloudFormation stack is deleted.
