Red Hat OpenShift & RHCSA

A large share of the enterprise Kubernetes you will ever be paid to operate is not plain Kubernetes at all — it is Red Hat OpenShift (nobody publishes a market-share figure worth quoting, so treat any percentage you see, here or anywhere, as marketing). OpenShift is Kubernetes plus a router, plus an image build system, plus a security model that will reject your first Deployment on day one. Red Hat certifies that world with exams that are entirely hands-on: no multiple choice, no drag-and-drop, just a live cluster, a list of tasks, and a grader that checks whether the thing actually works. That is the same bargain the CNPE makes, which is why the practice transfers even if the product does not. This page covers the real ladder — RHCSA (EX200) underneath and the OpenShift credentials above it — with the names and codes as the vendor publishes them today, the ones that were quietly renamed, the one that is retired, and an honest account of when this whole track is the wrong place to spend your year.

What these credentials are and where they sit

☺ Like you’re 10: Red Hat has a staircase of practical tests. The bottom step is about Linux, and the steps above it are about their version of Kubernetes.

All of these are issued by Red Hat (part of IBM), the company that builds Red Hat Enterprise Linux and OpenShift. They are not neutral, industry-body credentials like the CNCF ladder over on the certifications hub; they certify Red Hat products. What makes them unusual — and worth a page here — is the format. Red Hat has run performance-based exams for over twenty years: you get a real environment and real tasks, and per the official EX200 page it is “a hands-on, practical exam that requires you to undertake real-world tasks.” The EX280 page adds the sting, and states it as a rule for the whole programme: “As with all Red Hat performance-based exams, configurations must persist after reboot without intervention.” A hack that works until the node restarts scores zero.

The ladder, as renamed in May 2026

Red Hat restructured its certification names on 11 May 2026, into five progressive levels: Technologist (optional, entry-level), System Administrator / Developer, Engineer, Specialist, and Architect. Per Red Hat’s own announcement, “only the names are changing, so the content, descriptions, and difficulty remain exactly the same” — but the names changed a lot, and almost every study guide, YouTube course and job advert you will read still uses the old ones. This table is the decoder ring.

The exam codes survived all of this, which is why professionals talk in codes. Say “EX280” and everybody knows what you mean; say “OpenShift Admin” and you have named three different things.

Which OpenShift credentials are actually live

Per Red Hat’s all certifications and exams listing at time of writing, the live OpenShift-adjacent set is: EX180 (Technologist in OpenShift), EX156 (Technologist in OpenShift Virtualization), EX280 (System Administrator in OpenShift), EX380 (Advanced System Administrator in OpenShift), and the Specialist tier — EX282 OpenShift Networking, EX316 OpenShift Virtualization, EX336 Automating OpenShift Virtual Machine Management, EX370 OpenShift Data Foundation, EX430 OpenShift Advanced Cluster Security, EX432 OpenShift Advanced Cluster Management (each of those Specialist titles is formally “Red Hat Certified Specialist in …”). Architect is the top of the new five-level structure, and Red Hat describes it as an Engineer-level credential plus three Specialist certifications in the same specialisation — for OpenShift that means EX280 and EX380 (which together make the Engineer level) and then three of the Specialist exams above: five exams, not two.

Two things a reader hunting for a “GitOps certification” needs to hear. First, there is no standalone Red Hat OpenShift GitOps exam. GitOps is an objective inside EX380 — the official study points literally include “Implement OpenShift GitOps,” “Deploy OpenShift GitOps operator” and “Create pipelines and repositories.” If someone sells you an “EX-something GitOps cert,” check the vendor list. Second, the old multicluster exam is gone.

Why a platform engineer takes it — and when to skip it

☺ Like you’re 10: Brilliant if your company runs OpenShift. Mostly a waste if it does not.

The case for is narrow and strong. If your employer runs OpenShift — and a great many banks, insurers, telcos and governments do, because they bought a supported Kubernetes with a phone number attached — then EX280 is the most direct proof you can do the job, and hiring managers in those shops read it instantly. It also fixes a specific, common gap: engineers who are fluent in upstream Kubernetes and then flounder on OpenShift because their Deployment will not start, their Ingress does not resolve, and nobody told them about SecurityContextConstraints. Two weeks of EX280 prep cures that permanently.

RHCSA has a separate, quieter case. Platform engineering has drifted so far up the stack that a lot of people can write a Kubernetes operator and cannot read a journalctl output, resize a logical volume, or explain why SELinux ate their bind mount. Every node in every cluster is still a Linux box. RHCSA is the most respected forcing function in the industry for actually learning that — and, usefully, it is now a choice rather than a toll gate: the current EX280 page lists it as “strongly recommended but not required,” alongside RH124, DO180 and DO280 as recommended-not-required preparation. (Older material describes RHCSA as a hard prerequisite for the OpenShift track; we could not pin down the date Red Hat dropped it, only that today’s page does not enforce it.)

The honest case against

Now the part most cert pages skip. This is vendor-locked knowledge, and a large share of it does not travel. Routes, SCCs, ImageStreams, BuildConfigs, oc adm and the OperatorHub console are OpenShift-shaped; the concepts behind them generalise, but the muscle memory does not. If your platform is EKS, GKE, AKS or self-managed upstream, EX280 teaches you a dialect nobody around you speaks, and the same study time spent on the CNPE or CKA maps directly onto the cluster you actually run.

It also overlaps heavily with things you may already hold. If you have CKA, a good half of EX280 — RBAC, quotas and limit ranges, network policies, jobs and cron jobs, reading logs and events, troubleshooting pods — is material you have already been examined on, wearing an oc costume. What is genuinely new is a shortlist: Routes, SCCs, ImageStreams and Builds, Projects and project templates, Operators via OLM, and the HTPasswd identity provider. That shortlist is a fortnight of reading, not a certification.

And there is a cost asymmetry nobody says out loud. Red Hat exams are priced at the enterprise end of the market, and every one of these credentials expires after three years. Be fair about the comparison, though: the window is not the Red Hat weakness. Linux Foundation Kubernetes certifications earned from April 2024 onward are current for two years, not three, so Red Hat’s three-year clock is the more generous one — it is the per-exam price and the sheer number of exams in the Architect path that make badge-collecting here an expensive hobby.

What it actually tests — the official objectives

☺ Like you’re 10: Red Hat publishes the exact list of things you must be able to do. It does not publish how many marks each is worth.

Say this plainly: Red Hat does not publish percentage weights for these exams. There are no “Domain 2 — 25%” numbers to memorise as there are for the CNPE. The official pages give objective headings with sub-bullets and nothing more. Any weighting table you find on a training site is invented; treat the whole objective list as equally examinable.

EX280 — the OpenShift administration objectives

Transcribed from the official EX280 page (based on OpenShift Container Platform 4.18 at time of writing). Nine objective groups:

Notice two things a platform engineer should find striking. “Enable developer self-service” is an examined objective — quotas, limit ranges and project templates are exactly the guardrails our Self-Service & Golden Paths lesson calls the paved road. And EX280 explicitly absorbs the EX180 Technologist material, so the entry exam is a subset, not a detour.

EX380 — the advanced administration objectives

Worth printing in full, because this is the exam a platform engineer will recognise most. The official EX380 page (also OpenShift Container Platform 4.18 at time of writing) lists seven objective groups, again with no weights: configure and manage OpenShift authentication and identities; back up and restore applications with OADP; manage workloads with cluster partitioning; manage workloads with pod scheduling; implement OpenShift GitOps; manage cluster monitoring and metrics; and provision and inspect cluster logging. Under the GitOps heading the sub-bullets run: deploy the OpenShift GitOps operator; configure users, instances and integrations; configure Argo CD; create pipelines and repositories; integrate with Git, Helm, Kustomize and so on; and configure GitOps for both cluster administration and application management. That is a GitOps syllabus with a Red Hat badge on it.

EX200 — the RHCSA objectives

RHCSA is based on Red Hat Enterprise Linux 10 at time of writing, and its official study points fall into ten groups: understand and use essential tools; manage software (RPM repositories and packages, plus Flatpak); create simple shell scripts; operate running systems (boot targets, interrupting boot, processes, tuning profiles, journals, services); configure local storage (GPT partitions, physical volumes, volume groups, logical volumes, swap); create and configure file systems (VFAT/ext4/XFS, NFS, autofs, extending logical volumes, permission problems); deploy, configure and maintain systems (at, cron, systemd timers, services at boot, time clients, the bootloader); manage basic networking (IPv4/IPv6, hostname resolution, firewalld); manage users and groups; and manage security (firewall-cmd, default permissions, SSH key-based auth, and a solid block of SELinux — enforcing vs permissive, contexts, restoring defaults, port labels, booleans).

Two of those deserve a platform engineer’s attention specifically. Storage and LVM is the substrate under every PersistentVolume story in Storage & State. And SELinux is the reason a bind-mounted volume works on your laptop and mysteriously does not on a RHEL node — a debugging session that has cost more platform teams more hours than anyone admits.

Where OpenShift is not vanilla Kubernetes

☺ Like you’re 10: Same bike, extra bolted-on bits. Here are the bits that will trip you up on day one.

This is the section to read even if you never book an exam. Everything below is real OpenShift behaviour that surprises people arriving from upstream Kubernetes.

Projects, Routes and the router

A Project is, in Red Hat’s own documentation, “a Kubernetes namespace with additional annotations” — the same object, exposed to ordinary users as something they can create and own, with self-provisioning controlled centrally and a project template that can stamp quotas, limit ranges and network policies onto every new one. That template is a self-service primitive: read it next to Self-Service and it stops looking like trivia.

A Route is OpenShift’s ingress object, and it predates Kubernetes Ingress by years. The Ingress Operator implements the IngressController API and manages HAProxy-based ingress controllers; you can route traffic by specifying either OpenShift Route resources or Kubernetes Ingress resources, and Ingress objects get realised through the same router. Routes carry TLS termination modes directly on the object — edge, passthrough, re-encrypt — which is why an OpenShift engineer reaches for a Route where a GKE engineer reaches for an Ingress plus annotations. Note the sixth EX280 objective, “expose non-HTTP/SNI applications”: the router speaks HTTP and TLS-with-SNI, so a raw TCP service needs a LoadBalancer Service instead. Compare with Networking & Service Mesh.

# The oc CLI is kubectl plus OpenShift verbs — every kubectl command still works.
oc login --web https://api.cluster.example.com:6443
oc new-project payments                 # creates a Project (a namespace + annotations)
oc project payments

# Expose a Service through the router. This is the OpenShift shortcut for "ingress".
oc create deployment web --image=registry.access.redhat.com/ubi9/httpd-24
oc expose deployment/web --port=8080    # creates a Service
oc expose service/web                   # creates a Route with a generated hostname
oc get route web -o wide

# Edge-terminated TLS, the most common production shape:
oc create route edge web-tls --service=web --hostname=pay.apps.example.com

# Who can do what, and which SCC did a pod actually get?
oc adm policy who-can create routes -n payments

# oc create deployment labels its pods app=web, so select on that rather than
# guessing a pod name; the admitting SCC is recorded as an annotation.
oc get pods -l app=web -n payments \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.metadata.annotations.openshift\.io/scc}{"\n"}{end}'

SecurityContextConstraints vs Pod Security Admission

This is the single biggest culture shock. Long before upstream Kubernetes had PodSecurityPolicy — and long after it removed it — OpenShift has had SecurityContextConstraints (SCCs): cluster-level objects that decide what a pod is allowed to ask for, granted to service accounts through RBAC. On freshly installed clusters from 4.11 onward, restricted-v2 replaced restricted as the SCC granted to any authenticated user, and it drops all capabilities from containers rather than the smaller set restricted dropped. Clusters upgraded across 4.11 keep the legacy grant, which is exactly why the same manifest behaves differently on two clusters at the same version. The practical effect: an upstream Helm chart that runs as UID 0, or hardcodes runAsUser: 1000, will simply refuse to start, because OpenShift assigns each project a random UID range and expects images to tolerate it.

OpenShift also ships Kubernetes Pod Security Admission alongside SCCs, with a controller that synchronises a namespace’s PSA warn and audit labels from the SCC permissions of the service accounts in it — you can turn that off per namespace with the security.openshift.io/scc.podSecurityLabelSync label. So both systems are present, and SCC is the one that actually admits or rejects your pod. If you learned Pod Security Admission from our Security & Policy lesson, this is the same instinct implemented twice.

# The correct OpenShift move is NOT "give everything the privileged SCC".
# It is: make a service account, grant it the least-powerful SCC that works,
# and run the workload as that service account.
apiVersion: v1
kind: ServiceAccount
metadata:
  name: log-collector
  namespace: payments
---
# Grant an SCC via RBAC. anyuid lets an image pick its own non-root UID;
# it is a big step down from privileged and usually enough.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: log-collector-anyuid
  namespace: payments
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:openshift:scc:anyuid     # one ClusterRole exists per SCC
subjects:
  - kind: ServiceAccount
    name: log-collector
    namespace: payments
---
apiVersion: v1
kind: Pod
metadata:
  name: collector
  namespace: payments
spec:
  serviceAccountName: log-collector      # the SA is what holds the SCC grant
  containers:
    - name: collector
      image: image-registry.openshift-image-registry.svc:5000/payments/collector:1.4.0
      securityContext:
        allowPrivilegeEscalation: false
        capabilities: { drop: ["ALL"] }

ImageStreams, BuildConfigs and the integrated registry

OpenShift ships an integrated image registry inside the cluster (reachable at image-registry.openshift-image-registry.svc:5000), and two objects you will not find upstream. An ImageStream is a named, tagged pointer at images — it decouples “the tag my Deployment references” from “the immutable digest that tag currently resolves to,” and it can watch an external registry and fire a rollout when a tag moves. A BuildConfig describes how to turn source into an image inside the cluster, most famously via source-to-image (S2I): point it at a Git repo and a builder image, and OpenShift compiles and packages the app without you writing a Dockerfile at all.

Be careful how you read those in 2026. They are genuinely useful and genuinely examined (EX288’s objectives include image streams, S2I, build hooks and build triggers). They are also a pre-GitOps way of thinking: an in-cluster build triggering an in-cluster rollout is exactly the push-shaped, cluster-side pipeline that our CI/CD & Progressive Delivery lesson pushes back on. Most modern OpenShift platforms build in Tekton and deploy with Argo CD instead. In the same spirit, DeploymentConfig — OpenShift’s pre-Deployment workload object — has been deprecated since OpenShift 4.14; Red Hat’s documentation tells you to use plain Kubernetes Deployment objects for anything new. If a tutorial hands you a DeploymentConfig, it is old.

OpenShift GitOps and Pipelines — Argo CD and Tekton, downstream

☺ Like you’re 10: Two of the tools this whole site teaches are already in the box, wearing a different label.

Here is the fact that makes this page belong on a platform-engineering site rather than a vendor blog. Red Hat OpenShift GitOps is Argo CD — Red Hat describes it as based on the Argo CD project in the CNCF portfolio, packaged as an Operator with OpenShift SSO and console integration. Red Hat OpenShift Pipelines is Tekton — the direct downstream product of the upstream Tekton project at the Continuous Delivery Foundation. So the GitOps Workflows, Argo CD and Tekton pages on this site are not merely analogous to the OpenShift material; they are the same software, and an Application manifest you wrote for upstream Argo CD applies unchanged.

That cuts both ways for study planning. It means EX380’s GitOps objective is cheap for anyone who already learned Argo CD here. It also means an OpenShift shop gets no exemption from the ideas: reconciliation, drift, self-heal, prune and repo structure behave identically, and oc is just kubectl with extras.

# OpenShift GitOps: install the operator, then talk to plain Argo CD.
oc apply -f - <<'EOF'
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-gitops-operator
  namespace: openshift-operators
spec:
  channel: latest
  name: openshift-gitops-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic
EOF

oc get pods -n openshift-gitops                       # the Argo CD stack, unchanged
oc get route openshift-gitops-server -n openshift-gitops

# From here the manifests are identical to the ones on our Argo CD page —
# an Application pointing at a Kustomize overlay, with prune and selfHeal on.
oc get applications.argoproj.io -n openshift-gitops

# OpenShift Pipelines is Tekton; the CRDs are the upstream ones.
oc get tasks,pipelines,pipelineruns -n payments
tkn pipelinerun logs --last -f -n payments   # --last, or tkn will ask you to pick one

How this maps onto the CNPE and this site

☺ Like you’re 10: Almost every OpenShift topic already has a page here. Read them side by side.

Read that table honestly and the verdict writes itself: OpenShift is a packaging of this site’s curriculum with a support contract. Learn the curriculum and the packaging takes a fortnight. Learn only the packaging and you are stuck when the packaging changes.

Exam logistics — what the vendor publishes

☺ Like you’re 10: Here are the practical details, with a warning that they move and a note where the vendor would not tell us.

Official pages verified for this write-up: EX200, EX180, EX280, EX288, EX380, the full certification list, the training & certification FAQ, the certification-levels overview, Red Hat’s announcement of the May 2026 restructure, and the retired EX480 page.

Verdict — where it fits in a realistic order

☺ Like you’re 10: Take it if your job runs OpenShift. Otherwise take the neutral exams and read this page’s middle section for free.

A defensible order, assuming you are aiming at platform engineering rather than at a Red Hat job title. Learn Kubernetes properly first — everything else here assumes it. If your employer runs OpenShift, put EX280 next: it is directly job-shaped, it is hands-on, and it is the fastest way to stop being the person who does not know why their pod will not start. If your employer does not run OpenShift, put the CNPE next instead and come back to this page purely as a reading list — the OpenShift dialect section above is the part with lasting value, and it costs nothing.

RHCSA is the sleeper pick. Not because platform teams hire on it, but because the Linux layer is where the hardest incidents actually live, and a generation of engineers has skipped it. If you cannot confidently extend a logical volume, read a journal, or explain an SELinux denial, RHCSA is a better investment than a third Kubernetes badge — and unlike EX280, none of it becomes obsolete when your employer changes distribution.

Two closing calibrations. First, the three-year expiry is real and applies to every credential here, so treat Red Hat certification as a subscription with a renewal cost, not a trophy. Second, and more important: the reason to respect this track is the format, not the vendor. An exam that puts you in front of a live cluster and refuses to care what you can recite is measuring the right thing. Steal that standard for how you judge yourself, whichever logo is on the certificate.

Next stop: the credential hub, where this sits alongside the rest of the beyond-CNCF options — Certifications.