As per the AWS documentation it clearly states that the cloudformation stack will be rolled back. For more information on Cloudformation, please visit the link: https://aws.amazon.com/cloudformation/faqs/

An alarm has three possible states: OK—The metric is within the defined threshold ALARM—The metric is outside of the defined threshold INSUFFICIENT_DATA—The alarm has just started, the metric is not available, or not enough data is available for the metric to determine the alarm state Since the Ec2 instance was stopped and EBS volumes are no longer available, the alarms will not have enough information so the state of the alarm will be Insufficient Data. For more information on Cloudwatch alarms, please visit the link: http://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html

As per the AWS documentation, please find the below excerpts Option A is invalid because of the below documentation. Option B is invalid because of the below documentation. Option C is invalid because of the below documentation. For more information on ELB, please visit the link: http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-listener-config.html

From the AWS documentation on the Instance store lifecycle of an AMI. From here it is evident that there is no stage of ‘Define the AMI launch permissions’ For more information on Instance store EC2 volumes, please visit the URL: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-instance-store.html

If you see the AWS documentation for all possible SSL options in the below link you will see that SSL Protocols, SSL Ciphers and Server Order Preference are all part of the pre-defined policies. Only Client Order Preference is not present. For more information on Secure ELB, please visit the link: http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-policy-table.html

The pre-requite is to ensure to go to Preferences in AWS and ensure that “Receive Billing Alerts” is enabled. Only then will you be able to define Cloudwatch alarms on billing. For more information on Cloudwatch, please visit the link: https://aws.amazon.com/cloudwatch/

To discover the availability of your EC2 instances, a load balancer periodically sends pings, attempts connections, or sends requests to test the EC2 instances. These tests are called health checks. The status of the instances that are healthy at the time of the health check is InService. The status of any instances that are unhealthy at the time of the health check is OutOfService The load balancer checks the health of the registered instances using either the default health check configuration provided by Elastic Load Balancing or a health check configuration that you configure. When configuring the Autoscaling group, you can choose either the option of EC2 or ELB health checks. Since Ec2 instances are being marked as unhealthy by ELB but not being terminated by Autoscaling it means that the check from the Autoscaling side is wrongly configured.  For more information on ELB, please visit the below URL: https://aws.amazon.com/elasticloadbalancing/

To ensure that each end user request goes to the same EC2 instance as the session created, you need to enable stickiness at the ELB level To enable stickiness go to the ELB and in the port configuration section you can enable the stickiness. For more information on ELB, please visit the link: https://aws.amazon.com/elasticloadbalancing/

To increases instances proactively you need to increase the desired limit. Option B is wrong because the maximum limit will just to what maximum scale the instances can launch too, but will not launch them until a trigger occurs. Option C is wrong because this is not proactive measure by adding instances to an ELB. Option D is wrong because the minimum limit will just to what minimum scale the instances can terminate to, and does not look to launch new instances.  For more information on AutoScaling, please visit the link: https://aws.amazon.com/autoscaling/

You can set AWS bucket policy to make everything public. You can do via the following steps Step 1) Go to your S3 bucket and click on the Permissions section Step 2) Go to AWS Policy Generator Step 3) Add the S3 bucket policy to allow any Principal to access your bucket and choose the Actions accordingly. For more information on S3 Security please visit the link: http://docs.aws.amazon.com/AmazonS3/latest/dev/DataDurability.html

If you look at the documentation for AWS Glacier it clearly mentions that glacier can be used for offline administrative storage and is low cost. Amazon Glacier is an extremely low-cost storage service that provides secure, durable, and flexible storage for data backup and archival. With Amazon Glacier, customers can reliably store their data for as little as $0.004 per gigabyte per month. Amazon Glacier enables customers to offload the administrative burdens of operating and scaling storage to AWS, so that they don’t have to worry about capacity planning, hardware provisioning, data replication, hardware failure detection and repair, or time-consuming hardware migrations. Option A and B are wrong because they are used for real time storage. Option C is wrong because this is for database service. For more information on Glacier please visit the link: https://aws.amazon.com/glacier/details/

When you reboot your instance, as per the AWS documentation the following actions occur An instance reboot is equivalent to an operating system reboot. In most cases, it takes only a few minutes to reboot your instance. When you reboot an instance, it remains on the same physical host, so your instance keeps its public DNS name (IPv4), private IPv4 address, IPv6 address (if applicable), and any data on its instance store volumes. From the above explanation it is pretty straightforward to understand that Option D is the right option. For more information on rebooting instance, please visit the link: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-reboot.html

AWS Doc shows the options of an Autoscaling group. In the Suspended processes you can see the different processes for Autoscaling. Here you can see that there are processes for Schedule Actions, Replace unhealthy and AZ Rebalance. But no Reboot Instance, Hence Option A is the right answer. For more information on Autoscaling , please visit the URL: https://aws.amazon.com/autoscaling/

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.  And as per the AWS documentation, the cname is changed to the standby DB when the primary one fails. For more information on Multi-AZ RDS, please visit the link: https://aws.amazon.com/rds/details/multi-az/

Automated backups automatically back up your DB instance during a specific, user-definable backup window. Amazon RDS keeps these backups for a limited period that you can specify. You can later recover your database to any point in time during this backup retention period. And all of these backups get stored to S3 by default.The backup retention period is present as a setting when you setup the RDS in AWS.  Option A and C are wrong because If the table is deleted the Multi-AZ and Read Replica will also have the same dropped tables because the synchronization would have already happened. Option B is wrong because snapshots is a manual process. For more information on Automated backups, please visit URL: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html