An NCC health check reports significant time skew between nodes in a production AHV cluster. Before making any configuration changes, why must the administrator correct the skew?
Select an answer to reveal the explanation.
Short Explanation
Think of cluster time like everyone’s watches: if they drift, login tickets and leader votes stop lining up. Fix the skew before you touch anything else, because authentication and coordination can fail. You don't want a health check turning into a full cluster outage.
Full Explanation
NCC health checks evaluate time synchronization across CVMs because Nutanix cluster services depend on trusted time for authentication and distributed coordination. Security tokens and internal service authentication can become invalid when node clocks differ beyond acceptable tolerances, while Zookeeper-based coordination and internal metadata services rely on consistent event ordering and quorum behavior. A significant skew can therefore cause login, cluster management, and service coordination failures, making it a prerequisite fix before configuration changes. The categories and projects answer is wrong because those are Prism Central metadata and placement constructs; they do not require synchronized node clocks to apply. The redundancy factor answer is wrong because RF is a container storage policy applied by administrator intent, not an automatic response to clock drift. The snapshots and protection domains answer is wrong because local snapshots remain local and protection domain operation is not automatically disabled until replication targets resynchronize merely because clocks are skewed. Exam caveat: when a health check names time skew, treat it as a cluster-wide trust and coordination issue, not a storage policy or UI feature problem. Operational check: use the NCC health check output to identify skewed CVMs, then verify NTP configuration on those nodes before making further changes.