156-315.81.20 ClusterXL and VRRP High Availability Practice Question
A security administrator manages a two-member ClusterXL High Availability cluster. The administrator wants to run a failover test during a maintenance window without unplugging any cables or stopping the cluster. Which action will cause the currently active member to relinquish its Active state and force the standby member to take over?
⚠ Common exam trap
The trap here is assuming that any cluster-related command can force a failover, when only an administrative state change or a real failure triggers the transition.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Run `clusterXL_admin down` on the active member.
Administratively taking the active member down with `clusterXL_admin down` is the supported way to simulate a failure and verify that the standby member assumes the Active role. The command cleanly transitions the local member to Down, prompting the peer to promote itself. Other options are diagnostic or affect the wrong member, so they do not produce the desired controlled failover.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run `cphaprob -a if` on the active member.
Why it's wrong here
The `cphaprob -a if` command displays the monitored interfaces and their current state. It is strictly a read-only diagnostic command; it does not change the cluster state or trigger a failover. Using it during a maintenance window would only show interface status, leaving the active member in the Active state, so the test would not occur.
- ✓
Run `clusterXL_admin down` on the active member.
Why this is correct
The `clusterXL_admin down` command administratively takes the local member out of the cluster, causing it to transition to the Down state. The standby member detects the loss of the active peer and promotes itself to Active. This is the supported way to perform a controlled failover test without physically disconnecting cables or stopping the entire cluster.
- ✗
Run `fw ctl debug -m cluster on` on the active member.
Why it's wrong here
This command enables debug logging for the cluster kernel module. It increases the volume of diagnostic output but has no effect on the cluster's operational state. The active member remains Active, so no failover is triggered. Debugging is useful for troubleshooting, but it is not a mechanism to force a state transition during a maintenance test.
- ✗
Run `cpstop` on the standby member.
Why it's wrong here
Stopping Check Point services on the standby member would remove the standby from the cluster, but the active member would remain Active. No failover occurs because the active member still holds the Active state. This action would actually reduce redundancy and is the opposite of what is needed to test the failover path from active to standby.
About these practice questions
Courseiva writes every 156-315.81.20 question from scratch — 210 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Check Point exam blueprint
This 156-315.81.20 practice question is part of Courseiva's free Check Point certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the 156-315.81.20 exam.