When configuring health rules, it is important to: (Choose two)

Question

Options

• ASet thresholds that reflect realistic expectations for the application
• BInclude both leading and lagging performance indicators
• CIgnore metrics that show variability
• DBase rules on the maximum capacity of the system regardless of actual use

• A
  71% (24)
• C
  21% (7)
• D
  9% (3)

Explanation

Setting thresholds that reflect realistic expectations (A) ensures alerts fire when something is actually wrong - not constantly due to normal variance, and not too loosely to miss real problems. Including both leading indicators (predictive signals like queue depth or error rate trends) and lagging indicators (outcomes like response time or throughput) (B) gives you both early warning and confirmation of actual impact, making health rules far more actionable.

Why the distractors fail:

• C is the opposite of good practice - variable metrics often signal instability and should be monitored carefully, not ignored.
• D sets thresholds against theoretical maximums rather than actual usage patterns, which produces either constant false alarms (if the app never approaches max capacity) or dangerously delayed alerts (if max capacity is far above the typical operating point).

Memory tip: Think "Real and Round" - health rules should be Realistic (A, not based on theoretical max) and Rounded in perspective (B, both leading and lagging). If a choice tells you to ignore data or use irrelevant baselines, it's wrong.

No community discussion yet for this question.