EX280 Red Hat Certified System Administrator in OpenShift Study Guide¶

Independent AI-assisted resource — SOURCES + OBJECTIVES CHECKED; HUMAN REVIEW PENDING. Objective coverage, citations, volatility labels, links, and exam-integrity compliance were checked on October 28, 2026. This is not a guarantee that the guide is error-free or current after that date. See the sources-and-objectives record. The official EX280 objectives are authoritative.

Study guide at a glance

Start here

Report an issue with EX280

Blueprint checked2026-10-28

Review stateSources + objectives checked — human review pending

Guide-only active reading45 min–1 hr 15 min

Prerequisites: Red Hat recommends RHCSA-level administration, DO180 or equivalent OpenShift workload skills, DO280 or equivalent cluster-administration experience, and container familiarity. The live page currently mixes 4.22 and 4.18 and says multiple versions are in use; confirm the LMS assignment and practice every objective against that exact OpenShift version.

Exam essentialsRead the objective map, key distinctions, and readiness checklist.

Deep understandingWork through every domain, including decisions, failure modes, and related items.

Hands-on labsBegin with Use the first hands-on exercise in the guide, then use the remaining labs to produce evidence you can inspect and explain.

Official objective domains

See the objective map in this guide

The active-reading range uses 90–130 words per minute for technical material. Labs, troubleshooting, note-taking, spaced review, and prerequisite gaps add time; it is not a total preparation promise.

Current public-page baseline: Red Hat now states OpenShift Container Platform 4.22 in both the exam description and delivery paragraphs
Upcoming/version change: Multiple versions remain in use; no future effective date is established by that statement
Binding version rule: Confirm the version shown in the purchase/LMS assignment. Use that version's objectives and product documentation—not this page's mixed metadata or a third-party course title—as the final scope.
Official source: Red Hat EX280 exam page

CURRENT BLUEPRINT / VERIFY CURRENT: On October 28, the public version-specific objectives PDF still includes EX280V422, matching this guide's 55-task, nine-group map. The current EX280 exam page now consistently identifies 4.22 in its headline and delivery paragraph. The PDF also contains older version lists; these are not interchangeable. Select the assigned version before booking or building a cluster.

Current guide watch — October 28, 2026¶

The live EX280 page now consistently specifies OpenShift Container Platform 4.22 in both the exam baseline and delivery paragraphs; its earlier 4.18 delivery wording is no longer present. The version-specific objective PDF still contains EX280V422. Use the version assigned in the exam portal. OCP 4.22 release notes add platform context such as Kubernetes 1.35, but do not expand the hands-on objective list. Red Hat's May framework changed credential mapping and validity, not this exam's tasks. See OCP 4.22 documentation and the Red Hat certification FAQ.

How to use this guide¶

EX280 is a three-hour hands-on administration exam on a live OpenShift environment. You are evaluated on whether the resulting resources and platform configuration meet the requested criteria. Red Hat requires configurations and services to remain functional through the normal platform lifecycle without manual repair. That makes the preparation unit a verified end state, not a memorized command.

The official page recommends RHCSA-level administration, DO180 or equivalent workload experience, DO280 or equivalent cluster-administration experience, and container familiarity. It also requires the baseline abilities associated with the former OpenShift technologist level: using the console and oc, deploying and troubleshooting workloads, and reading product documentation. These are recommendations and skill dependencies, not an invented certification prerequisite.

Use this loop for every practice task:

identify the selected cluster version, active project, current user, API resource, and requested end state;
inspect before changing: use oc get, describe, events, logs, API discovery, and authorization checks;
make the smallest declarative change in a saved manifest or controlled configuration object;
validate the resource, controller reconciliation, endpoint behavior, permissions, events, and logs from the correct identity;
reapply the manifest, restart/recreate a workload when appropriate, and prove the state remains correct.

Do not practice destructive identity-provider, ingress, Operator, or security-context changes on a shared production cluster. Use a disposable training cluster with snapshots or a documented rebuild path. A shared developer sandbox is excellent for project-scoped work but normally cannot teach every cluster-admin objective.

Objective map¶

Red Hat publishes unweighted task groups. Do not invent percentages.

Official task group	What mastery looks like
Manage OpenShift Container Platform	Navigate console/CLI, query resources and images, diagnose health/events/logs, and use local product documentation
Declarative resource management	Author, transform, import/export, apply, and verify YAML plus Kustomize bases/overlays
Deploy applications	Use manifests, templates, Helm, Deployments/ReplicaSets, labels/selectors, Services, routes, ConfigMaps, and Secrets
Manage authentication and authorization	Configure HTPasswd, users/groups, RBAC, and least-privilege validation
Configure network security	Diagnose networking, routes/ingress, TLS, NetworkPolicy, Services, load balancing, and external access
Expose non-HTTP/SNI applications	Select and validate the appropriate L4 exposure path rather than assuming an HTTP route
Enable developer self-service	Apply cluster/project quotas, requests/limits, limit ranges, and project templates
Manage OpenShift Operators	Discover, install, validate, and remove Operator lifecycle resources safely
Configure application security	Use service accounts, SCC permissions, secrets, API access, Jobs, and CronJobs with least privilege

1. Manage OpenShift Container Platform¶

Start every task by establishing context: oc whoami, oc project, oc version, and the cluster server. A correct command against the wrong cluster, namespace, or identity is still wrong. Learn both console and CLI navigation because the objective names both, but use the CLI for repeatability and the console for fast visual correlation of topology, events, alerts, and Operator status.

Resource discovery is more valuable than memorizing every field. Use oc api-resources to find names, scopes, short names, and API groups; oc explain <resource> --recursive to explore schemas available on the assigned cluster; and oc get ... -o yaml, JSONPath, custom columns, label selectors, and field selectors to extract evidence. Know the difference between desired specification, observed status, controller conditions, and events.

For images, distinguish mutable tags from immutable digests. Inspect the workload's resolved image, image pull status, registry path, and credentials. A tag is a human-friendly pointer that may move; a digest identifies content. Exporting a resource and blindly reapplying server-generated fields is fragile. Build a clean manifest containing intent, not status, UIDs, resource versions, timestamps, or managed fields.

Troubleshooting should move through layers:

cluster/operator/node health and alerts;
API object validity, admission failures, scheduling, pulls, mounts, and container state;
Service selector and endpoints;
DNS and network policy;
route/ingress and TLS;
application logs and response behavior.

Events are time-ordered clues, not permanent audit history. describe, namespace events, pod logs (including a previous container when available), deployment conditions, and cluster-operator conditions answer different questions. Record the exact failing layer before changing anything.

Related item: Kubernetes controllers continuously reconcile desired and observed state. Deleting a managed Pod may be a valid diagnostic action because its controller recreates it; editing the Pod directly usually is not a durable fix. This mental model explains much of OpenShift administration.

2. Declarative resource management¶

A good manifest is small, reviewable, reproducible, and explicit about API version, kind, metadata, and specification. Validate syntax and server acceptance, use oc diff where supported, apply narrowly, then inspect both the object and its downstream effects. Keep secrets out of ordinary source control even when the YAML is syntactically valid.

Kustomize separates a reusable base from environment-specific overlays. Know how kustomization.yaml selects resources and applies patches, names, labels, or generated configuration. Render before applying so you can inspect the actual objects. An overlay should express the environmental difference without copying the complete base. Confirm the exact Kustomize behavior supported by the oc client and documentation supplied for the assigned version.

Imperative commands remain useful for discovery and generating starter YAML, but saved declarative artifacts are the repeatable source of truth. For every exercise, delete or recreate the project/workload and replay the artifacts. A one-time success does not prove reproducibility.

Related item: GitOps extends declarative management by having a controller reconcile a repository to clusters. GitOps products are broader than the listed EX280 tasks, but Git-style diffs, reviews, immutable history, and rollback-friendly changes are excellent preparation habits.

Render a configuration change before deployment¶

This original exercise has four files. Create the directories shown and save each YAML block at its named path. The image is an intentionally non-runnable placeholder: rendering needs no image pull, credentials or cluster. For a later cluster lab, replace it with an approved image that supports the cluster's assigned UID and listens on port 8080. Supply the requested probes, resource sizing and namespace policy before deployment.

base/workload.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: study-api
spec:
  replicas: 1
  selector:
    matchLabels:
      app: study-api
  template:
    metadata:
      labels:
        app: study-api
    spec:
      automountServiceAccountToken: false
      containers:
        - name: api
          image: example.invalid/study/api:v1
          ports:
            - name: http
              containerPort: 8080
          envFrom:
            - configMapRef:
                name: study-settings
---
apiVersion: v1
kind: Service
metadata:
  name: study-api
spec:
  selector:
    app: study-api
  ports:
    - name: http
      port: 80
      targetPort: http

base/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - workload.yaml
configMapGenerator:
  - name: study-settings
    literals:
      - MODE=baseline

overlays/practice/kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
namespace: study-practice
replicas:
  - name: study-api
    count: 2
configMapGenerator:
  - name: study-settings
    behavior: merge
    literals:
      - MODE=practice

The fourth file, overlays/practice/README.txt, is your own evidence note: record the client version, expected namespace, replicas, ConfigMap value and selector/port relationships. Run kubectl kustomize overlays/practice to render locally, or use the assigned oc client's supported equivalent. Neither rendering command applies resources. The overlay's namespace field does not create a Namespace object.

Expected output has a Deployment with two replicas, a matching Service and one generated ConfigMap. Its content-dependent name is rewritten into the Deployment reference. Change MODE=practice to MODE=recovery and render again: the ConfigMap name and pod-template reference should both change, allowing a Deployment rollout when applied. Rendering identical inputs should be stable. Check these relationships instead of memorizing a particular hash suffix. The Kustomize reference explains generators and name references; the cluster still decides schema acceptance, quota, SCC admission and runtime behavior.

3. Deploy applications¶

Understand the controller-to-network chain: a Deployment manages ReplicaSets, a ReplicaSet maintains Pods, labels connect Pods to selectors, a Service provides stable discovery/load distribution, and a Route or another external mechanism brings traffic into the cluster. When an application is unreachable, prove each link rather than recreating everything.

Labels are arbitrary metadata; selectors are behavioral contracts. A Deployment selector must agree with its pod-template labels, and a Service selector must match the intended ready Pods. Inspect EndpointSlices/endpoints to confirm the Service actually has backends. Distinguish port, targetPort, container port, and the port on which the process really listens.

ConfigMaps hold non-secret configuration; Secrets hold sensitive material but are not automatically safe merely because they are base64-encoded. Know environment-variable and volume-mount consumption, update behavior, file keys/paths, and the need to restart or roll out workloads when applications do not reload values dynamically. Validate from inside the running container without printing secret values into logs or notes.

For ConfigMap update behavior, separate three cases: existing container environment variables stay unchanged; normal projected volume files are refreshed eventually but the application must reread them; a subPath mount does not receive updates. A new generated ConfigMap name in the pod template causes a different kind of change from editing data behind the same name. Validate both the mounted/environment value and what the application actually uses.

Templates parameterize OpenShift objects; Helm packages and renders charts; Kustomize overlays existing YAML without a template language. Select the mechanism named in the task, inspect rendered resources, set values explicitly, and verify ownership and upgrade behavior. For Deployments, practice image/config updates, rollout status/history, pause/resume only where needed, and safe rollback based on observed failure.

Related item: Readiness controls whether a Pod receives Service traffic; liveness controls restart behavior; startup protects slow initialization. Probes and resource sizing are durable operations knowledge even when a particular version's public EX280 list does not name every probe task.

4. Manage authentication and authorization¶

Authentication establishes identity; authorization decides what that identity may do. For HTPasswd, create or update the credential file/Secret, configure the cluster OAuth identity provider, wait for reconciliation, and test login. Identity-provider changes are cluster-wide and can lock out administrators, so keep a verified recovery identity and work only in a disposable environment.

RBAC binds Roles or ClusterRoles to users, groups, or service accounts. A RoleBinding grants permissions in a namespace even when it references a ClusterRole; a ClusterRoleBinding grants cluster-wide scope. Prefer existing aggregate/default roles when they match the requirement. Validate with oc auth can-i while impersonating the intended subject and test both an allowed and a denied operation.

User and group objects, identities, credentials, and RBAC bindings are related but not interchangeable. Removing a user object does not necessarily remove the external credential, and changing the HTPasswd source does not clean every binding. Trace the full path from credential to identity mapping to group membership to role binding.

Related item: Least privilege is demonstrated with negative evidence. “The user can create deployments” is incomplete until you also show that the user cannot modify cluster-scoped policy or another team's namespace.

5. Configure network security¶

Build a packet path: client → external address/load balancer or ingress → Route/Service → EndpointSlice → Pod IP/container port. Check DNS, certificates, route admission, Service selectors, ready endpoints, listening ports, and NetworkPolicy at their own layers. Avoid interpreting every timeout as a firewall problem.

Routes expose HTTP/S traffic through the OpenShift ingress controller. Understand hostnames and the edge, passthrough, and re-encrypt TLS boundaries: where TLS terminates, which certificate is presented, and whether traffic to the backend is encrypted. Inspect route admission and the certificate chain; do not infer security from an https URL alone.

NetworkPolicy is additive. Once a Pod is selected for a traffic direction, allowed traffic is the union of applicable policies. Namespace and pod selectors can combine; an empty selector has a specific broad meaning. Create source and destination test Pods, prove an allowed flow and a denied flow, and ensure DNS/required platform traffic is not accidentally blocked.

Prove selector scope and policy composition¶

In standard NetworkPolicy, two selectors within one peer are combined with AND; separate peers are alternatives. A peer containing only a pod selector selects Pods in the policy's own namespace. For a pod-to-pod flow, source egress and destination ingress must both permit it when those directions are isolated. This explanation concerns ordinary NetworkPolicy; cluster-level policy APIs can impose additional controls.

Save this original ingress-only fixture as allow-reviewer.yaml. It selects app=study-api Pods in study-practice and permits TCP 8080 from Pods labeled role=reviewer in namespaces labeled team=quality:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-reviewer
  namespace: study-practice
spec:
  podSelector:
    matchLabels:
      app: study-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              team: quality
          podSelector:
            matchLabels:
              role: reviewer
      ports:
        - protocol: TCP
          port: 8080

Source / request	This rule permits ingress?
Quality namespace, reviewer Pod, TCP 8080	Yes
Quality namespace, another role, TCP 8080	No
Another team, reviewer Pod, TCP 8080	No
Quality reviewer, TCP 9090	No
Quality reviewer, UDP 8080	No

Splitting the two selectors into separate from entries broadens the rule: any Pod in a quality namespace or a reviewer Pod in the policy's own namespace could match. A second policy allowing everyone on TCP 8080 also broadens the effective allowance; adding a restrictive policy cannot subtract that allowance. This fixture does not control egress, other destination labels, route access or every platform exception. Inspect all selecting policies and use fresh connections from real source Pods for the later cluster test.

For route TLS, trace both legs: edge decrypts at the router and normally forwards cleartext HTTP; passthrough leaves TLS for the backend and depends on SNI; re-encrypt decrypts at the router and establishes a separate TLS connection to the backend. Check the backend certificate trust configuration, including the destination CA where required. A successful frontend handshake alone does not prove backend trust or application health.

For external access, understand ClusterIP, NodePort, LoadBalancer, ingress/routes, and what the cluster/provider actually provisions. A LoadBalancer Service may remain pending without an integrated implementation. Match the exposure method to protocol, source restrictions, TLS boundary, and platform support.

Related item: OpenShift commonly uses OVN-Kubernetes, but plugin details and diagnostic surfaces change by product version. Learn stable packet-path reasoning, then bind exact commands and objects to the assigned documentation.

6. Expose non-HTTP/SNI applications¶

An ordinary OpenShift Route is designed around HTTP/S and TLS SNI behavior. Raw TCP/UDP or protocols that do not fit that model require an L4 mechanism supported by the cluster, commonly a LoadBalancer or NodePort Service, or configured ingress-controller capabilities. Do not force a database or arbitrary TCP service through an HTTP route simply because routes are familiar.

Verify the Service protocol and ports, external address/provisioning state, backend endpoints, cloud/on-prem load-balancer implementation, network controls, and end-to-end client behavior. If the task asks for a LoadBalancer, create and diagnose that resource rather than substituting a Route. Treat infrastructure-specific provisioning time and pending status as observable facts.

7. Enable developer self-service¶

ResourceQuota limits aggregate namespace consumption or object counts. LimitRange constrains or defaults individual containers/Pods/PVCs. Requests influence scheduling and quota accounting; limits constrain runtime consumption. Diagnose a rejected workload by reading admission messages and comparing the request with both quota and limit-range rules.

Cluster resource quotas can select multiple projects; ordinary resource quotas are namespace-scoped. Project templates allow administrators to seed new projects with policy/resources. Test template changes with a newly created project—existing projects do not magically acquire new template contents—and verify behavior as a non-admin developer.

Good self-service creates safe paved roads: users can create the resources they need without receiving unnecessary cluster authority. Validate project creation policy, role assignments, quotas, defaults, and failure messages from the developer identity.

Related item: Capacity management joins policy with scheduling. A quota can permit a request that the cluster still cannot schedule, while free cluster capacity does not override an exceeded namespace quota.

8. Manage OpenShift Operators¶

Classic OLM: Operator Lifecycle Manager concepts form a chain: catalog/package/channel exposes versions; a Subscription expresses desired channel/version behavior; an InstallPlan represents installation/upgrade actions; a ClusterServiceVersion reports the installed Operator; custom resource definitions extend the API; custom resources request managed instances.

Before installation, inspect scope, namespace, channel, approval mode, compatibility, dependencies, CRDs, and permissions. After installation, verify Subscription, InstallPlan, CSV conditions, Operator pods, CRDs, and a safe custom-resource path. Troubleshoot from conditions and events rather than repeatedly deleting resources.

Uninstall is not one universal delete. Removing a Subscription/CSV may leave custom resources, CRDs, operands, namespaces, or cluster-wide RBAC. Follow the assigned product documentation and the task's requested end state. “Delete an Operator” and “delete all data it ever managed” are not synonyms.

VERIFY CURRENT — two OLM resource models: The OpenShift 4.22 OLM v1 overview and architecture describe ClusterExtension and ClusterCatalog, with Operator Controller and catalogd. A ClusterExtension is cluster-scoped even when its installed components use a named namespace. Discover the installed APIs and follow the assigned workflow; do not require a Subscription/CSV for an extension installed through v1. Classic console Operator pages do not represent the v1 installation inventory. Treat this distinction as version-aware operational context, not a new weighted exam objective.

Related item: Operators encode operational knowledge in controllers. The same reconciliation model used for Deployments explains why directly editing an operand may be reverted by its Operator.

9. Configure application security¶

Pods call the Kubernetes API as service accounts. Give each workload the narrow service account and RBAC needed, mount tokens only when necessary, and verify authorization from that identity. Avoid granting broad roles to the default service account for convenience.

Security Context Constraints govern whether a workload may run with requested Linux identities, capabilities, host access, volumes, and privilege. Diagnose admission using workload events and SCC authorization. Prefer adapting the workload to an appropriate existing SCC or granting a narrowly appropriate SCC to a dedicated service account; privileged access is a last resort and must be explicitly required.

The 4.22 SCC reference distinguishes two grant paths. oc auth can-i use scc/<name> and oc adm policy who-can use scc <name> inspect RBAC; they do not include direct entries in the SCC's users/groups. oc describe scc <name> shows those direct entries, not all RBAC grants. Inspect both paths, the subject identity, requested pod security context, events and the admitted Pod's openshift.io/scc annotation. A single RBAC no does not prove the subject has no SCC access; an RBAC yes does not prove the requested pod satisfies that SCC.

A Role/RoleBinding can scope permission to use a named SCC within a project. Directly adding a user/group/service account to an SCC grants access across projects where the subject can create Pods. Prefer a dedicated workload account and the narrow required grant; preserve built-in SCC definitions. Test both an allowed workload and an out-of-scope identity, rather than fixing every admission failure by granting privileged.

Secrets should be scoped, access-controlled, and consumed without disclosure. Separate the permission to read a Secret from the permission to create a Pod that can mount it—both can expose data. For Jobs and CronJobs, define restart/concurrency/history behavior and use a dedicated service account. Verify completion, logs, schedules, missed/overlapping execution behavior, and cleanup.

Related item: Kubernetes RBAC does not understand the sensitivity of individual Secret values. Namespace design, admission controls, service-account isolation, audit, and external secret systems complement RBAC in production; the exam objective begins the model rather than completing it.

Integrated scenarios¶

Scenario 1: Multi-team application platform¶

Create two developer groups and isolated projects. Configure least-privilege bindings, aggregate quota, per-container defaults, and a project template. Deploy an application from a Kustomize base with team overlays, ConfigMap and Secret consumption, Service, TLS Route, and default-deny plus required-allow NetworkPolicies. Validate from each user identity and from test Pods.

Scenario 2: Packaged privileged workload¶

Install an approved Operator or Helm-packaged workload in its designated namespace. Trace the assigned OLM lifecycle resources or rendered chart objects, use a dedicated service account, add only the required SCC/RBAC, expose the correct protocol, and prove a normal user cannot escalate. Remove the installation to the exact requested boundary and inventory residual cluster-scoped objects.

Scenario 3: Broken production deployment¶

Start with a failing rollout containing an image/tag mistake, selector mismatch, missing configuration key, denied network flow, and incorrect route TLS assumption. Use conditions, events, logs, endpoints, authorization, and packet-path tests to isolate failures. Fix declaratively, reapply from a clean namespace, and produce positive plus negative evidence.

Hands-on labs¶

Discovery and evidence: inventory API resources, cluster/operator health, projects, images, events, alerts, and logs; produce filtered/custom-column evidence without copying generated fields.
Declarative replay: build multi-object YAML, then a Kustomize base and two overlays; render, diff, apply, delete, and reproduce the end state.
Application chain: deploy with a template and Helm chart; validate Deployment → ReplicaSet → Pod → Service → endpoint → Route and perform a controlled update/rollback.
Identity and RBAC: configure HTPasswd on a disposable cluster, create users/groups, bind roles, and prove allowed/denied operations with impersonation.
Network boundaries: implement TLS route modes and NetworkPolicies; test DNS, same/different project access, denied sources, endpoint readiness, and certificate presentation.
Self-service: configure quota, limit ranges, requests/limits, cluster quota where available, and a project template; validate as developer and diagnose admission failures.
Operator lifecycle: install into the correct scope, inspect the installed OLM resource model, CRDs and operand health, then uninstall to a documented boundary.
Security and timed recovery: use a dedicated service account, narrow RBAC/SCC access, Secret consumption, Job, and CronJob; then solve an integrated broken environment using only assigned-version docs.

For every lab retain manifests, commands, expected observations, actual output, version, rollback, and a clean-replay result. Scrub credentials, tokens, certificates' private keys, and cluster URLs before saving evidence.

Original knowledge checks¶

Why are the headline and delivery versions on the live EX280 page insufficient to select a lab baseline?
Which source becomes binding after an exam version is assigned?
What does persistence mean for a controller-managed platform?
Why begin with identity, project, server, and version?
What is the difference between spec, status, conditions, and events?
When should you inspect previous-container logs?
Why should exported YAML be cleaned before reuse?
What does an image digest prove that a tag does not?
How do API discovery and oc explain reduce memorization?
Why is directly editing a managed Pod rarely durable?
What belongs in a Kustomize base versus overlay?
Why render a Kustomization or Helm chart before applying it?
How do a Deployment, ReplicaSet, and Pod relate?
What proves that a Service selector works?
How do Service port and targetPort differ?
When does a ConfigMap or Secret update require a rollout?
How do Templates, Helm, and Kustomize differ?
What evidence supports a safe application rollback?
How do authentication and authorization differ?
Why can a ClusterRole be used by a namespace-scoped RoleBinding?
What two tests demonstrate least privilege?
Why does deleting a user object not necessarily revoke credentials?
What is the packet path from external client to container?
Where does TLS terminate for edge, passthrough, and re-encrypt routes?
How are multiple NetworkPolicies combined?
Why might a LoadBalancer Service remain pending?
When is an ordinary Route the wrong exposure mechanism?
What must be verified for a non-HTTP service?
How do ResourceQuota and LimitRange differ?
How do requests affect both scheduling and quota?
Why test a project-template change with a new project?
What does a safe self-service design allow and deny?
How do Subscription, InstallPlan, CSV, CRD, and custom resource relate?
What evidence shows an Operator is healthy?
Why can uninstall leave cluster resources or data?
What identity does a Pod use to call the API?
How should an SCC admission failure be investigated?
Why is granting privileged to the default service account dangerous?
What Job/CronJob settings affect retries, overlap, and history?
What evidence shows an entire solution is reproducible rather than manually repaired?

Answers to the original knowledge checks¶

The same public page gives two baselines and says several versions are in use; neither a headline nor an older delivery paragraph identifies your assigned exam.
The assigned version in the LMS and its matching objectives. The public version PDF helps compare lists; it does not assign a version to you.
Controllers must recreate the requested working state from durable resources after replacement/reconciliation; manual changes inside a Pod are insufficient.
Those checks prevent correct operations against the wrong account, project or cluster and identify the available API/tool version.
The specification expresses intent; status reports observations; conditions summarize particular states; events are transient diagnostic records.
After a container restart when the current process logs omit the failure. Previous logs may be unavailable if the earlier container has been removed.
Server-assigned identity, version and status fields are observations rather than reusable desired configuration.
A digest identifies image content. A tag is a mutable reference; neither alone proves the image is trusted or suitable.
They reveal available resources, scope and field schemas for the actual server, reducing reliance on an old example.
A controller recreates Pods from its template; update the owning declarative resource.
The base holds common resources and the overlay expresses differences such as namespace, replicas and configuration.
Inspect the exact generated objects, selectors, references, permissions and values before admission; rendering itself does not prove runtime success.
The Deployment manages rollout through ReplicaSets; each ReplicaSet maintains its desired matching Pod count.
Matching ready EndpointSlices plus a successful Service request. Matching labels alone do not establish application readiness.
The Service exposes its port to clients and forwards to the backend targetPort, which can refer to a named container port; a real process must listen there.
Environment consumption needs replacement to obtain new values. Normal volume projections update eventually but may require application reload; subPath mounts do not refresh. Handle Secret consumption with the same deliberate verification.
Templates substitute parameters into OpenShift resources, Helm renders packaged charts, and Kustomize transforms existing manifests.
A known-good revision and compatible configuration/data, clear rollout failure evidence, then healthy replacement Pods and endpoint behavior. Undoing a Deployment is not a database rollback.
Authentication establishes identity; authorization evaluates permitted actions on resources.
The role defines permissions; the RoleBinding confines applicable namespaced permissions to its own namespace. Cluster-scoped access needs the appropriate cluster binding.
Prove one required action succeeds and one forbidden action fails as the intended subject.
Credentials may remain at the identity provider and bindings/identity mappings can remain separately. Check each layer and the provider-specific revocation behavior.
Resolve the external name/address, inspect load balancer/ingress, route and TLS, Service and endpoints, then destination port/process and network controls.
Edge terminates at the router; passthrough terminates at the backend; re-encrypt terminates at the router and creates a new encrypted backend connection.
Their allowed traffic is a union for each isolated direction. Source egress and destination ingress must both allow a connection; other cluster-level controls also matter.
Its external implementation or address pool may be absent, exhausted or still provisioning; inspect controller events and provider support.
When the protocol does not fit HTTP or supported TLS/SNI routing, such as arbitrary UDP or plain TCP; choose the assigned L4 mechanism.
Transport protocol, both port mappings, provisioned address, ready backends, controls and a real end-to-end client exchange.
Quota governs aggregate project usage/counts; LimitRange sets defaults or bounds on individual resource specifications.
Requests reserve scheduling capacity and count toward the applicable quota; satisfying quota does not guarantee a node has capacity.
The template supplies initial resources for new projects; existing projects do not automatically adopt edits.
It permits the intended project/workload operations while constraining capacity, cross-project access and cluster administration.
In classic OLM, a Subscription requests a channel, InstallPlan tracks actions, CSV describes the installed Operator, CRDs define APIs and custom resources request instances. OLM v1 uses a different resource model.
Inspect the relevant lifecycle conditions, controller Pods/events and the managed instance's observed behavior; successful installation alone does not prove the operand works.
Lifecycle ownership and uninstall boundaries differ; custom resources, data, CRDs or shared permissions may intentionally remain. Inventory before deletion.
Usually the configured service account using its projected credential; a Pod with token automount disabled needs another explicit supported authentication path to call the API.
Inspect both SCC direct grants and RBAC, the workload identity and requested fields, admission events and the selected SCC after success. Correct only the actual mismatch.
Every workload using that shared identity could inherit broad host/capability permissions. Isolate identities and grant only the required SCC access.
Jobs use backoffLimit, restartPolicy and deadlines; CronJobs add schedule, concurrencyPolicy, startingDeadlineSeconds and history limits. Job actions must tolerate retries or duplicate execution.
A clean replay from saved manifests, healthy reconciliation, real endpoint checks and allowed/denied tests after replacement, with versions and observations recorded.

Version-transition checklist¶

Before using 4.18, 4.22, or older content, compare it with the assigned version:

objective groups and exact named tasks;
installed oc client/server versions and available APIs;
deprecated/removed APIs and server-side schema;
Kustomize and Helm behavior supplied in the environment;
route, ingress-controller, LoadBalancer, and OVN-Kubernetes behavior;
OAuth/HTPasswd resource examples and reconciliation;
Operator Lifecycle Manager version, channels, and uninstall guidance;
SCC defaults, service-account tokens, and admission messages;
console layout and alert/health surfaces;
included product documentation and permitted local help.

Do not add an older topic merely because a course teaches it, and do not omit an assigned-version task because a newer course moved on. The LMS assignment wins.

About related items: A Related item: callout adds prerequisite, operational, architectural, or adjacent context that makes the current topic easier to understand. It is useful supporting knowledge, not a claim that the item appears verbatim in the published exam objectives.

Source map and freshness notes¶

The live EX280 page is the scope authority but contains conflicting 4.22/4.18 statements and explicitly delegates assigned candidates to version-specific objectives. Matching versioned product documentation controls syntax and behavior. DO180/DO280 describe official learning routes; other resources supplement explanation and practice only.

Volatile: assigned exam version, objectives, APIs, console layout, CLI/tool behavior, network/ingress implementation, Operator channels, SCC defaults, course versions, sandbox limits, delivery, price, duration, access, and schedule. Recheck the official page and LMS immediately before study-plan lock and booking.

This guide uses only public objective language and original scenarios, labs, and checks. It does not reproduce or solicit recalled exam tasks.

Places to learn¶

This is not a complete list and is not meant to be consumed in full. Pick the explanation style and lab environment that work for you, then use the assigned objectives as the checklist. Estimated time includes deliberate practice where stated; access, runtimes, course versions, and schedules can change.

Resource	Access	Estimated time
Assigned EX280 objectives plus matching OpenShift docs	Public / exam environment	15–30 selected hours
Red Hat DO180 + DO280	Paid	8–10 training days or 70–120 selected hours with labs
Red Hat DO080 orientation	Free account	About 2 hours plus 2–4 hours exploration
Red Hat Foundations of OpenShift learning path	Free account	3 hours 40 minutes plus 4–8 hours practice
Red Hat Developer Sandbox	Free account, 30-day environment	10–25 project-scoped hours
OpenShift Local	Free account; capable local hardware	20–50 hours
Pluralsight OpenShift Administration path	Paid	10 hours video plus 20–40 hours labs
O'Reilly / Sander van Vugt EX280 video	Paid; page blocked in this review	Previously listed 8 hours 1 minute plus 20–40 hours labs and large version-gap review
Udemy / Mahmoud Khatab EX280 course	Paid; page blocked in this review	Previously listed 7 hours 53 minutes plus 20–40 hours labs and scope review

Official core: DO180 OpenShift Administration I advertises 4.22 as checked September 28. DO280 OpenShift Administration II is the closest official administration route and also advertises 4.22 as checked September 28; this does not reconcile the exam page's mixed wording. Verify the purchased course revision.
Versioned documentation: use OpenShift 4.22 documentation for an assigned 4.22 exam and OpenShift 4.18 documentation for an assigned 4.18 exam. Become fast at finding examples inside the version you will actually receive.
Free orientation: DO080 Containers, Kubernetes and OpenShift Technical Overview is an older 4.12 foundation, approximately two hours, not full exam preparation. The Foundations of OpenShift path lists 3 hours 40 minutes of guided content.
Practice environments: the Developer Sandbox FAQ describes a free 30-day shared environment and its restrictions. OpenShift Local provides a local minimal cluster. The sandbox cannot grant every cluster-admin capability; OpenShift Local requires substantial machine resources and still differs from a production multi-node cluster.
Current broad path: Pluralsight Red Hat OpenShift Administration lists six 2026 courses and ten video hours. It is broader than EX280 and not an official version-specific objective map, so select relevant modules and add labs.
Older detailed route: O'Reilly/Pearson Red Hat OpenShift Administration: EX280 was previously listed as 8 hours 1 minute from April 2021; the page was access-blocked on September 28, so this metadata was not reverified. Its controller/RBAC/resource fundamentals remain useful, but it predates the current Kustomize, declarative, networking, Operator, non-HTTP exposure, and version-specific emphasis.
Alternative language route: Udemy / Mahmoud Khatab EX280 was previously listed as 7 hours 53 minutes, 30 lectures, Arabic audio and English captions, updated August 2026. Its page was access-blocked in this review; verify these details before purchase. It includes useful hands-on administration but also topics not named on the current public list; map every module and do not treat course breadth as exam scope.
Operational reading: Przemysław Roguski's September 10, 2026 network-policy verification article motivates testing denied as well as permitted flows and inspecting every selecting policy. Allow its listed 37-minute reading time plus 1–2 hours to design your own flow matrix. Its platform-specific ports, host-network cases and template examples need separate verification against your cluster; this guide adopts the validation method, not those settings or the article's agent workflow.

PRACTICAL DEPTH — review evidence: Local Kustomize rendering and selector reference checks are recorded in the September 28 review. No OpenShift cluster, OAuth, SCC admission, networking, Operator installation or clean-replay lab was executed. The eight platform labs above remain practice tasks, and a successful render is not a passing cluster lab.

No exact current EX280 MeasureUp, Whizlabs, or official multiple-choice practice exam was independently verified on September 1. Because EX280 is performance-based, build original tasks from the public objectives and validate them on fresh namespaces/clusters. Avoid products claiming real, leaked, “sure shot,” or recalled exam content. A realistic plan is 120–220 hours after Kubernetes/OpenShift workload experience, or 250–450 hours if containers, Kubernetes, Linux, and cluster administration are all new.