Exams / SAP-C03 / Study guide / Metrics, logs, tracing and SLOs (CloudWatch, OpenTelemetry, Application Signals)
Metrics, logs, tracing and SLOs (CloudWatch, OpenTelemetry, Application Signals): SAP-C03 study notes and practice questions
What to know about Metrics, logs, tracing and SLOs (CloudWatch, OpenTelemetry, Application Signals) for the SAP-C03 exam, from the Operational Excellence and Automation domain (20% of the exam guide), then 2 free questions to test it. Part of the SAP-C03 study guide.
SAP-C03 asks how to instrument many services the same way, see inside container clusters, and measure reliability against an objective rather than a raw threshold.
Standardized instrumentation
AWS Distro for OpenTelemetry (ADOT) is AWS’s supported OpenTelemetry distribution: one set of SDKs, auto-instrumentation agents and a collector for metrics and traces, sent to CloudWatch, X-Ray or other OpenTelemetry back ends.
The AWS X-Ray SDKs and daemon are in maintenance mode. X-Ray remains the trace store and trace map, but new code should be instrumented with OpenTelemetry.
The CloudWatch agent collects host metrics (memory, disk) and log files from EC2 and on-premises servers.
Embedded metric format (EMF) writes structured logs that CloudWatch turns into metrics, which suits Lambda and containers.
Use consistent dimensions and resource attributes (service, environment, team) across every workload so dashboards and alarms work for all of them.
Container monitoring
Container Insights collects cluster, node, service, task and pod metrics and logs for ECS, EKS and Kubernetes on EC2.
Enhanced observability for EKS and ECS adds detailed per-container metrics and curated dashboards.
On EKS, install the CloudWatch Observability add-on rather than maintaining your own agents.
SLOs with Application Signals
CloudWatch Application Signals auto-instruments applications (Java, Python, Node.js and .NET on EC2, ECS, EKS and Lambda) through OpenTelemetry and shows request volume, latency, errors and faults per service and operation, with an application map of dependencies.
Define service level objectives on a service level indicator such as availability or p99 latency, measured over a rolling or calendar interval, either by time periods or by request count.
Application Signals tracks the error budget, and burn-rate alarms warn when you are consuming it too fast.
It correlates metrics with traces, logs, Synthetics canaries and RUM, and shows deployments and configuration changes beside the metrics.
CloudWatch cross-account observability shows Application Signals and other telemetry from many accounts in one monitoring account (see log aggregation).
How to choose
Scenario wording
Choose
“One vendor-neutral instrumentation standard for all teams”
ADOT (OpenTelemetry)
“Existing app uses the X-Ray SDK; plan for the future”
Migrate to OpenTelemetry with ADOT
“Memory and disk metrics from EC2”
CloudWatch agent
“Per-pod CPU and memory across EKS clusters”
Container Insights (enhanced observability)
“Alert when we’re at risk of missing 99.9% availability this month”
Application Signals SLO with burn-rate alarm
“Custom metrics from Lambda without API calls”
Embedded metric format
Common traps
New X-Ray SDK instrumentation when ADOT is the recommended path.
Static error-count alarms when the requirement is stated as an SLO or error budget.
Running custom Prometheus and Grafana servers when the scenario asks for least operational overhead.
Assuming EC2 publishes memory metrics without the CloudWatch agent.
Different metric names per team, which makes organization-wide dashboards impossible.
A streaming service runs 60 microservices written in Java, Python, Go and Node.js, on Amazon EKS and AWS Lambda. Engineers cannot follow a single customer request across services, and the platform team wants traces that work the same in every language. Two of the services are older Java applications that cannot be changed quickly.
The platform team also wants the instrumentation to stay on a vendor-neutral standard, and the traces must reach AWS X-Ray and CloudWatch without a separate tracing server to run.
Which approach meets these requirements?
Choose one answer.
AA. Instrument every service with the AWS X-Ray SDK for its language, and run the X-Ray daemon as a sidecar in each pod to send the traces.
BB. Instrument each service with OpenTelemetry, using auto-instrumentation agents for the older Java services, and export traces through the AWS Distro for OpenTelemetry collector to X-Ray and CloudWatch.
CC. Write custom logging in each service that prints the request ID and the duration of each call, and use CloudWatch Logs Insights to join the entries across the services by the shared request ID on a dashboard.
DD. Turn on the detailed metrics for each EKS node and Lambda function, and compare the average latency per service on the CloudWatch dashboard.
Show the answer and explanation
Answer: B
A. Wrong: The X-Ray SDKs and daemon are in maintenance mode, so new instrumentation should not start on them. The option also gives a different instrumentation library for each language.
B. Right: Correct. OpenTelemetry gives one standard across languages, and its Java auto-instrumentation agent adds tracing to the older services without code changes. The AWS Distro collector exports the traces to X-Ray and CloudWatch, so no separate tracing server is needed.
C. Wrong: Logs joined by hand give a less complete picture than a distributed trace, and each language would print its own format. The option does not produce traces across services.
D. Wrong: Averages per service do not follow one request across the services it calls. The option does not show where a single customer request spends its time.
Explanation
The AWS Distro for OpenTelemetry gives one vendor-neutral instrumentation standard across languages and exports traces to X-Ray and CloudWatch with a collector rather than a separate server. The X-Ray SDK is in maintenance mode, and logs or averaged metrics cannot follow one request across services.
A payment processor's checkout service has a target that 99.9 percent of requests succeed and that 95 percent of them finish within 800 milliseconds, measured over a month. The on-call team wants to see how much of the monthly error budget is left and to be paged early when the service burns that budget too fast.
The team also wants a view of checkout from outside the company's network, so that it notices when customers cannot reach the service even while the internal metrics look healthy.
Which TWO approaches meet these requirements? (Choose two.)
Choose two answers.
AA. Define service level objectives in CloudWatch Application Signals for the checkout service, one for availability and one for latency, and create burn-rate alarms that notify the on-call team.
BB. Create CloudWatch alarms on the checkout service's CPU utilization and memory usage, and page the on-call team when either one stays above 80 percent for 10 minutes.
CC. Create a CloudWatch Synthetics canary that runs the checkout flow from several locations outside the company's network on a schedule, and alarm when a run fails or runs slowly.
DD. Search the checkout service's logs in CloudWatch Logs Insights each morning for HTTP 500 responses, and compare the count with the previous day.
EE. Create a Cost Anomaly Detection monitor on the checkout service's account, and alert the on-call team when the daily spend changes sharply.
Show the answer and explanation
Answers: A, C
A. Right: Correct. Application Signals tracks each objective against its target and shows the error budget left in the interval. Burn-rate alarms page the on-call team when the budget is being used up too fast.
B. Wrong: CPU and memory do not measure whether the requests succeed or finish in time, so the error budget cannot be tracked from them. The alarms also miss customer-facing failures.
C. Right: Correct. A canary calls the checkout flow from outside the network, so it catches the customer-facing failures that internal metrics miss. Its alarms add an external view of availability and latency.
D. Wrong: A morning search finds failures long after they start, and it does not show the budget left in the month. The option is a manual review rather than an early alert.
E. Wrong: Spend anomalies reflect cost, not service health or the error budget. The option does not measure requests or latency.
Explanation
Application Signals tracks the availability and latency objectives with error-budget burn alarms, and a Synthetics canary from outside the network catches customer-facing failures. CPU alarms, a morning log search and spend anomalies do not measure the objectives, the budget or the external view.
Want more on Metrics, logs, tracing and SLOs (CloudWatch, OpenTelemetry, Application Signals)? The 5 full-length practice sets have 10 more Metrics, logs, tracing and SLOs (CloudWatch, OpenTelemetry, Application Signals) questions, 375 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Metrics, logs, tracing and SLOs (CloudWatch, OpenTelemetry, Application Signals)