PCNSE Manage, Monitor and Operate Practice Question
An organization has a pair of PA-5250 firewalls in active/passive HA. During a maintenance window, the active firewall is rebooted. After the reboot, the firewall that was passive becomes active and passes traffic. However, the other firewall remains in a non-functional state and shows 'unknown' as HA state. The administrator checks the HA configuration and finds both firewalls have the same HA settings. What is the most likely issue?
⚠ Common exam trap
Many candidates assume a software version mismatch or keepalive timer issue is the cause, but the 'unknown' state specifically points to a loss of control-plane connectivity, not a version or timer problem.
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
✓
The HA control link is down or misconfigured.
After a reboot, the previously active firewall fails to join the HA pair and shows 'unknown' state, which indicates it cannot communicate with its peer. Since both firewalls have identical HA settings, the most likely cause is that the HA control link (the dedicated link used for heartbeat and state synchronization) is down or misconfigured, preventing the rebooted firewall from establishing a valid HA session.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The backup firewall has a different software version.
Why it's wrong here
Mismatched PAN-OS versions block HA formation, but the stem states both firewalls share identical HA settings and the peer already became active, so version mismatch is not evidenced. Version parity is the correct check when HA state shows 'suspended' with explicit version-mismatch alerts.
- ✗
The floating IP addresses are not configured.
Why it's wrong here
Floating IPs affect traffic routing after failover, not HA state negotiation; an 'unknown' state points to a broken HA control link or mismatched HA1 configuration. It is tempting because missing floating IPs do cause failover problems, and would be correct if traffic failed to pass rather than the peer showing unknown.
- ✗
The HA keepalive timer is too short.
Why it's wrong here
A short keepalive timer causes premature failover or flapping, not a persistent 'unknown' HA state after the peer reboots. Timer tuning is the right fix when heartbeats are delayed across high-latency links, not when a firewall cannot establish HA state at all.
- ✓
The HA control link is down or misconfigured.
Why this is correct
HA state synchronisation and election traffic traverse the dedicated HA control link. If that link is down or misconfigured, the rebooted peer cannot exchange hello and state messages, so it remains 'unknown' even though data-plane failover succeeded.
Go deeper
Related to this question
About these practice questions
One of 319 original PCNSE practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This PCNSE practice question is part of Courseiva's free Palo Alto Networks 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 PCNSE exam.