2.1 - Scalability and high availability

1. A CloudWatch alarm monitors StatusCheckFailed_System for an EC2 instance. Which alarm action moves the instance to healthy hardware while keeping its instance ID and IP?

• The EC2 recover action (correct answer)
• The EC2 terminate action followed by an Auto Scaling replacement
• The EC2 stop action, which powers the instance down until the morning
• A reboot action that reinstalls the guest operating system first

The recover action migrates the instance to new underlying hardware while preserving instance ID, private IP, Elastic IP, and metadata, ideal for system status check failures. Terminate/replace would change the identity.

2. You get paged every time either CPU or memory briefly spikes, causing alert fatigue. You only want a page when BOTH are high at the same time. What should you configure?

• A composite alarm combining both alarms with AND logic (correct answer)
• A single metric math alarm that adds the two unrelated metrics together
• Two separate SNS topics that subscribers must correlate by hand each time
• A high-resolution alarm evaluated every second on each metric

A composite alarm combines existing alarm states with a rule (ALARM(cpu) AND ALARM(mem)), so it fires only when both are breaching, cutting noise. Adding unrelated metrics with math is not meaningful.

3. An application hangs occasionally, failing the instance status check while the hardware stays healthy. Which alarm action restarts the same instance in place?

• The EC2 reboot action (correct answer)
• The EC2 recover action, which migrates it to new underlying hardware
• The terminate action wired to a replacement launch template
• The stop action, leaving the instance off until an operator returns

A reboot action restarts the same instance in place, clearing a hung guest OS while hardware is fine (an instance status check failure). Recover is for system (hardware) failures, not a guest-side hang.

4. An Auto Scaling group is set to min 2, desired 4, max 8. A scaling policy tries to add 6 instances at once. How many instances will actually run?

• 10, because desired plus the requested six
• 8, because the maximum caps the group (correct answer)
• 6, only the newly requested instances
• 4, the desired capacity never changes

Desired capacity can grow but is clamped by max, so 4 + 6 would reach 10 yet stops at 8. The group never launches below min or above max regardless of policy requests.

5. You run workloads in three Regions and want a single Region's log group to receive events from all of them for BC dashboards. What enables this?

• Manually export each Region's logs to S3 and re-import them by hand
• Enable detailed monitoring, which replicates log groups across Regions
• Subscription filters feeding a cross-Region Kinesis Data Firehose stream (correct answer)
• Nothing, because CloudWatch Logs cannot leave the Region they are created in

Subscription filters can push events to a Kinesis Data Firehose (or Data Stream) in another Region, centralizing logs for cross-Region aggregation. Detailed monitoring does not replicate logs, and manual S3 round-trips are not near real time; logs can leave their Region via these pipelines.

6. A central security account must ingest logs from 40 member accounts continuously. Which pattern is most reliable?

• Have each account email its exported log files to the security team weekly
• Cross-account subscription filters delivering to a central Firehose or Kinesis (correct answer)
• Grant the security team read access and let analysts copy logs by hand daily
• Turn on detailed monitoring in every member account to sync their log groups

Cross-account subscription filters to a central Kinesis Data Stream or Firehose give a continuous, automated, reliable aggregation pipeline. Emailing files, manual copying, and detailed monitoring are not real-time centralized logging solutions.