- How the EX436 Outline Is Structured
- Domains 1-2: Building the Cluster and Fencing It
- Domains 3-4: Logging and Monitoring
- Domains 5-6: Fail-Over Services and Service Behavior
- Domains 7-9: Storage and GFS2
- What the Hands-On Format Demands
- Sequencing Your Preparation by Domain
- Fees, Retakes, Renewal and Delivery
- Frequently Asked Questions
- The EX436 outline lists nine unweighted objectives; Red Hat does not publish percentage weights for them.
- The exam is one three-hour hands-on section on RHEL High Availability Add-On administration.
- Configurations must survive a reboot, so test persistence before you stop working.
- Fencing is the objective that quietly breaks every other cluster task if it is wrong.
How the EX436 Outline Is Structured
The Red Hat Certified Specialist in High Availability Clustering exam (EX436) publishes its objectives as a list of first-level study points. This guide treats those entries as nine domains, but one caveat matters: nine is the count of lines Red Hat displays, not an issuer-declared "official" domain count, and the objectives carry no percentage weighting. Anyone quoting a "domain weight" for this exam is making it up.
Two quirks of the published outline are worth knowing before you plan. First, logging/monitoring and monitoring appear as separate entries, so they are split here into Domains 3 and 4. Second, growing a GFS2 filesystem is displayed on its own line rather than folded into the GFS2 configuration objective. Red Hat's shorter seven-item competency summary on the certification overview page exists too, but the detailed exam outline takes precedence when the two differ.
For the bigger picture of what the credential is and how it fits a career, see What Is High Availability Clustering Certification?, and for eligibility details see High Availability Clustering Requirements 2026.
Domains 1-2: Building the Cluster and Fencing It
Domain 1: Configure a high-availability cluster
This is the foundation. You are expected to take bare RHEL systems and produce a functioning, authenticated, running cluster using the High Availability Add-On tooling.
- Install the required cluster packages and enable the services on every node
- Authenticate nodes to each other and create the cluster with the pcs interface
- Understand quorum, including how node counts and votes affect whether the cluster keeps running
- Open the necessary firewall services so nodes can actually talk to each other
- Verify membership and state from the command line before moving on
Candidates lose time here on small environmental problems, not conceptual ones: a firewall service left closed, a service not enabled to start at boot, name resolution between nodes that does not match what the cluster was told. Because everything later depends on this domain, build a repeatable routine for standing up a cluster and rehearse it until it is boring.
Domain 2: Configure cluster fencing
Fencing is how a cluster guarantees that a failed or unresponsive node is genuinely dead before its resources start elsewhere. Without it, shared storage can be corrupted by two nodes writing at once.
- Create and configure fence devices appropriate to the environment you are given
- Attach fencing topology so the right device acts on the right node
- Test fencing deliberately instead of assuming it works
- Understand the relationship between fencing, quorum and resource recovery
Fencing deserves outsized attention even though the outline is unweighted. A misconfigured fence device does not usually fail loudly; it surfaces later as resources that refuse to move, or storage services that block. Treat a clean fence test as a gate you must pass before attempting anything in the later domains.
Domains 3-4: Logging and Monitoring
Domain 3: Configure cluster logging and monitoring
Red Hat lists logging and monitoring as its own objective. Expect to be asked to make cluster behavior observable and diagnosable, not just functional.
- Locate and interpret cluster logs when something misbehaves
- Adjust logging so useful diagnostic detail is captured
- Read status output to distinguish healthy, degraded and failed states
Domain 4: Configure cluster monitoring
The separately listed monitoring objective is about the cluster watching its own resources and reporting on them.
- Configure resource monitor operations, including interval and timeout behavior
- Understand what happens when a monitor operation fails
- Use cluster status tooling to confirm monitoring is actually active
The overlap between these two domains is real, so study them together. The practical skill is diagnostic: given a cluster that is not behaving, can you find out why from logs and status output quickly? That same skill rescues you in every other domain when a task does not work the first time.
Domains 5-6: Fail-Over Services and Service Behavior
Domain 5: Configure a clustered fail-over service
This is where a cluster earns its keep: a service that moves between nodes automatically and remains reachable.
- Create resources and group them so they start, stop and move together
- Combine typical building blocks such as a floating IP address, a filesystem and an application service
- Verify fail-over by moving the service and by simulating a node problem
- Confirm the service is reachable by clients after it moves
Domain 6: Configure cluster service behavior
Beyond simply running, you must control how, where and in what order services behave.
- Constraints for location, ordering and colocation
- Resource stickiness and preferred-node behavior
- Recovery and failure-handling settings, including what the cluster does after repeated failures
- Resource options that change start, stop and migration behavior
The trap in Domain 6 is that constraints interact. An ordering constraint without a matching colocation, or a location preference that fights stickiness, can leave a service stopped or on the wrong node with no obvious error. Practice reading the resulting placement, not just entering the commands. If you want to gauge how this compares with other hands-on credentials, read How Hard Is the High Availability Clustering Exam?
Domains 7-9: Storage and GFS2
Domain 7: Configure storage
Shared storage is the substrate for the clustered filesystems that follow.
- Prepare shared block devices so every node sees the same storage
- Use clustered logical volume management so volumes can be activated safely across nodes
- Understand how locking and fencing protect shared storage from concurrent corruption
Domain 8: Configure GFS2 filesystems
GFS2 is the shared-disk filesystem used when several nodes must mount and write the same data simultaneously.
- Create a GFS2 filesystem with an appropriate journal count for the nodes that will mount it
- Choose and set the lock table name so it matches the cluster
- Mount the filesystem across nodes, and make that mount managed by the cluster instead of left to a manual command
- Understand the dependency on cluster locking and the distributed lock manager
Domain 9: Grow a GFS2 filesystem
Red Hat displays growth as its own objective, so treat it as a distinct skill.
- Extend the underlying clustered volume first
- Grow the mounted filesystem to use the new space
- Account for the journal needs of any node you add
- Verify the new size from more than one node
These three domains are strongly sequential: a GFS2 filesystem is only as reliable as the storage and fencing beneath it. A comparison of how the nine objectives group helps you plan:
| Cluster area | Domains | Primary skill | Common failure mode |
|---|---|---|---|
| Foundation | 1, 2 | Build the cluster, make it safe with fencing | Closed firewall services, untested fence devices |
| Observability | 3, 4 | Logging, status, monitor operations | Monitoring configured but never verified |
| Services | 5, 6 | Fail-over and placement behavior | Conflicting constraints, not testing after reboot |
| Shared storage | 7, 8, 9 | Clustered volumes, GFS2, growth | Wrong lock table or journal count, unmanaged mounts |
What the Hands-On Format Demands
EX436 is a single three-hour hands-on section covering RHEL High Availability Add-On administration. There are no multiple-choice items to guess at; you are given tasks on live systems and results are evaluated against objective criteria. Two consequences follow. First, partial progress that does not produce the required end state earns nothing, so finishing one task cleanly beats half-finishing three. Second, speed matters because three hours must cover a full cluster build plus services and storage.
Red Hat does not publish task counts or a pass mark in the sources used for this guide, and neither does this article. For what is and is not known about scoring, see High Availability Clustering Passing Score 2026 and High Availability Clustering Pass Rate 2026. The exam page describes total scores, while the handbook also describes objective-area feedback; neither gives task-by-task detail, so you will not receive a breakdown of exactly which command went wrong.
The exam page does not specify an exam-specific documentation allowance. Do not rely on being able to look things up; verify the rules for your booked session and be ready to work from built-in help and your own fluency.
Sequencing Your Preparation by Domain
One short plan, tied to how the domains depend on each other, is more useful than a generic schedule. Build in dependency order and finish each stage with a reboot test.
Domains 1-2: Cluster and fencing
- Rebuild a multi-node cluster from scratch several times
- Configure and deliberately trigger fencing
Domains 3-4: Diagnostics
- Break things on purpose and diagnose from logs and status
- Tune monitor operations and watch failure responses
Domains 5-6: Services
- Build resource groups, then layer constraints and stickiness
- Reboot nodes and confirm placement persists
Domains 7-9: Storage and GFS2
- Create clustered volumes, GFS2 and cluster-managed mounts
- Grow the filesystem and verify from every node
Then run full timed rehearsals using original practice scenarios you write yourself or find on the practice test site; never rely on supposed recalled exam content. For a broader preparation framework, see the High Availability Clustering Study Guide 2026, and keep the High Availability Clustering Cheat Sheet handy for last-minute command review.
Fees, Retakes, Renewal and Delivery
Red Hat's program-wide standard exam list price is USD 500, but the regional booking-cart price controls what you actually pay, so treat that figure as a reference rather than an exam-specific quotation. Full cost context is in High Availability Clustering Certification Cost 2026.
- Delivery: Remote, testing-center and classroom delivery are subject to booking availability. Remote candidates need LiveUSB, a successful compatibility test and the required identity and hardware checks.
- Retake: 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.
- Results: The exam page says usually three U.S. business days; the program guide allows five business days. Plan for the longer window.
- Currency: Certifications are current for three years. Renew before expiry through the original exam or qualifying same-level or higher-level credentials under the current framework.
On prerequisites: RHCSA or RHCE is recommended, but neither is mandatory. The RH436 course is the recommended preparation, or equivalent experience, and class attendance is optional. RH436 is a four-day course, but its topics are preparation curriculum and do not establish exhaustive exam coverage. Career-side questions are covered in High Availability Clustering Jobs and Is the High Availability Clustering Certification Worth It?, which should be read with the understanding that certification does not guarantee earnings or employment.
Frequently Asked Questions
The published outline lists nine first-level objectives, which this guide treats as nine domains. Red Hat does not describe nine as an official domain count, and the objectives are unweighted, so no percentage split exists.
No. It is one three-hour hands-on section where you configure RHEL High Availability Add-On systems. Results are graded against objective criteria, and configurations must survive a reboot.
Neither is mandatory. RHCSA or RHCE is recommended, and RH436 or equivalent experience is recommended. Class attendance is optional, so strong hands-on cluster experience can substitute.
The exam page does not specify an exam-specific documentation allowance. Verify the rules for your booked session and prepare to work primarily from your own command fluency and built-in help.
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, and confirm details against your active transcript.