Red Hat EX280: Complete OpenShift Administrator Study Guide

What EX280 measures—and what Red Hat does not publish

Red Hat says EX280 tests the knowledge, skills, and ability to create, configure, and manage a cloud application platform using OpenShift Container Platform. The exam page identifies OpenShift Container Platform 4.18 as the product basis. Passing leads to the exact credential name Red Hat Certified System Administrator in OpenShift and can count toward Red Hat's OpenShift architect path.

EX280 is performance-based: candidates demonstrate administration by working in an environment rather than choosing answers from a conventional multiple-choice form. That fact should shape preparation. Reading is necessary, but practical repetition is the core. Create resources from clean state, verify them, break them safely, diagnose from evidence, recover, and remove them.

The public page cited here does not publish duration, task count, or objective percentages. Therefore the accurate duration text in this guide is Verify official exam page. No unofficial hour estimate is presented as fact. Likewise, the practice bank uses a transparent non-official internal allocation—not Red Hat weights:

These 50 checks are not simulations of a secret form. They ask what an administrator should inspect, plan, constrain, verify, or recover in original scenarios. Each explanation points to official HTTPS documentation.

Build the Linux, container, Kubernetes, and OpenShift foundation

The official prerequisites recommend Red Hat System Administration I or comparable experience. RHCSA is strongly recommended but not required. Red Hat also recommends OpenShift Administration I and II—DO180 and DO280—or comparable experience, plus container familiarity. That list is a useful readiness signal: EX280 administration sits above basic shell, process, file, network, container-image, YAML, and Kubernetes object knowledge.

Be fluent with the oc command-line context. Before every change, know the API endpoint, user, and project. Performance practice should use an unmistakable lab context and explicit namespaces. A technically correct manifest applied to the wrong project is an operational failure. Use concise queries first, then inspect full status, conditions, events, logs, and relevant configuration.

OpenShift projects build on Kubernetes namespaces and add familiar management workflows. Establish ownership and expiry labels, resource quotas, limit ranges, and dedicated service accounts. Learn the difference between aggregate quota and per-object defaults or bounds. When a Pod is Pending, use events to distinguish quota, request, node capacity, affinity, selector, and taint causes before changing anything.

Work with resource manifests as maintained desired state

A manifest is an API request represented as YAML or JSON. Review apiVersion, kind, metadata, namespace, and spec. Then inspect security-sensitive details: service account, image, command, environment, volumes, host access, ports, probes, resources, and security context. Validate against the API served by the target 4.18 cluster rather than assuming an old example still matches.

Keep user-owned desired state, but remove server-assigned UID, resourceVersion, timestamps, managed runtime status, and other generated data from reusable files. Configuration should be declarative, reviewed, and versioned. Compare the maintained source with live state to expose emergency edits and drift. Never export bearer tokens or real Secret values into a repository.

ConfigMaps carry non-confidential settings. Secrets carry sensitive values, but merely using a Secret object does not make the full lifecycle safe. Protect source, API authority, mounts, application output, logs, backups, and rotation. Base64 is encoding, not encryption. Use synthetic values in study projects and add a canary search to prove that evidence never captured them.

Deploy and troubleshoot applications

A Deployment declares replicated Pods and manages rollout through ReplicaSets. A Service supplies stable discovery and selects Pods by labels. Ready endpoints appear when matching Pods satisfy readiness. If a Service has no endpoints, check namespace, selector, Pod labels, and readiness before changing cluster networking.

Probes answer different questions. A startup probe can protect a slow initialization window. Readiness determines whether traffic should reach the Pod. Liveness can trigger restart when the process is irrecoverably unhealthy. A probe that depends on every downstream system can create cascading unavailability, so choose a meaningful but bounded health signal.

Requests influence scheduling; limits bound applicable runtime consumption. Investigate OOMKilled by comparing observed memory, requests, limits, concurrency, replica strategy, node capacity, and project quota. Avoid solving every incident by adding resources without measuring the application.

Tags can move. For a controlled release, record and deploy exact image content—typically a digest—and connect that identity to testing. Observe rollout status and history. Inject a bad revision in a disposable project, preserve status, events, and logs, then roll back and verify service recovery. Correct the maintained source so the bad desired state does not return.

Manage authentication and authorization

Authentication establishes who a request represents. Authorization decides whether that identity may perform a verb on a resource at a scope. A successful login followed by Forbidden is not an authentication failure. Inspect the exact API group, resource, subresource, verb, name, namespace, and effective bindings.

Use Roles and RoleBindings for project-scoped authority. A ClusterRole can be bound in one project when its reusable permission set fits, while ClusterRoleBinding grants cluster scope. Avoid wildcards, shared administrator accounts, and default cluster-admin responses. Test the required success and sensitive denial as the actual user or service account.

Identity-provider changes deserve staged rollout. Validate issuer trust, claim mapping, identity naming, group synchronization, secrets, and logout or token behavior with a synthetic non-admin user. Preserve an approved recovery path. Removing every existing administrative path before a new provider is proven creates avoidable lockout.

Workloads should use dedicated service accounts. If a workload never calls the API, disable automatic token mounting where appropriate. If it does call the API, enumerate only required verbs and resources. Treat workload creation rights as potentially transitive authority because a Pod can run under a service account and mount namespaced data.

Configure network security and exposure

NetworkPolicy becomes useful when translated from observed requirements. Write a connectivity matrix: source, destination, direction, protocol, port, DNS dependency, ingress path, probes, metrics, and owner. Apply default-deny for the intended direction, then add exact allows. Ingress and egress are independent, and applicable allow rules combine additively. A narrow policy does not cancel a broad allowance elsewhere.

DNS is a frequent first failure under egress isolation. Permit the actual resolver path narrowly, then test name resolution separately from the application connection. Confirm that policy selects the intended Pods and namespaces and that the installed network implementation enforces it. The presence of a YAML object is not proof of a denied packet.

OpenShift Routes publish HTTP and HTTPS services through the ingress layer. Choose edge termination when the router terminates external TLS, re-encrypt when the router establishes another encrypted backend connection, and passthrough when the router forwards TLS based on SNI without decrypting application payload. Passthrough cannot route by HTTP path because it does not see plaintext HTTP.

Raw TCP or UDP does not become routable merely by creating an ordinary HTTP Route. Evaluate a supported LoadBalancer or NodePort Service, or documented ingress-controller capabilities. Before exposure, define private versus public reachability, source restrictions, authentication, encryption, health, failover, monitoring, firewall path, ownership, and removal. A database should not be published to the internet merely for lab convenience.

Enable bounded developer self-service

Templates can process parameterized sets of objects and give developers a repeatable starting point. Good self-service combines a reviewed template with scoped RBAC, quotas, limits, admission, ownership, and cleanup. It is delegated authority within guardrails, not a shared cluster administrator credential.

Align parameter requirements with generated-object validation. Make required values explicit. Generate or supply sensitive values through an approved workflow rather than committing a reusable password. Process the template and create generated resources as the intended developer identity. Template rendering can succeed while authorization, quota, schema, or SCC admission later rejects an object.

Manage OpenShift Operators deliberately

An Operator can install CRDs, controllers, webhooks, roles, and cluster-wide behavior. Before subscribing, review source, package, channel, version, support, install mode, namespace scope, required permissions, dependencies, and update approval. A logo is not a trust assessment.

Learn the OLM chain: catalog source offers package metadata; a Subscription expresses channel and approval; an InstallPlan lists proposed changes; a ClusterServiceVersion describes an installed version and its owned APIs and requirements; the controller reconciles custom resources into operands. A Running Operator Pod does not prove successful reconciliation. Read Subscription, InstallPlan, CSV, custom-resource conditions, events, controller logs, and effective permissions together.

Updates must follow a supported path. Review API compatibility and migrate custom resources as documented. Preserve relevant desired state and test the operand after change. Uninstall requires separate decisions about the controller, managed instances, finalizers, data, CRDs, webhooks, and RBAC. Deleting a CRD can delete every custom resource of that type.

Configure application security for OpenShift defaults

OpenShift's restricted model commonly runs containers with an arbitrary non-root UID. Images should not assume root or a fixed UID. Make required directories writable to the appropriate group, keep immutable application content read-only, and avoid privileged, host namespace, hostPath, and unnecessary capability requirements.

SecurityContextConstraints govern which Pod security settings can be admitted and which identities may use them. When an application requests a broader SCC, inspect the exact UID strategy, capabilities, privilege escalation, volume types, host access, and service-account binding. First adapt the image or configuration. If an exception remains necessary, make it exact, owned, approved, compensated, expiring, and removable.

Application security also includes Secret handling, image identity, service-account authority, network reachability, logs, persistent volumes, and cleanup. A container that starts successfully can still expose credentials, accept traffic it does not need, or write sensitive data to an unmanaged volume.

Three projects for performance-based preparation

The EX280 project set is intentionally deeper than a command checklist. The first creates a production-style project baseline with declarative workloads, quota, probes, immutable rollout, rollback, five fault classes, restricted execution, evidence, and teardown. The second builds synthetic identity, least-privilege RBAC, default-deny segmentation, TLS Routes, and a private non-HTTP canary with six distinct failures. The third studies OLM, custom resources, secure Templates, SCC, Secrets, controlled updates, failure recovery, and uninstall.

An eight-week practice plan

How to reason under performance pressure

First establish context. Confirm cluster, user, project, resource type, and desired outcome. Second inspect before editing. Status, conditions, events, logs, selectors, endpoints, quota, and effective access often identify the layer. Third make the smallest declarative change. Fourth verify both success and denied paths. Fifth preserve a rollback and clean temporary objects.

Build command families from concepts rather than memorizing one long sequence. For a workload problem, move from controller to Pod to container to Service and policy. For authorization, move from identity to exact request to role rules and bindings. For an Operator, move from Subscription to InstallPlan to CSV to controller to custom-resource status and operand. This structure survives naming changes better than rote command recall.

Do not use dumps. Recalled tasks violate exam integrity and train brittle imitation. The best preparation is the ability to produce the same legitimate outcome from different starting states and explain why every object and permission exists.

Official references

• Red Hat EX280 exam page
• Red Hat Certified System Administrator in OpenShift credential
• OpenShift Container Platform 4.18 documentation
• Red Hat Certification Program Guide

Continue preparing

• EX280 roadmap
• 50 original task-planning checks
• 40 EX280 flashcards
• Three OpenShift projects
• RHCSA roadmap
• Editorial policy

Frequently asked questions