Intermediate Monitoring & Observability test (Intermediate)

Sample questions

5 sample questions from the Intermediate Monitoring & Observability test, with the answers. Samples are taken out of the live test, so you will not meet these when you sit it.

1. Which of the following best describes the primary use cases of PromQL and Loki?

   1. PromQL and Loki are both used exclusively for querying time-series data from Prometheus.
   2. PromQL and Loki are both used exclusively for querying log data.
   3. PromQL is used for querying time-series data from Prometheus, while Loki is used for querying log data.
   4. PromQL is used for querying log data, while Loki is used for querying time-series data from Prometheus.

   Answer: C. PromQL is used for querying time-series data from Prometheus, while Loki is used for querying log data.

   PromQL is the query language used to retrieve and process time-series data from Prometheus, which is a monitoring system. Loki, on the other hand, is a log aggregation system that uses a query language similar to PromQL but is tailored for logs. The other options incorrectly describe the roles of these tools or introduce unrelated concepts.

2. Which of the following is a technique used to monitor and analyze the flow of requests through a distributed system, providing insights into the performance and behavior of individual services and their interactions?

   1. Alert fatigue
   2. Distributed tracing
   3. SLI calculation
   4. SLO alignment

   Answer: B. Distributed tracing

   Distributed tracing is a method used to monitor and analyze the flow of requests through a distributed system, providing insights into the performance and behavior of individual services and their interactions. It helps in identifying bottlenecks, failures, and latency issues across microservices.

3. Which action is most directly related to aligning service level objectives (SLOs) with business priorities and user expectations?

   1. Reviewing and aligning service level objectives with business priorities and user expectations.
   2. Implementing alert deduplication to reduce noise in monitoring systems.
   3. Setting up log retention policies in Loki for long-term observability.
   4. Configuring tracing correlation IDs for better debugging of microservices.

   Answer: A. Reviewing and aligning service level objectives with business priorities and user expectations.

   SLO alignment involves ensuring that service level objectives are directly tied to business goals and user needs. This ensures that the objectives are meaningful and actionable, and any bugs or issues identified during monitoring are addressed in the context of their impact on these objectives. Other options may relate to other aspects of monitoring or alerting but are not directly focused on aligning SLOs with business priorities.

4. Which of the following is a valid alert suppression technique to reduce alert fatigue while ensuring critical issues are not missed?

   1. Increasing the frequency of alerts during peak usage hours
   2. Disabling all alerts for non-critical systems
   3. Using a fixed alert threshold regardless of system load
   4. Implementing a dynamic alert threshold based on historical data patterns

   Answer: D. Implementing a dynamic alert threshold based on historical data patterns

   Alert suppression techniques aim to reduce the number of alerts without missing critical issues. Implementing a dynamic alert threshold based on historical data patterns allows for more accurate detection of anomalies, reducing false positives and alert fatigue. Other options do not directly address suppression or may not be effective in reducing unnecessary alerts.

5. A web application received 3000 requests in a 24-hour period, and 15 of those requests resulted in errors. What is the error rate SLO for this service, assuming the SLO target is 0.5% or lower?

   1. The error rate SLO is 10%.
   2. The error rate SLO is 0.5%.
   3. The error rate SLO is 5%.
   4. The error rate SLO is 1.5%.

   Answer: B. The error rate SLO is 0.5%.

   The error rate SLO is calculated by dividing the number of errors (15) by the total number of requests (3000), resulting in an error rate of 0.005, or 0.5%. This meets the SLO target of 0.5% or lower. The other options are incorrect because they do not accurately represent the error rate calculation.