- How to Read the 64-Entry Objective List
- Cluster Administration, Console, CLI and Troubleshooting
- Declarative Resource Management and Application Deployment
- Authentication and Authorization
- Networking, Routes, TLS and Network Policies
- Developer Self-Service, Quotas and Project Templates
- Managing Operators
- Application Security, Service Accounts and SCCs
- Jobs and Cron Jobs
- Exam Format, Fees and Policies
- Sequencing the Domains Over Your Prep Weeks
- Frequently Asked Questions
- The 64 "domains" are a flat list of broad labels and individual tasks from Red Hat, not 64 official weighted domains.
- EX280 is a three-hour, hands-on OpenShift 4.22 assessment with product documentation supplied and no outside help.
- Configurations must stay functional across the normal platform lifecycle without manual restoration, so persistence matters as much as getting it working once.
- Kustomize overlays, Helm, jobs and cron jobs appear in the detailed outline but not in the shorter nine-heading summary.
How to Read the 64-Entry Objective List
Red Hat's published objectives for the Red Hat Certified System Administrator in OpenShift exam (EX280) arrive as a flat list. Some entries are umbrella labels such as "Manage OpenShift Container Platform" or "Configure application security." Others are single tasks such as "Modify user passwords" or "Configure Kubernetes cron jobs." Counted line by line, the retrieved list contains 64 entries, and this article walks through all of them in source order.
Red Hat also publishes a shorter competency page listing nine broader headings. All nine are retained inside the detailed list, but the detailed outline adds material that the summary does not spell out: Declarative Resource Management, YAML, Kustomize overlays, Helm, jobs and cron jobs. Candidates who study from the nine-heading summary alone will miss those. For the wider picture of what the credential covers, see What Is EX280 Certification?
Another caution: multiple exam versions are in use, and this walkthrough follows the objective list published against OpenShift Container Platform 4.22. Red Hat also maintains a document titled "Red Hat Certification Exam Objectives by Version," but it could not be retrieved for this article, so nothing here is inferred from it. Check your booking or learning-management-system record to see which version you were assigned before you commit study time. Older 4.14-era quiz syllabi and objectives from other Red Hat exams should not be mixed in.
Cluster Administration, Console, CLI and Troubleshooting
The first block of entries (Domains 1 through 15) establishes the day-to-day administrator toolkit. It is the foundation for everything that follows, because nearly every later task is performed through either the web console or the oc command line.
Domains 1-3: Manage OpenShift Container Platform, Web Console, Command Line
You are expected to administer and configure a cluster through both interfaces, not just the one you prefer.
- Know which tasks are faster in the console (browsing events, viewing operator status) and which are faster with
oc(bulk changes, scripting, exporting YAML). - Practice switching between them mid-task without losing context.
Domains 4-6: Projects and Images
Create and delete projects, locate and examine container images, and identify images by tags and digests.
- Understand why a digest pins an exact image while a tag can move.
- Be comfortable inspecting an image before deploying it, since the right reference matters in later deployment tasks.
Domains 7-9: Querying, Importing/Exporting, and Examining Resources
Query, format and filter attributes of Kubernetes resources; import, export and configure resources; examine resources and cluster status.
- Output formatting (JSONPath, custom columns, YAML/JSON output) turns a slow hunt into a one-line answer.
- Exporting a live resource to a manifest is a common starting point for declarative work later in the list.
Domains 10-13: Events, Logs, Health and Troubleshooting
Monitor cluster events and alerts, view logs, assess cluster health, and troubleshoot common container, pod and cluster events and alerts.
- Build a repeatable diagnostic order: events first, then pod status, then logs, then node and operator health.
- These skills pay off on every other domain, because a task that fails silently usually shows its cause in events or logs.
Domains 14-15: Documentation and the Technologist Baseline
"Use product documentation" is an explicit objective. The exam supplies relevant product documentation, so navigating it quickly is a graded skill in practice, not a courtesy. Domain 15 states that you should be prepared to perform all tasks of a Red Hat Certified Technologist in OpenShift, so do not treat the entry-level material as skippable.
Declarative Resource Management and Application Deployment
Domains 16 through 30 cover how applications get onto the cluster and how they are exposed. This is where the detailed outline diverges most from the nine-heading summary, adding YAML manifests, Kustomize and Helm.
Manifests, Kustomize and Updates (Domains 16-21)
- Declarative Resource Management and Working with resource manifests: read, write and correct YAML for core resources.
- Deploy applications from YAML resource manifests and update application deployments: apply changes and understand how rollouts behave.
- Deploy applications using Kustomize and work with Kustomize overlays: apply a base plus an environment-specific overlay, and recognize what each patch changes.
Configuration, Templates and Helm (Domains 22-25)
Secrets and configuration maps feed configuration into workloads, while "Deploy applications" and "Deploy applications from templates and Helm charts" cover the other common delivery mechanisms. Candidates comfortable only with raw manifests should deliberately practice templates and Helm, since they are listed separately.
Managing Workloads and Exposure (Domains 26-30)
- Manage application deployments and work with replica sets: scaling, ownership and what controls pod counts.
- Labels and selectors: the glue that binds services, replica sets and network policies to pods. A selector typo causes many "it deploys but nothing works" failures.
- Configure services and expose applications to external access: connect a stable internal endpoint, then publish it.
Key Takeaway
Practice the same application delivered four ways: a raw manifest, a Kustomize base with an overlay, a template, and a Helm chart. Being able to switch methods fluently is exactly what this block of the outline asks for.
Authentication and Authorization
Domains 31 through 36 form the identity block, and they are unusually concrete: the HTPasswd identity provider is named explicitly.
Domains 31-36: Identity, Users, Groups and Permissions
- Configure the HTPasswd identity provider: build the credentials file, store it as a secret, and wire it into the cluster's OAuth configuration.
- Create and delete users; modify user passwords: understand that user records, identities and the password file are separate pieces, so deleting one does not necessarily clean up the others.
- Create and manage groups; modify user and group permissions: role bindings at cluster and project scope, and how group membership inherits access.
Because the exam expects configurations to remain functional across the normal platform lifecycle, an identity provider change must actually be applied correctly to the OAuth configuration and survive the resulting rollout, not merely appear to work for a moment.
Networking, Routes, TLS and Network Policies
Domains 37 through 46 make up the largest thematic cluster in the list, and the entries are tightly related. It is worth studying them as one system rather than ten separate tasks.
| Objective entry | What to be able to do |
|---|---|
| Configure network security / Configure networking components | Understand how traffic flows between pods, services and the outside world. |
| Troubleshoot software defined networking | Isolate whether a failure is DNS, service selection, policy or routing. |
| Create and edit external routes / Control cluster network ingress | Publish HTTP applications and manage how traffic enters the cluster. |
| Secure external and internal traffic using TLS certificates | Apply and verify certificates on edge, passthrough or re-encrypt style routes and internal paths. |
| Configure application network policies | Allow only intended traffic between workloads and namespaces. |
| Expose non-HTTP/SNI applications; configure a load balancer service; configure external application access | Reach services that routes alone do not cover. |
The pairing of routes with the separate non-HTTP/SNI entry is a useful signal: routes cover typical web traffic, while load balancer services and related techniques cover everything else. Network policies reward careful reading, because an overly strict policy blocks legitimate traffic and a missing one leaves workloads exposed. For a candid look at where candidates tend to struggle, see How Hard Is the EX280 Exam?
Developer Self-Service, Quotas and Project Templates
Domains 47 through 52 cover running a shared cluster responsibly: letting developers create their own projects while keeping resource use bounded.
Domains 47-52: Self-Service and Resource Governance
- Enable developer self-service: control who can create projects and what they receive by default.
- Configure cluster resource quotas and project quotas: cap aggregate consumption across multiple projects or within one.
- Configure project resource requirements and limit ranges: set per-container requests and limits and defaults, and understand how they interact with quotas. A quota that demands resource requests will reject pods that omit them, which is a classic troubleshooting scenario.
- Configure project templates: customize what a new project contains automatically, such as quotas, limit ranges or network policies.
Managing Operators
Domains 53 through 56 cover the operator lifecycle: manage OpenShift operators, install an operator, uninstall an operator and delete an operator. Notice that uninstall and delete are listed as separate entries. Removing a subscription or cluster service version is not the same as cleaning up the custom resources, definitions and namespaces an operator left behind, and the outline treats those as distinct skills.
- Know how to find and install an operator from the catalog and confirm it reached a healthy state.
- Understand what remains after removal and how to verify a clean state.
- Use operator and cluster health indicators from the earlier troubleshooting domains to confirm each step worked.
Application Security, Service Accounts and SCCs
Domains 57 through 62 treat workload security as its own area.
Domains 57-62: Securing Applications
- Configure and manage service accounts: workloads authenticate to the cluster as service accounts, and permissions attach to them.
- Run privileged applications and manage permissions using security context constraints: when a pod is rejected for its security context, the fix is usually granting the right constraint to the right service account, not loosening everything cluster-wide.
- Create and apply secrets to manage sensitive information: create secrets and consume them as environment variables or mounted volumes.
- Configure application access to Kubernetes APIs: give an application only the API permissions it needs through a service account and role binding.
The recurring principle is least privilege. Whenever a task requires elevated access, grant the narrowest permission that satisfies it and confirm it with the relevant verification command.
Jobs and Cron Jobs
The final two entries, Domains 63 and 64, are "Deploy jobs to perform one-time tasks" and "Configure Kubernetes cron jobs." They are short on the page but easy to underestimate. Know the difference between a job (run to completion) and a cron job (scheduled creation of jobs), how to read a schedule expression, and how to check whether a run succeeded. Because these appear only in the detailed outline, candidates who prepared from the broader nine-heading summary are the most likely to be surprised by them.
Exam Format, Fees and Policies
The EX280 exam is a three-hour, hands-on assessment performed on OpenShift 4.22, with relevant product documentation supplied and no outside assistance. Rather than answering multiple-choice items, you configure and repair a live environment, and your result reflects whether the required configurations actually work and remain functional across the normal platform lifecycle without manual restoration.
- Prerequisites: none are strictly required. RH124-level skills, the DO180 and DO280 courses or equivalent work experience, and container familiarity are recommended, and RHCSA is strongly recommended. Details are in EX280 Requirements.
- Cost: Red Hat's program-wide standard exam list price is USD 500, but the regional price shown in your booking cart controls. See EX280 Certification Cost for the full breakdown.
- 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 eligibility periods and scheduling restrictions.
- Results: the exam page says usually three U.S. business days, while the program guide allows five business days. Plan around the longer window. Total scores are reported, and the handbook also describes objective-area feedback, but neither provides task-by-task detail.
- Validity and renewal: certifications are current for three years, and renewal is possible through the original exam or qualifying same-level or higher-level credentials under the current framework. Older renewal pages use different terminology, so consult the current handbook and your active transcript. See EX280 Exam Dates for scheduling.
Specific passing scores and pass-rate statistics are not asserted here because they are not verified; for the current state of that question, read EX280 Passing Score and EX280 Pass Rate. EX280 also leads into the RHCE in OpenShift path when combined with EX380, though that does not change the scope of the exam you are sitting.
Sequencing the Domains Over Your Prep Weeks
Rather than a generic schedule, order your study by dependency: later domains assume you can already navigate, troubleshoot and deploy. This is one possible arrangement for a candidate who already has RHCSA-level Linux skills.
Navigation and diagnostics (Domains 1-15)
- Console and
ocfluency, output filtering, events, logs, cluster health. - Practice finding procedures in the product documentation under a timer.
Declarative deployment (Domains 16-30)
- Manifests, Kustomize overlays, templates, Helm, secrets, config maps, services.
Identity and networking (Domains 31-46)
- HTPasswd, users, groups, role bindings; routes, TLS, network policies, load balancer services.
Governance, operators, security, jobs (Domains 47-64)
- Quotas, limit ranges, project templates, operator lifecycle, service accounts, SCCs, jobs and cron jobs.
Spend your final days on timed, integrated practice, since the real exam mixes areas freely. Our EX280 practice tests are original and help you rehearse that mixing, while the EX280 study guide and cheat sheet support review. Any practice material you use should be original, never reconstructed from the actual exam. If you want to weigh the effort against the payoff, see Is the EX280 Certification Worth It? and EX280 Jobs.
Frequently Asked Questions
No. The retrieved Red Hat objective list contains 64 flat entries that mix broad labels and individual tasks. Red Hat does not define 64 official domains, and this guide infers no hierarchy or weighting from the list.
No. It is a three-hour, hands-on assessment on OpenShift 4.22 in which you configure and troubleshoot a live environment, with relevant product documentation supplied and no outside assistance.
The detailed outline includes Kustomize overlays, Helm, jobs and cron jobs, which the shorter nine-heading competency summary does not spell out. Studying only that summary can leave gaps in those areas.
Multiple exam versions are in use, so confirm the designated version in your booking or learning-management-system record. This guide follows the OpenShift 4.22 objective list and does not assume any version-specific content beyond it.
None is strictly required. RHCSA is strongly recommended, along with RH124-level skills, DO180 and DO280 or equivalent experience, and container familiarity. See the requirements guide for details.