AZ-120 · Question #237
You have an SAP production landscape on Azure that uses a two-node Pacemaker cluster. You need to ensure that the cluster automatically fails over for Azure scheduled events. What should you…
The correct answer is C. the Azure fence agent. Configuring the Azure fence agent (STONITH) on each Pacemaker node is correct because it integrates directly with the Azure metadata service to detect scheduled events (maintenance, reboot, redeployment) and triggers a controlled node fence - forcing a clean failover before…
Question
You have an SAP production landscape on Azure that uses a two-node Pacemaker cluster. You need to ensure that the cluster automatically fails over for Azure scheduled events. What should you configure on each node?
Options
- Athe Azure Monitor agent
- Bthe Linux diagnostics extension (LAD)
- Cthe Azure fence agent
- Dthe Azure VM extension for SAP
How the community answered
(60 responses)- A3% (2)
- B5% (3)
- C90% (54)
- D2% (1)
Explanation
Configuring the Azure fence agent (STONITH) on each Pacemaker node is correct because it integrates directly with the Azure metadata service to detect scheduled events (maintenance, reboot, redeployment) and triggers a controlled node fence - forcing a clean failover before Azure forcibly interrupts the node. Without it, the cluster cannot react proactively to Azure's event notifications, risking split-brain or data corruption.
Why the distractors are wrong:
- A (Azure Monitor agent) - collects logs and metrics for observability; it has no ability to trigger cluster fencing or respond to scheduled events.
- B (Linux diagnostics extension / LAD) - sends diagnostic data to Azure Storage; similarly passive and irrelevant to cluster failover logic.
- D (Azure VM extension for SAP) - enables SAP-specific monitoring and support tooling, but does not participate in Pacemaker cluster fencing or event-driven failover.
Memory tip: Think "fence = force out." The fence agent is the cluster's bouncer - when Azure signals a scheduled event, the fence agent kicks the affected node out of the cluster cleanly so the other node can take over. If it's not about shooting a node ("STONITH = Shoot The Other Node In The Head"), it won't handle failover.
Topics
Community Discussion
No community discussion yet for this question.