Sample questions
Observability MonitoringDifficulty 1
What is the key difference between monitoring and observability?
- aMonitoring only ever collects logs, while observability only ever collects metrics data.
- bMonitoring tracks known metrics against known thresholds; observability infers system state from emitted data.✓
- cObservability only matters once a company grows large; small systems can rely on monitoring alone.
- dMonitoring and observability always describe the exact same underlying practice, just marketed under two different names.
Explanation:Monitoring watches predefined signals (CPU, error rate) against known thresholds. Observability is broader: it's the property of a system that lets engineers ask new, unforeseen questions using metrics/logs/traces without having pre-built a dashboard for that exact question. (a) is wrong because both practices use metrics and logs together, not one exclusively.
Observability MonitoringDifficulty 1
Which three signal types are commonly referred to as the "three pillars" of observability?
- aMetrics, logs, and traces✓
- bCPU, memory, and disk usage
- cAlerts, dashboards, and reports
- dUptime, throughput, and error budget
Explanation:Metrics (numeric time-series), logs (discrete event records), and traces (request-level execution paths across services) are the three data types most systems combine to reconstruct behavior. (b) lists resource metrics, which are only a subset of metrics; (c) and (d) are tools/derived concepts built on top of the three signals, not the signals themselves.
Observability MonitoringDifficulty 2
What is the practical difference between a counter and a gauge metric?
- aA counter only accumulates upward (or resets to zero); a gauge holds a value that can move up or down freely.✓
- bA counter holds an instantaneous value that fluctuates, while a gauge only ever accumulates upward over time.
- cA counter is only ever used for string values, while a gauge is only ever used for numeric measurements.
- dA counter and a gauge can be swapped for each other in any system, with no practical difference at all.
Explanation:Counters model cumulative totals like total requests served, which only grow (or reset on restart). Gauges model instantaneous, fluctuating values like current queue length or memory usage. Picking the wrong type breaks rate/trend calculations downstream. (b) inverts the definitions; (c) and (d) are false — both hold numeric values and behave very differently in aggregation.
Observability MonitoringDifficulty 2
A service emits the following log line:
{"timestamp":"2020-01-01T10:00:00Z","level":"error","service":"payment-api","message":"db connection timeout","request_id":"abc123"}
What is the main advantage of this structured (JSON) log format over plain-text logging?
- aStructured log files always take noticeably less disk space than any comparable plain-text log format.
- bApplications that switch to structured format logging automatically start running faster.
- cFields like level or request_id can be filtered directly, since the format is machine-parseable.✓
- dStructured logging removes the need for using log levels such as error or info entirely.
Explanation:Because each field is a distinct, typed key rather than free text, log tooling can filter, aggregate, and correlate on service, level, or request_id without fragile text parsing (e.g. regex). (a) and (b) are false claims about size/performance that structured logging doesn't guarantee; (d) is wrong — the example still carries a level field.
Observability MonitoringDifficulty 1
Why do applications typically use log levels such as DEBUG, INFO, WARN, and ERROR?
- aOnly to standardize the coding style developers use when writing log statements.
- bBecause using log levels makes the application write every log line faster to disk.
- cLog levels are only ever required in development environments and are completely meaningless in production.
- dTo let logs be filtered by severity so noise is reduced and operators can focus on what matters.✓
Explanation:Levels let teams tune verbosity per environment: DEBUG for deep troubleshooting, ERROR/WARN for what actually needs attention in production. This keeps signal-to-noise manageable. (b) is a false performance claim; (c) is wrong, production commonly runs at INFO/WARN and levels stay meaningful; (a) understates their operational purpose.
Observability MonitoringDifficulty 2
A team sets an alert to fire on every small CPU spike above 70%. Within weeks, they receive dozens of alerts per day and start dismissing them without reading. What is this phenomenon called, and what is the root cause?
- aCardinality explosion; too many unique label combinations are slowing down the metrics backend.
- bAlert fatigue; a high volume of low-signal alerts causes even important ones to be missed or ignored.✓
- cLog rotation failure; the disk keeps filling up, causing the same alert to re-fire repeatedly.
- dSLA breach; the uptime commitment formally promised in writing to paying customers has already been exceeded.
Explanation:When alerts fire too often on noise rather than genuine actionable conditions, operators desensitize and start ignoring notifications, including real incidents — this is alert fatigue. The fix is usually raising thresholds, adding a duration window, or alerting on symptoms rather than raw fluctuations. (a), (c), (d) describe unrelated failure modes not implied by the scenario.