Before relying on a GHES replica as a warm spare, which operational check is most important on an ongoing basis?
Select an answer to reveal the explanation.
Short Explanation and Infographic
A warm spare only helps if it is actually current. Watch replication health — lag, failed components, disk pressure — so promotion would not lose unacceptable data. Promoting daily 'just in case' is a terrible idea; it is a deliberate failover action. Licenses and webhooks are not the primary readiness signal for HA replication.
Full explanation below image
Full Explanation
The correct answer is verifying that replication is healthy and in sync. HA/warm-spare value depends on the replica receiving repository and service data with acceptable lag. Administrators routinely check ghe-repl-status (and monitoring integrations) for failed services, large lag, or disk issues. Option A is wrong: license seat counts are not how you validate replica readiness. Option C is wrong: webhook configuration on a non-serving replica is not the key HA readiness metric. Option D is wrong and dangerous: ghe-repl-promote is for failover, not a daily health routine. Document RPO/RTO expectations, automate alerts on replication failure, and rehearse failover in a controlled test when possible.