What Is High Availability Clustering?

What the Credential Is, and What It Is Not

The Red Hat Certified Specialist in High Availability Clustering is a performance-based credential issued by Red Hat, Inc. and earned by passing exam EX436. It validates that you can build, configure, and maintain a high-availability cluster using the Red Hat Enterprise Linux High Availability Add-On. It is a practical credential: you do not choose answers from a list, you configure real systems and Red Hat grades the outcome.

The phrase "High Availability Clustering" is a natural short label for this certification, not an issuer acronym. Other credentials in the industry use similar wording, so it is worth being precise: everything in this article concerns the Red Hat specialist certification and exam EX436 only. If you want a broader orientation to the terminology, the sibling pages on the meaning of High Availability Clustering and the certification itself cover the naming questions in more depth.

High Availability Clustering in Plain Terms

A high-availability cluster is a group of servers (nodes) that cooperate so a service keeps running even when an individual machine fails. Instead of a single web server, database, or file service tied to one host, the cluster software monitors the service, detects failure, and restarts or relocates the service on a healthy node. The goal is to minimize downtime without a human intervening at 3 a.m.

Three ideas underpin almost everything on the exam:

• Membership and quorum. Nodes must agree on who is in the cluster. Quorum prevents two halves of a split cluster from both believing they are in charge.
• Fencing. When a node misbehaves or becomes unreachable, the cluster must be certain it is truly offline before recovering its resources elsewhere. Fencing forcibly isolates or powers off the suspect node so shared data is never written by two nodes at once.
• Resources and constraints. Services are modeled as resources, grouped, ordered, and placed with rules so they start in the right sequence on the right nodes.

How EX436 Is Delivered and Graded

EX436 is a single, hands-on section lasting three hours. You work on live Red Hat Enterprise Linux systems and complete administration tasks covering the High Availability Add-On. Results are graded against objective criteria, meaning the grader checks whether the system is in the required state rather than judging how you got there.

The most important format rule is persistence: configurations must survive a reboot. A cluster resource that works until the node restarts, a mount that disappears after reboot, or a service that is running but not enabled will not satisfy a grading check. Build the habit of verifying state after a restart during practice.

Scoring detail is limited. The exam page describes total scores, while the Red Hat handbook also describes feedback by objective area; neither provides task-by-task performance breakdowns. Results typically arrive within about three U.S. business days per the exam page, though the program guide allows up to five business days. For a deeper look at scoring, see the page on the passing score, and note that Red Hat does not publish a verified pass mark or pass-rate figure that we can cite, which is why the pass rate discussion stays qualitative.

The Nine Published Objectives

Red Hat publishes the exam's study points as a list of objectives. This site tracks nine first-level entries, preserving the separate logging/monitoring lines and the separately displayed GFS2 growth entry. These are unweighted objectives; nine is the count of listed entries, not an official percentage-weighted domain structure. The detailed exam outline takes precedence over the shorter competency summary on Red Hat's certification page. For a full breakdown, see the complete guide to all nine content areas.

What Hands-On Mastery Looks Like

Because the exam grades outcomes, your goal is fluency: building a complete service from nothing, quickly and correctly, without hesitating over syntax. A representative workflow that touches many objectives at once looks like this, described conceptually rather than as a script to memorize:

1. Stand up the cluster and confirm all nodes are members with quorum.
2. Configure fencing and prove it works before building anything on top.
3. Prepare shared storage and, where required, a GFS2 filesystem mounted on the right nodes.
4. Create the service resources, order and group them, and add constraints.
5. Force a failure, watch the service relocate, and read the logs to confirm what happened.
6. Reboot nodes and confirm everything returns to the intended state.

Troubleshooting is part of the job

Expect situations where something is almost right: a resource that will not start, a constraint that pins a service to the wrong node, a fence device that refuses to authenticate. The ability to read cluster status, interpret log output, and clear failure states is as valuable as creating resources from scratch. If you want a gauge of how demanding this is, see the discussion in how hard the exam is.

Prerequisites and Preparation Paths

Red Hat recommends holding RHCSA or RHCE before attempting EX436, but neither is mandatory. The practical reason is that clustering assumes you are already comfortable with Linux administration: storage, networking, services, firewalls, and SELinux all show up while building a cluster. Attempting EX436 without that base means fighting two battles at once. The full eligibility picture is on the requirements page.

For structured preparation, Red Hat offers RH436, Red Hat High Availability Clustering, a four-day course. Red Hat recommends it or equivalent experience, and class attendance is optional. Treat RH436 as preparation curriculum rather than an exact map of the exam: its topics do not establish exhaustive exam coverage, and its listed RHEL version should not be treated as the EX436 release. The live exam page follows the most recent available product version without naming a release in its main description, so avoid assuming an older lab environment matches your booked session. More on training choices is in the training overview, and a full roadmap lives in the study guide.

Cost, Retakes, and Renewal Mechanics

Red Hat's program-wide standard exam list price is USD 500. That is a program-level figure, not an exam-specific checkout quotation; the regional price shown in your booking cart controls what you actually pay. See the cost breakdown for what else to budget.

• Delivery options: remote, testing-center, and classroom delivery exist, subject to availability. Remote candidates need a LiveUSB, a successful compatibility test, and the required identity and hardware checks.
• Retake policy: 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.
• Validity and renewal: certifications are current for three years. You can renew before expiry by retaking the exam or by earning a qualifying same-level or higher-level credential under the current framework.

Scheduling specifics, including availability windows, are covered in the exam dates guide.

Who Values This Credential

The certification speaks to people who keep critical Linux services running: systems administrators, platform and infrastructure engineers, site reliability engineers, and consultants supporting enterprise Red Hat environments. Organizations that run databases, file services, or line-of-business applications on RHEL, and that cannot tolerate a single-host outage, are the natural audience. Roles that appear on job boards for this skill set often pair clustering with broader Linux and storage responsibilities.

Be realistic about outcomes. A credential demonstrates verified skill; it does not guarantee a raise or a job. Any compensation figure you read should come from attributable market data, which is why the salary guide and the ROI analysis frame returns qualitatively and avoid promising certification-caused earnings.

Sequencing Your Study Around the Objectives

The objectives build on one another, so order matters more than volume. One sensible arrangement ties each phase to a dependency:

Fencing goes first because a half-working fence configuration poisons every later lab with confusing symptoms. Storage and GFS2 come last because they stack on a stable cluster. Finish each phase by rebooting and confirming persistence, then take timed practice on the main practice test site to check your recall of concepts, and use the cheat sheet for last-minute review.

Frequently Asked Questions