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's actually current, so you need to watch replication health—lag, failed components, disk pressure—so promotion won't lose unacceptable data. Running promotion daily just in case is a deliberate failover action, not a health check. License counts and webhook settings aren't the primary readiness signal for HA replication.
Full Explanation
The correct choice is verifying that replication is healthy and reasonably in sync with the primary. 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. The option about confirming that the replica has a higher user license count than the primary is wrong because license seat counts are not how you validate replica readiness. The option about disabling all webhooks on the replica so it never receives events is wrong because webhook configuration on a non-serving replica is not the key HA readiness metric. The option about running ghe-repl-promote daily as a preventive measure is wrong and dangerous because 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.