2.2 - Backup, restore, and disaster recovery

1. How does an Auto Scaling group typically add instances in response to sustained high CPU?

• A CloudWatch alarm triggers a scaling policy on the group (correct answer)
• The group polls each instance's guest OS directly every few seconds for load
• CloudWatch reboots the busiest instance to shed some of its load
• The group doubles capacity on a fixed hourly schedule regardless of CPU

A CloudWatch alarm on a metric like CPUUtilization invokes a scaling policy, which tells the Auto Scaling group to launch instances. Scheduled scaling exists but is time-based, not a response to CPU.

2. Which CloudWatch metric indicates that AWS-side infrastructure (host hardware or network) supporting your EC2 instance has failed?

• StatusCheckFailed_System (correct answer)
• StatusCheckFailed_Instance, which reflects guest OS and configuration problems
• CPUUtilization crossing a static threshold value
• NetworkPacketsIn dropping to zero for a while

StatusCheckFailed_System reports failures in the AWS-managed infrastructure and is what a recover action responds to. StatusCheckFailed_Instance reflects guest-side problems you must fix (a reboot often helps).

3. Compliance requires keeping seven years of logs cheaply for possible audits. What is the recommended long-term store?

• Export the log group to Amazon S3 and apply lifecycle to Glacier (correct answer)
• Raise the CloudWatch Logs retention to the maximum and leave it there
• Copy each log stream into a second CloudWatch Logs group as a backup
• Keep the logs live in CloudWatch Logs and rely on cross-Region copies for durability

Exporting to S3 with lifecycle transitions to Glacier is the cheap, durable archive for multi-year retention. CloudWatch Logs storage is pricier for cold data, and duplicating streams or relying on live logs is neither cheap nor an archive strategy.

4. For DR readiness, which single setting on a log group most directly controls how far back events survive?

• The KMS key attached to the log group for encryption at rest
• The subscription filter pattern that decides which events stream out
• The retention setting, which defines the age at which events expire (correct answer)
• The metric filter, which determines which log lines are counted as metrics

Retention directly sets how many days events are kept before deletion, the key control for how far back DR investigations can look. KMS handles encryption, subscription filters route data, and metric filters create metrics, none of which govern event age.

5. On your operations dashboard you want each alarm's red/green state visible next to its graph. What do you add?

• A metric stream feeding the dashboard in real time
• A Contributor Insights widget listing top talkers
• An alarm status widget on the dashboard (correct answer)
• A separate SNS topic for every displayed alarm

CloudWatch dashboards include an alarm status widget that shows each alarm's OK/ALARM state alongside graphs. A metric stream exports data, Contributor Insights ranks contributors, and adding SNS topics sends notifications without displaying state on the dashboard.

6. You want a single 'service unhealthy' alarm that fires only if BOTH latency and error alarms are in ALARM. Which two facts apply? (Choose TWO.)

• You must merge the two metrics into one custom metric first
• A composite alarm combines child alarms with a rule (correct answer)
• The rule uses AND so both children must be in ALARM (correct answer)
• Composite alarms cannot notify through an SNS topic

A composite alarm evaluates a rule over existing child alarms, and an AND rule fires only when both children are in ALARM, reducing noise. You do not need to merge metrics, and composite alarms can absolutely notify via SNS.