Your team runs planned maintenance on an AHV host, and Prism Central raises a known maintenance alert. An X-Play automation must mark the alert as handled while leaving the alert history and monitoring intact. Which automation action should it perform?
Select an answer to reveal the explanation.
Short Explanation
Think of an acknowledged alert like a triage tag: it's still on the board, but someone has claimed it. You want the automation to acknowledge the alert, not erase the evidence or blind your monitor. The trap is making the noise go away by disabling monitoring or deleting history.
Full Explanation
An automated alert-handling workflow should preserve observability while recording human or automated triage. In Nutanix alert management, acknowledging an alert marks it as handled without removing it from the alert history or stopping future detection, so the alert remains available for audit, reporting, and escalation review. An X-Play or API-driven workflow should therefore invoke the alert-management acknowledge action when the known maintenance condition is expected. Deleting an alert corrupts the historical record and can hide recurring symptoms, because the alert entry itself is the evidence that the condition occurred and was addressed. Disabling the alert rule suppresses detection for that condition, which is unsafe during maintenance because unexpected failures may occur under the same rule. Placing a host in maintenance mode changes cluster behavior and may prevent some alerts, but it does not acknowledge an already raised alert and can mask unrelated issues by altering the cluster state rather than managing the alert lifecycle. Exam caveat: do not confuse suppressing or removing an alert with acknowledging it; acknowledgment is a workflow state, not a monitoring change. Operational check: test the automation in a maintenance window by confirming the alert remains visible in history with acknowledged status and that new unrelated alerts still generate.