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
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
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.