Handle a Health API access error — AWS Health and CloudWatch

Your goal

Investigate a Health API access error and configure a separate application heartbeat alarm.

Why this matters

An access error must not be mistaken for an empty health report. You will inspect the emulator’s restricted Health response and configure a separate application alarm. These are different sources of operational information.

Words you will use

A health event reports a service issue or change. An access error means the request was not allowed. A heartbeat is a regular signal from an app. An alarm on that signal is separate from AWS service health.

How to proceed

Start a fresh emulator, read each numbered step, and enter the practice settings shown. Run the action, inspect its API receipt, then continue. Finish lab checks the emulator state again before saving your progress.

1. Make a Health API request

Request recent Health events and inspect the real SubscriptionRequiredException returned by this emulator. This is an expected teaching error. It means access is restricted, not that there are no service incidents.

2. Set up a separate application check

Create a disabled-action alarm for a practice Heartbeat metric. It would compare the count with one per minute. This app check is separate from AWS service health and does not replace the unavailable Health report.

3. Inspect the alarm and explain its scope

Read the alarm’s stored metric and threshold. You have handled a real API access error and configured an application check. You have not retrieved live AWS status, generated an incident, or measured this website’s uptime.

Practice, then check your understanding

Perform the actions yourself and inspect the returned state. Errors keep your settings so you can retry. Starting another lab clears the previous live environment. Earned XP is kept, and signed-in achievements sync to your account. Replay does not award duplicate XP.

Read the official AWS documentation for service behavior and production details.