AWS Certified SysOps Administrator - Associate Questions and Answers (Dumps and Practice Questions)

Question : HadoopExam Inc is planning to set up the Multi AZ feature of RDS. Which of the below mentioned conditions won't take advantage of the Multi AZ feature?

1. Availability zone outage
2. A manual failover of the DB instance using Reboot with failover option
3. Region outage
4. When the user changes the DB instance's server type

Correct Answer : 3

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. Benefits
Enhanced Durability : Multi-AZ deployments for the MySQL, Oracle, and PostgreSQL engines utilize synchronous physical replication to keep data on the standby up-to-date with the
primary. Multi-AZ deployments for the SQL Server engine use synchronous logical replication to achieve the same result, employing SQL Server-native Mirroring technology. Both
approaches safeguard your data in the event of a DB Instance failure or loss of an Availability Zone.

If a storage volume on your primary fails in a Multi-AZ deployment, Amazon RDS automatically initiates a failover to the up-to-date standby. Compare this to a Single-AZ deployment:
in case of a Single-AZ database failure, a user-initiated point-in-time-restore operation will be required. This operation can take several hours to complete, and any data updates
that occurred after the latest restorable time (typically within the last five minutes) will not be available.
Amazon Aurora employes an SSD-backed virtualized storage layer purpose-built for database workloads. Amazon Aurora Replicas serve as failover targets and share the same underlying
storage as the source instance, lowering costs and avoiding the need to copy data to the replica nodes.
Increased Availability : You also benefit from enhanced database availability when running Multi-AZ deployments. If an Availability Zone failure or DB Instance failure occurs, your
availability impact is limited to the time automatic failover takes to complete: typically one to two minutes (see the RDS FAQ for details).
The availability benefits of Multi-AZ deployments also extend to planned maintenance and backups. In the case of system upgrades like OS patching or DB Instance scaling, these
operations are applied first on the standby, prior to the automatic failover. As a result, your availability impact is, again, only the time required for automatic failover to
complete. Unlike Single-AZ deployments, I/O activity is not suspended on your primary during backup for Multi-AZ deployments for the MySQL, Oracle, and PostgreSQL engines, because
the backup is taken from the standby. However, note that you may still experience elevated latencies for a few minutes during backups for Multi-AZ deployments. On instance failure in
Amazon Aurora deployments, Amazon RDS uses RDS Multi-AZ technology to automate failover to one of up to 15 Amazon Aurora Replicas you have created in any of three Availability Zones.
If no Amazon Aurora Replicas have been provisioned, in the case of a failure, Amazon RDS will attempt to create a new Amazon Aurora DB instance for you automatically.
No Administrative Intervention : DB Instance failover is fully automatic and requires no administrative intervention. Amazon RDS monitors the health of your primary and standby, and
initiates a failover automatically in response to a variety of failure conditions.
Failover conditions : Amazon RDS detects and automatically recovers from the most common failure scenarios for Multi-AZ deployments so that you can resume database operations as
quickly as possible without administrative intervention. Amazon RDS automatically performs a failover in the event of any of the following:
Loss of availability in primary Availability Zone, Loss of network connectivity to primary, Compute unit failure on primary , Storage failure on primary
Note: When operations such as DB Instance scaling or system upgrades like OS patching are initiated for Multi-AZ deployments, for enhanced availability, they are applied first on the
standby prior to an automatic failover. As a result, your availability impact is limited only to the time required for automatic failover to complete. Note that Amazon RDS Multi-AZ
deployments do not failover automatically in response to database operations such as long running queries, deadlocks or database corruption errors.Amazon RDS when enabled with Multi
AZ will handle failovers automatically. Thus, the user can resume database operations as quickly as possible without administrative intervention. The primary DB instance switches
over automatically to the standby replica if any of the following conditions occur:
An Availability Zone outage , The primary DB instance fails , The DB instance's server type is changed , The DB instance is undergoing software patching, manual failover of the DB
instance was initiated using Reboot with failover

Question : QuickTechie's Administrator has configured Auto Scaling with ELB. One of the instance health check returns the status as Impaired to Auto Scaling.
What will Auto Scaling do in this scenario?

1. Perform a health check until cool down before declaring that the instance has failed
2. Terminate the instance and launch a new instance
3. Notify the user using SNS for the failed state
4. Notify ELB to stop sending traffic to the impaired instance

Correct Answer : 2
Explanation: The Auto Scaling group determines the health state of each instance periodically by checking the results of the Amazon EC2 instance status checks. If the
instance status description shows any other state other than "running" or the system status description shows impaired, Auto Scaling considers the instance to be unhealthy. Thus, it
terminates the instance and launches a replacement.

Auto Scaling allows you to suspend and then resume one or more of the Auto Scaling processes in your Auto Scaling group. This can be very useful when you want to investigate a
configuration problem or other issue with your web application and then make changes to your application, without triggering the Auto Scaling process. There are two primary Auto
Scaling process types - Launch and Terminate. The Launch process creates a new EC2 instance for an Auto Scaling group, and the Terminate process removes an existing Amazon EC2
instance. The remaining Auto Scaling process types relate to specific Auto Scaling features: AddToLoadBalancer, AlarmNotification, AZRebalance, HealthCheck, ReplaceUnhealthy,
ScheduledActions

If you suspend Launch or Terminate, all other process types are affected to varying degrees. The following descriptions discuss how each process type is affected by a suspension of a
Launch or a Terminate process. The AddToLoadBalancer process type adds instances to the load balancer when the instances are launched. If you suspend this process, Auto Scaling
launches the instances but does not add them to the load balancer. If you resume the AddToLoadBalancer process, Auto Scaling also resumes adding new instances to the load balancer
when they are launched. However, Auto Scaling does not add running instances that were launched while the process was suspended; those instances must be added manually using the
RegisterInstancesWithLoadBalancer Elastic Load Balancing API action or the elb-register-instances-with-lb Elastic Load Balancing command. The AlarmNotification process type accepts
notifications from CloudWatch alarms that are associated with the Auto Scaling group. If you suspend the AlarmNotification process type, Auto Scaling does not automatically execute
scaling policies that would be triggered by alarms. Although the AlarmNotification process type is not directly affected by a suspension of Launch or Terminate, alarm notifications
are often used to signal that a change in the size of the Auto Scaling group is warranted. If you suspend Launch or Terminate process, Auto Scaling might not be able to implement the
alarm's associated policy.

The AZRebalance process type seeks to maintain a balanced number of instances across Availability Zones within a region. If you remove an Availability Zone from your Auto Scaling
group or an Availability Zone otherwise becomes unhealthy or unavailable, Auto Scaling launches new instances in an unaffected Availability Zone before terminating the unhealthy or
unavailable instances. When the unhealthy Availability Zone returns to a healthy state, Auto Scaling automatically redistributes the application instances evenly across all of the
designated Availability Zones. If you suspend the Launch process, the AZRebalance process neither launches new instances nor terminates existing instances. This is because the
AZRebalance process terminates existing instances only after launching the replacement instances. If you suspend the Terminate process, the AZRebalance process can cause your Auto
Scaling group to grow up to ten percent larger than the maximum size. This is because Auto Scaling allows groups to grow temporarily larger than the maximum size during rebalancing
activities. If Auto Scaling cannot terminate instances, your Auto Scaling group could remain up to ten percent larger than the maximum size until you resume the terminate process
type. The HealthCheck process type checks the health of the instances. Auto Scaling marks an instance as unhealthy if Amazon EC2 or Elastic Load Balancing informs Auto Scaling that
the instance is unhealthy. The HealthCheck process can override the health status of an instance that you set with SetInstanceHealth API action or the as-set-instance-health command.
The ReplaceUnhealthy process terminates instances that are marked as unhealthy and subsequently creates new instances to replace them. This process calls both of the primary process
type - first Terminate and then Launch.

Question : Acmeshell Coporation is using Cloudformation to launch an EC instance and then configure an application after the instance is launched.
The user wants the stack creation of ELB and AutoScaling to wait until the EC2 instance is launched and configured properly. How can the user configure this?

1. It is not possible that the stack creation will wait until one service is created and launched
2. The user can use the HoldCondition resource to wait for the creation of the other dependent resources
3. The user can use the DependentCondition resource to hold the creation of the other dependent resources
4. The user can use the WaitCondition resource to hold the creation of the other dependent resources

Correct Answer : 4

Explanation: For Amazon EC2 and Auto Scaling resources, we recommend that you use a CreationPolicy attribute instead of wait conditions. Add a CreationPolicy attribute to those resources
and use the cfn-signal helper script to signal when an instance has been successfully created.
You can use a wait condition for situations like the following:

To coordinate stack resource creation with configuration actions that are external to the stack creation

To track the status of a configuration process

For these situations, we recommend that you associate a CreationPolicy attribute with the wait condition so that you don't have to use a wait condition handle. For more information
and an example, see Creating Wait Conditions in a Template. If you use a CreationPolicy with a wait condition, do not specify any of the wait condition's properties.

Syntax

{
"Type" : "AWS::CloudFormation::WaitCondition",
"Properties" : {
"Count" : String,
"Handle" : String,
"Timeout" : String
}
}
AWS Cloudformation is an application management tool which provides application modelling, deployment, configuration, management and related activities. AWS CloudFormation provides a
WaitCondition resource which acts as a barrier and blocks the creation of other resources until a completion signal is received from an external source, such as a user application or
management system.

AWS Certified SysOps Administrator - Associate Questions and Answers (Dumps and Practice Questions)

Related Questions