Measurement, Monitoring & Sharing
38 practice questions with explanations — 15 free to try
3 of these 38 questions are in the free 15-question taster · the full topic is part of Premium
PassNova has 38 DevOps Foundation practice questions on Measurement, Monitoring & Sharing, each with a clear explanation. A 15-question taster is free with no sign-up; the full bank is part of PassNova Premium. Updated for 2026.
Measurement, Monitoring & Sharing: example questions & answers
3 worked examples with answers and explanations below. Try 15 DevOps Foundation questions free in the browser; the full 38-question Measurement, Monitoring & Sharing bank is part of PassNova Premium.
Which set lists DORA's original 'four key' metrics for measuring software delivery performance?
- ACPU usage, memory usage, disk space, and network latency
- BLines of code written, number of meetings held, total open bug count, and percentage server uptime
- CDeployment frequency, lead time for changes, change failure rate, and time to restore service✓
- DQuarterly revenue, team headcount, customer satisfaction score, and total marketing spend per campaign
Answer: DORA's original four key metrics were deployment frequency, lead time for changes, change failure rate and time to restore service, which together measure both throughput and stability. DORA now uses five metrics: change lead time, deployment frequency and failed deployment recovery time for throughput, and change fail rate and deployment rework rate for instability.
What is the main difference between monitoring and observability?
- AMonitoring is manual while observability is fully automated by AI tools
- BThey are identical concepts which simply happen to go by two different names in practice
- CObservability applies to hardware, while monitoring applies to software
- DMonitoring tracks known, predefined conditions; observability helps understand unknown internal states from system outputs✓
Answer: Monitoring watches predefined metrics and known failure conditions, whereas observability uses logs, metrics, and traces to help teams understand and diagnose unexpected or unknown system behaviour.
In Site Reliability Engineering (SRE), what is an 'error budget'?
- AThe acceptable amount of unreliability allowed before reliability work takes priority over new features✓
- BA prioritised list of all known software defects that must be cleared before the next release can proceed
- CThe number of engineers assigned to support
- DThe financial budget allocated to fixing bugs
Answer: An error budget is the permissible level of unreliability derived from a service level objective; once it is exhausted, teams prioritise reliability work over releasing new features.