- What the EX436 Credential Actually Certifies
- How the Three-Hour Hands-On Exam Works
- The Nine Published Objectives, Read Like an Administrator
- Why "Survives Reboot" Changes How You Practice
- Prerequisites, RH436, and the Experience Gap
- Booking, Cost, Retakes, and Renewal Mechanics
- Sequencing Your Preparation by Objective
- Where the Skill Set Gets Used
- Frequently Asked Questions
- EX436 is a single three-hour, hands-on exam covering RHEL High Availability Add-On administration, graded against objective criteria.
- Configurations must survive a reboot, so every lab you practice should end with a restart test.
- Red Hat publishes nine unweighted objectives, from cluster creation through growing a GFS2 filesystem.
- RHCSA or RHCE is recommended, not mandatory; RH436 is recommended, and class attendance is optional.
What the EX436 Credential Actually Certifies
The Red Hat Certified Specialist in High Availability Clustering credential is earned by passing exam EX436, delivered by Red Hat, Inc. It validates that you can build and operate clusters using the RHEL High Availability Add-On: the Pacemaker-based stack that keeps services running when a node fails. This is not a theory credential. It tests whether you can sit at a terminal, stand up a working cluster, and leave it in a state that holds together after the machines restart.
If you are new to the topic itself, the overview in What Is High Availability Clustering Certification? covers the basics. This article focuses on the specifics of EX436: what the exam objectives demand, how the hands-on format shapes preparation, and the practical mechanics of booking and keeping the credential current. For a broader orientation to the credential family on this site, see our High Availability Clustering Certification hub page.
How the Three-Hour Hands-On Exam Works
EX436 consists of one three-hour hands-on section. You are not answering multiple-choice questions or matching terms to definitions. You receive a set of tasks to complete on live systems, and your results are graded against objective criteria, meaning the grader checks whether the resulting configuration actually does what the task required.
A few format realities follow from that:
- Outcome-based grading. Several valid commands can reach the same end state. What counts is the state of the cluster, not the exact command you typed.
- No partial credit for intentions. A resource that is configured but fails to start is a failed outcome, even if your syntax was nearly right.
- Persistence is part of correctness. Red Hat states that configurations must survive reboot, so a setup that only works until the next restart does not satisfy the task.
- Documentation access is unconfirmed. The exam page does not specify an exam-specific documentation allowance, so verify the rules for your booked session rather than assuming either way.
Task counts and pass marks are not published in the sources we rely on, so we do not quote them. If you want to understand how candidates generally experience difficulty, read How Hard Is the High Availability Clustering Exam?, and for scoring details see High Availability Clustering Passing Score.
The Nine Published Objectives, Read Like an Administrator
Red Hat's live exam outline lists nine first-level objectives. They are unweighted, and nine is simply the count of published lines, including separate logging/monitoring entries and a separately displayed GFS2 growth entry. The detailed outline takes precedence over the shorter seven-item competency summary on Red Hat's specialist overview page. For an objective-by-objective walkthrough, see High Availability Clustering Exam Domains: Complete Guide to All 9 Content Areas. Here is how each one translates into practical work.
Configure a high-availability cluster
The foundation. You must be able to bring nodes together into a functioning cluster from a bare starting point.
- Installing the High Availability Add-On packages and enabling the required services
- Authenticating nodes and creating the cluster with
pcs - Verifying quorum and membership before building anything on top
Configure cluster fencing
Fencing is what lets a cluster safely recover from a misbehaving node. Without it, shared-storage resources are at risk, so expect this to underpin many other tasks.
- Defining fence devices appropriate to the environment
- Understanding how fencing interacts with node failure and resource recovery
- Testing that a fence action actually triggers when intended
Configure cluster logging and monitoring
Red Hat lists logging and monitoring as its own entry. Practically, this means knowing where cluster components write their logs and how to adjust that behavior so you can diagnose failures quickly.
- Locating and reading cluster log output
- Adjusting logging configuration to make troubleshooting feasible
Configure cluster monitoring
A separate published entry from logging. Focus on how the cluster observes the health of its resources and nodes, and how you inspect that state from the command line.
- Reading cluster and resource status output accurately
- Configuring resource monitoring behavior, such as operation intervals and timeouts
Configure a clustered fail-over service
The classic high-availability deliverable: a service that moves to a surviving node when its host fails.
- Building resources and grouping them so they start, stop, and move together
- Ensuring dependent pieces, such as an address, storage, and the application, come up in a sensible order
- Proving fail-over works by deliberately disrupting a node
Configure cluster service behavior
Beyond "it runs," this objective is about how it runs: where resources prefer to live and how they respond to failures.
- Constraints that influence placement and ordering
- Controlling failure handling and resource stickiness
Configure storage
Clustered services often depend on shared storage, and that storage must be presented to every relevant node correctly before any cluster filesystem is possible.
- Presenting shared block devices consistently across nodes
- Preparing the storage layer that the clustered filesystem will sit on
Configure GFS2 filesystems
GFS2 is Red Hat's clustered filesystem, designed for simultaneous access from multiple nodes. Creating one correctly requires the supporting cluster infrastructure to already be healthy.
- Creating a GFS2 filesystem sized for the number of cluster nodes that will mount it
- Mounting it under cluster control so it behaves properly across nodes
Grow a GFS2 filesystem
Red Hat displays this as its own entry. Extending a live clustered filesystem is a distinct skill from creating one, and it is the kind of task where careful sequencing matters.
- Extending the underlying storage first
- Expanding the mounted filesystem to use the new space
Note the dependency chain: fencing, storage, and cluster formation are prerequisites for the fail-over and GFS2 objectives. A weakness early in the chain tends to cascade, so a shaky cluster foundation costs you time on everything built above it.
Why "Survives Reboot" Changes How You Practice
Many candidates prepare by completing a lab and moving on the moment pcs status looks green. The EX436 requirement that configurations survive reboot means that approach leaves a gap. A cluster that looks healthy in your current session may not come back cleanly after a full restart if services were not enabled to start, if resources depend on something that was only mounted manually, or if a constraint leaves a resource unable to start anywhere.
Build this into your timing as well. A full restart consumes minutes of your three hours, so plan to verify persistence deliberately rather than discovering problems at the last moment. Also resist the urge to rely on memorized command sequences; the outcome-based grading rewards understanding why each step is needed. The High Availability Clustering Cheat Sheet is a useful quick reference once you understand the underlying behavior, but it works best as a refresher, not a substitute for lab time.
Prerequisites, RH436, and the Experience Gap
There are no mandatory prerequisites. RHCSA or RHCE is recommended, but neither credential is required to sit EX436. In practice, that recommendation matters: clustering assumes you are already comfortable with RHEL system administration, including storage, networking, services, and troubleshooting. Candidates who skip that foundation often find they are fighting the operating system rather than the cluster. See High Availability Clustering Requirements for the full eligibility picture.
Training works similarly. RH436, Red Hat's High Availability Clustering course, is recommended, but class attendance is optional; equivalent experience is acceptable preparation. The course is a four-day offering built around RHEL 8.3. That detail deserves care:
| Source | What it tells you | What it does not establish |
|---|---|---|
| EX436 exam page | The live exam follows the most recent available product version without naming a release in its main description | A specific RHEL release label for your booked session |
| RH436 course page | Four-day preparation curriculum based on RHEL 8.3 | Exhaustive exam coverage, an official domain count, or the exam timer |
| Detailed exam outline | The nine published objectives; takes precedence over the shorter competency summary | Objective weighting or task counts |
The practical takeaway: do not label EX436 as "RHEL 8.3" just because the course is, and do not assume older RHEL labs match what you will face. Confirm the product version for your booking and practice on the closest matching release. Our High Availability Clustering Training page explains training options in more detail.
Booking, Cost, Retakes, and Renewal Mechanics
Price and scheduling
The program-wide standard exam list price is USD500. That figure is a program-level list price, not an EX436-specific checkout quotation, and the regional booking-cart price controls what you actually pay. Delivery options (remote, testing center, or classroom) are subject to booking availability. For the wider cost picture, including training, read High Availability Clustering Certification Cost, and for scheduling logistics see High Availability Clustering Exam Dates.
Remote delivery requirements
If you test remotely, expect additional preparation. Candidates need a LiveUSB, a successful compatibility test, and must pass the required identity and hardware checks. Run the compatibility check well ahead of exam day rather than the night before.
Retakes
Eligible unsuccessful first individual attempts receive one free retake under Red Hat's training policies, subject to purchase or subscription eligibility periods and scheduling restrictions. Read the policy for your specific purchase before relying on it.
Results timing
Published guidance differs: the exam page says results usually arrive in about three U.S. business days, while the program guide allows five business days. Plan around the longer window. Results are reported as total scores, and the handbook also describes objective-area feedback, but neither provides task-by-task performance details, so you will not receive a line-by-line account of what went wrong.
Renewal
Certifications are current for three years. You can renew before expiry by retaking the original exam or by earning qualifying same-level or higher-level credentials under the current framework. For credentials earned before the framework change, Red Hat's FAQ says updated renewal and mapping rules apply to the active transcript after you pass a new exam following May 11, 2026.
Sequencing Your Preparation by Objective
Because the objectives build on each other, schedule them in dependency order rather than studying them as an unordered list. One sensible arrangement, assuming a lab environment of several RHEL nodes with shared storage:
Cluster formation and fencing
- Build, destroy, and rebuild a cluster repeatedly until it is routine
- Configure and deliberately trigger fencing; fencing underpins nearly everything later
Logging, monitoring, and fail-over services
- Learn to read status and logs fluently before you need them under time pressure
- Build grouped resources and prove fail-over by disrupting a node
Service behavior and storage
- Work through placement and ordering constraints and failure handling
- Prepare shared storage consistently across nodes
GFS2 creation, growth, and full rehearsals
- Create, mount, and then grow a GFS2 filesystem
- Run timed, end-to-end scenarios that finish with a full reboot check
This ordering is a suggestion, not an official plan, and you should stretch or compress it based on your RHCSA-level comfort. For a fuller preparation framework, see the High Availability Clustering Study Guide. When you want to check your readiness against original practice material, the High Availability Clustering practice test site offers question sets written to test the underlying concepts. Practice questions and labs should always be original; avoid any source claiming to reproduce actual exam content, which also would not reflect a hands-on, outcome-graded exam well.
Where the Skill Set Gets Used
The competencies EX436 certifies map to roles where uptime of critical services is a core responsibility: Linux systems administration, infrastructure and platform operations, and site reliability work in environments that run RHEL. Think of databases, application tiers, and shared-storage workloads that cannot tolerate a single node failure. Employers value the underlying judgment, such as when to fence, how to place resources, and how to avoid split-brain, more than the certificate itself.
Be realistic about outcomes. A credential can strengthen a profile, but it does not guarantee employment or any specific earnings, and we do not quote salary figures here without attributable market evidence. If you are weighing the return on the investment, our analyses in Is the High Availability Clustering Certification Worth It? and High Availability Clustering Jobs discuss the market side in more depth, and the salary guide addresses compensation separately.
Key Takeaway
Prepare as an operator, not a memorizer. The grader checks that your cluster works, and keeps working after a reboot. Practice every objective as a complete build-verify-restart cycle, and sequence your study so that fencing, storage, and cluster formation are solid before you tackle fail-over and GFS2.
Frequently Asked Questions
You need to pass exam EX436. It is a single three-hour, hands-on exam covering RHEL High Availability Add-On administration, with outcomes graded against objective criteria and configurations required to survive reboot.
No. RHCSA or RHCE is recommended and RH436 or equivalent experience is recommended, but neither the credentials nor the class are mandatory. Class attendance is optional, though the underlying RHEL administration skills are genuinely needed.
The program-wide standard exam list price is USD500, but that is not an EX436-specific checkout quote. The regional booking-cart price controls what you pay, so confirm it at booking.
Eligible unsuccessful first individual attempts receive one free retake under Red Hat's training policies, subject to purchase or subscription eligibility periods and scheduling restrictions. Check the policy terms that apply to your purchase.
Certifications are current for three years. Renew before expiry by retaking the original exam or earning a qualifying same-level or higher-level credential under the current framework. Because Red Hat's pages are not fully consistent, verify against the current handbook, the dated FAQ, and your active transcript.