Custom metrics, alarms and health checks: DVA-C03 study notes and practice questions
What to know about Custom metrics, alarms and health checks for the DVA-C03 exam, from the Troubleshooting and Optimization domain (22% of the exam guide), then 4 free questions to test it. Part of the DVA-C03 study guide.
These questions ask how an application publishes its own numbers, how an alarm decides to fire, and how the team learns that something is unhealthy.
Custom metrics
Embedded metric format (EMF): the application writes a JSON log event with an _aws object that lists the namespace, dimensions and metrics. CloudWatch Logs extracts the metrics from the log, with no API call per invocation. This suits Lambda and code that cannot change much.
PutMetricData: a direct API call. Each call costs money and needs cloudwatch:PutMetricData permission. Batch values where possible.
Each dimension set creates a separate metric, so keep high-cardinality values such as request IDs out of dimensions.
Set StorageResolution to 1 for high-resolution metrics. The default is 60 seconds.
Alarms and notifications
An alarm watches one metric, or a metric math expression such as an error percentage.
Evaluation periods and datapoints to alarm control sensitivity. One period of one minute pages on every spike.
Missing data: a heartbeat alarm that should fire when a job stops needs missing data treated as breaching. Otherwise, no data can leave the alarm in its previous state.
Dimensions must match the metric exactly. An alarm that names only some dimensions watches nothing.
Alarm actions publish to SNS. If the topic is encrypted with a customer managed KMS key, the key policy must let CloudWatch use it.
Composite alarms combine alarms, such as “latency and 5xx both breached”, so one incident sends one page.
Quota limits: Service Quotas publishes usage metrics in the AWS/Usage namespace for supported quotas. An alarm set below the limit warns before you hit it.
Deployment completions:EventBridge receives CodeDeploy and CodePipeline state-change events. Route them to SNS or Lambda.
Health checks
ALB target groups: health checks mark targets healthy or unhealthy, and the load balancer routes only to healthy targets.
ECS: container health checks run a command inside the container. Load balancer health checks are separate.
EKS: liveness probes restart a container that has stopped responding. Readiness probes stop traffic until a container is ready.
CloudWatch Synthetics canaries: scripts that call an endpoint on a schedule and raise alarms. They test from outside the application, so they catch failures that internal metrics miss.
How to choose
Scenario wording
Answer
“publish a metric without a call per invocation”
Embedded metric format
“alarm when the job stops reporting”
Missing data treated as breaching
“one page when two conditions both hold”
Composite alarm
“warn before reaching a service quota”
Alarm on the AWS/Usage metric
“notify when a deployment finishes”
EventBridge rule to SNS
“stop routing to unhealthy containers”
ALB target group or ECS health check
Common traps
One-minute, one-period alarms on noisy metrics.
Dimension mismatch between the published metric and the alarm.
Encrypted SNS topics without a key policy that allows CloudWatch.
Readiness for restarts: a liveness probe restarts, a readiness probe only removes traffic.
A Lambda function processes orders and must report a custom metric for each order's value, with one dimension, region.
The team does not want a PutMetricData call in every invocation, and the function's role should not need cloudwatch:PutMetricData. The per-order detail must also stay searchable in Logs Insights.
What should the developer do?
Choose one answer.
AA. Start a background thread at the end of each invocation that calls PutMetricData with the order value.
BB. Create a metric filter on the log group that counts log lines containing the word order.
CC. Write each order as a JSON log event in embedded metric format, with region as a dimension.
DD. Turn on Lambda Insights, which adds the order value to the function's built-in metrics.
Show the answer and explanation
Answer: C
A. Wrong: The thread still calls PutMetricData, so the role still needs that permission and the per-invocation API call remains.
B. Wrong: A metric filter on lines containing a word counts those lines. It does not publish each order's value as a metric with a region dimension.
C. Right: Correct. The embedded metric format puts the metric in a structured log event, and CloudWatch extracts it. The function needs logs:PutLogEvents rather than PutMetricData, and the event stays in the log for Logs Insights. Learn more: Embedding metrics within logs (opens in a new tab)
D. Wrong: Lambda Insights reports system-level metrics such as memory and CPU use. It does not turn application values, such as an order total, into custom metrics.
Explanation
The embedded metric format lets code write metrics inside structured log events, and CloudWatch Logs extracts them without a PutMetricData call. The detailed events remain searchable. Dimensions with many unique values, such as an order ID, create a separate metric for each value, so the dimension should be low-cardinality like region.
An application publishes a custom metric named QueueLagSeconds with PutMetricData.
Operations want an alarm that evaluates the metric every 10 seconds, so that spikes are caught quickly.
The team accepts a higher charge for this one alarm, but it must keep the same metric and dimensions, and the alarm must reflect the queue's current lag.
Choose one answer.
AA. Publish the metric as a high-resolution metric, then create an alarm with a 10-second period.
BB. Keep the standard-resolution metric and create an alarm with a 10-second period.
CC. Enable detailed monitoring on the instances that publish the metric.
DD. Publish the same standard-resolution metric once per second, so that each alarm period has fresh data.
Show the answer and explanation
Answer: A
A. Right: Correct. Only high-resolution metrics, stored at one-second granularity, can drive alarms with 10- or 30-second periods. Each such alarm costs more, which the team has accepted. Learn more: Publishing custom metrics (opens in a new tab)
B. Wrong: A standard-resolution metric has one-minute granularity, and a 10-second alarm period is not available for it. The alarm cannot evaluate every 10 seconds.
C. Wrong: Detailed monitoring applies to the instances' built-in metrics, not to a custom metric the application publishes. It does not change the granularity of QueueLagSeconds.
D. Wrong: Publishing more often does not change a standard metric's one-minute granularity, so the alarm period still cannot be 10 seconds.
Explanation
Custom metrics are standard resolution by default. Publishing them as high resolution stores them at one-second granularity, and only then can an alarm use a 10-second or 30-second period. Publishing more often or changing instance monitoring does not change this.
A payments API runs as an Amazon ECS service on AWS Fargate, behind an Application Load Balancer. Its tasks are slow to start, because the application needs about 60 seconds to load its cache before it can answer requests.
When a task stops responding, the team wants ECS to replace it automatically. The application has a /health endpoint that returns an error when its database connection is down.
Which configuration meets these requirements without replacing healthy tasks while they start?
Choose one answer.
AA. Set the service's health check grace period to 120 seconds, and point the target group health check at /health. ECS stops and replaces tasks that fail the load balancer check after the grace period.
BB. Point the target group health check at the root path on port 80 with a 2-second timeout, and set no grace period, so each new task is checked as soon as it starts.
CC. Create a CloudWatch alarm on the target group's 5xx count that notifies an operator, who then stops any task that returns errors.
DD. Set the service's minimum healthy percent to 100 and maximum percent to 200, so ECS starts each replacement task before it stops the old one.
Show the answer and explanation
Answer: A
A. Right: Correct. The grace period tells the ECS service scheduler to ignore load balancer health check failures while a new task loads its cache. After that, a failing target group check on /health makes the scheduler replace a task that stops responding or loses its database connection. Learn more: Amazon ECS service definition parameters (opens in a new tab)
B. Wrong: New tasks are checked before the cache loads, so they fail and are replaced again and again. The root path also does not reflect the database connection that the team wants checked.
C. Wrong: An alarm only notifies, so a person must stop each task, which breaks the automatic replacement the team wants. It also reacts to errors in total rather than to the health of each task.
D. Wrong: These settings control how many tasks run while tasks are replaced. They do not decide when a task is unhealthy, and they do not stop new tasks from failing health checks while they load the cache.
Explanation
The ECS service scheduler replaces tasks that fail the load balancer target group health check, and /health makes that check reflect the database connection. The health check grace period keeps the scheduler from judging a slow-starting task too early. Together they replace unhealthy tasks automatically without churning new ones during startup.
A platform team deploys its services with AWS CodeDeploy. The on-call channel must hear about every deployment that finishes, whether it succeeds or fails, within a minute of the change.
The team does not want to change its deployment scripts or run a polling job that calls the CodeDeploy API every minute. The alerts go to an Amazon SNS topic that already posts to the channel.
Which solution meets these requirements?
Choose one answer.
AA. Add a step to each deployment script that publishes to the SNS topic when the script exits, with the result of the script.
BB. Run an AWS Lambda function every minute that calls the CodeDeploy API for recent deployments, and publishes any new success or failure to the SNS topic.
CC. Create an Amazon EventBridge rule that matches CodeDeploy deployment state-change events with the SUCCESS and FAILURE states, with the SNS topic as the target.
DD. Turn on CloudWatch Logs for the CodeDeploy agent on each instance, and create a metric filter that publishes to the SNS topic when a line contains the word Deployment.
Show the answer and explanation
Answer: C
A. Wrong: This changes every deployment script, which the team wants to avoid. It also misses deployments that fail outside the script, such as during an agent step.
B. Wrong: This is the polling job the team ruled out. It also adds a function and a schedule that the team must maintain.
D. Wrong: Agent logs live on the instances and do not cover every deployment, such as ones that fail before reaching an instance. A text match on a log line is also a fragile signal for success or failure.
Explanation
CodeDeploy publishes deployment state-change events to Amazon EventBridge. A rule that matches the SUCCESS and FAILURE states and targets the SNS topic alerts the channel about each finished deployment, with no change to the scripts and no polling.
Want more on Custom metrics, alarms and health checks? The 5 full-length practice sets have 16 more Custom metrics, alarms and health checks questions, 390 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →