SOA-C03 - Monitoring, Logging, Analysis, Remediation, and Performance Optimization (22% of the exam) - Section 1.2

Centralise logs and traces using Amazon CloudWatch Logs, AWS CloudTrail, Amazon Managed Service for Prometheus, Amazon Managed Grafana and AWS X-Ray.

Centralise application and infrastructure telemetry across Amazon CloudWatch Logs, AWS CloudTrail, Amazon Managed Service for Prometheus, and AWS X-Ray. Recognise which service to choose for audit trails, metrics scraping, or distributed tracing of microservices.

Amazon CloudWatch LogsAWS CloudTrailAmazon Managed Service for PrometheusAWS X-Ray

Practice question for this objective

Free sampleMonitoring, Logging, Analysis, Remediation, and Performance Optimizationmedium

A platform team runs a microservices application on Amazon EKS. They want a single Amazon Managed Grafana workspace where on-call engineers can correlate two kinds of telemetry side by side: application time-series metrics already exposed in Prometheus exposition format, and the end-to-end distributed traces that show how long each request spends in every downstream service. The team does not want to run or patch any of the back-end stores themselves, and they want Grafana to query each telemetry store in place without copying the data into the workspace. Which two telemetry back ends should they add as Grafana data sources to satisfy this requirement? (Select TWO.)

  • AAmazon Managed Service for Prometheus, ingesting the Prometheus-format metrics and queried by Grafana for the time-series panels. Correct
  • BAmazon CloudTrail, queried by Grafana to provide the per-request latency breakdown across the downstream microservices.
  • CAWS X-Ray, supplying the distributed traces so Grafana can show the time each request spends in every downstream service. Correct
  • DA self-managed Prometheus server on Amazon EC2 scraping the pods, with Grafana querying that instance for the metrics panels.
  • EAmazon CloudWatch Logs Insights, queried by Grafana to reconstruct the cross-service trace spans for each slow request.
Centralised observability in Managed Grafana queries purpose-built managed back ends in place: Managed Service for Prometheus for metrics and X-Ray for distributed traces. The requirement pairs two distinct telemetry types with no self-managed stores and no data copied into Grafana. Amazon Managed Service for Prometheus is the managed home for Prometheus-format metrics, and AWS X-Ray is the managed home for distributed traces; both are native Grafana data sources Grafana queries in place. CloudTrail records API audit events, not traces; a self-managed Prometheus reintroduces the patching the team rejected; and Logs Insights queries logs but cannot reconstruct cross-service trace spans, so none of the three satisfies the stated need.

Why A is correct: Amazon Managed Service for Prometheus stores the Prometheus-exposition metrics at scale with no servers to patch, and it is a native Managed Grafana data source for the time-series panels.

Why B is wrong: CloudTrail records management and data API activity for audit, so it is tempting as a central log store, but it does not produce per-request distributed traces or service latency breakdowns.

Why C is correct: AWS X-Ray captures end-to-end distributed traces and is a managed back end with no servers to run, and Grafana can query it directly to render the per-service latency breakdown.

Why D is wrong: A self-managed Prometheus on EC2 can store the metrics, but it leaves the team patching and scaling the time-series database, which the stated requirement explicitly rules out.

Why E is wrong: Logs Insights queries log events and is a valid Grafana source for logs, but it does not assemble cross-service trace spans, so it cannot deliver the distributed latency breakdown the stem needs.

See more SOA-C03 practice questions, answers explained.

Exam traps in Monitoring, Logging, Analysis, Remediation, and Performance Optimization

Answers that look right on this material and are not. Each one is a distractor from a different question in the SOA-C03 bank for this domain.

  • Deploy a self-managed Prometheus server and a Grafana server onto the EKS cluster and operate both alongside the application workloads.

    Why it is wrong: Running Prometheus and Grafana inside the cluster works but leaves the team patching, scaling and backing up both systems, which is exactly the self-managed burden they want to avoid.

  • Replace the Prometheus server with the CloudWatch agent on each instance and point the agent at the Managed Service for Prometheus workspace for ingestion.

    Why it is wrong: Swapping Prometheus for the CloudWatch agent discards the existing scrape configuration the team wants to keep and changes the whole collection path rather than just offloading storage.

  • Build an automation that copies each source account's metrics, log groups and traces into the monitoring account on a recurring schedule for engineers to query.

    Why it is wrong: Copying telemetry duplicates large volumes of data, adds cost and lag, and still leaves the monitoring account viewing stale snapshots rather than the live signals.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.