EX380
Red Hat Certified Specialist in OpenShift Automation and Integration
EX380 preparation and scheduling guide
EX380 validates advanced OpenShift administration skills for planning, implementing, and managing large-scale Red Hat OpenShift Container Platform deployments in an enterprise. It serves platform engineers, system administrators, cloud administrators, enterprise architects, SREs, and DevOps engineers who need to prove practical capability rather than recall definitions. This guide helps you decide whether your current OpenShift experience is ready, which skill areas to practise first, and when to move from study to scheduling.
What does EX380 validate?
EX380 is Red Hat’s Red Hat Certified Advanced System Administrator in OpenShift exam. Its central test is practical: can you configure, secure, protect, automate, and recover an enterprise OpenShift environment? Passing the exam earns the Red Hat Certified Advanced System Administrator in OpenShift credential.
Red Hat describes EX380 as testing the ability to plan, implement, and manage large-scale Red Hat OpenShift Container Platform deployments in an enterprise. That wording points to a systems-administration assessment, not a narrow command-line exercise. Preparation should therefore connect individual commands to cluster outcomes such as controlled access, resilient applications, repeatable deployment, and recoverability.
The current EX380 exam is based on Red Hat OpenShift Container Platform 4.18. Treat that version as the anchor for your preparation. If your workplace uses another release, use it to build operational judgement, but verify version-sensitive procedures against the official EX380 objectives and current Red Hat documentation before relying on them.
What the credential can support
The credential counts toward earning Red Hat Certified Architect in OpenShift. Red Hat also lists capabilities associated with the credential that include deploying Kubernetes applications, managing Operators, implementing GitOps with Jenkins, configuring enterprise authentication, managing persistent storage, and recovering failed worker nodes.
These capabilities are useful signals for deciding whether EX380 matches your role. Someone mainly developing application code may need a different certification focus. Someone responsible for cluster configuration, platform reliability, identity integration, storage, or deployment automation is closer to the exam’s intended operating context.
Who should consider EX380?
EX380 is aimed at people who already administer OpenShift or equivalent container platforms and now need to demonstrate advanced enterprise administration. Red Hat names platform engineers, system administrators, cloud administrators, enterprise architects, SREs, and DevOps engineers as intended candidates.
Red Hat recommends a current Red Hat Certified Specialist in OpenShift Administration certification or equivalent skills in OpenShift cluster and containerized-application administration. This is a recommendation about readiness, not a stated requirement that every candidate must hold that certification.
The stated prerequisite knowledge corresponds to the topics covered by the DO180 and DO280 courses for OpenShift version 4.18 and later versions. Use those course topics as a gap-checking reference if your fundamentals are uneven, but do not treat course attendance as a substitute for performing the tasks yourself.
A useful readiness test is whether you can explain both the desired configuration and the verification method. For example, it is not enough to know that an identity provider exists; you should be able to reason about identities, authentication behavior, user access, and how to confirm that the result matches the requirement.
A quick readiness decision
Schedule preparation around real gaps if you can already administer projects, troubleshoot workloads, and work confidently with OpenShift resources. Start with foundational administration study if basic cluster, container-application, or command-line tasks still require step-by-step reference material.
Your experience with self-managed OpenShift is relevant, and Red Hat states that the skills apply to managed services including Red Hat OpenShift Service on AWS and Azure Red Hat. The underlying administration concepts remain important, but do not assume that a managed service removes the need to understand authentication, storage, recovery, or application protection.
How is EX380 assessed?
Red Hat describes its certification exams as performance-based assessments. Candidates complete real tasks in live system environments rather than answering multiple-choice questions. Your study method should therefore emphasize implementation, validation, diagnosis, and recovery instead of memorizing terminology or practising only recognition questions.
A performance-based exam rewards a controlled workflow. Read the requirement, identify the affected OpenShift objects or services, make the smallest appropriate change, verify the result, and leave the environment in the requested state. Practise that sequence until it becomes more reliable than improvising under pressure.
Do not prepare with exam dumps, leaked questions, or memorization claims. They cannot replace the ability to complete the required work, and using unauthorized material can undermine both preparation quality and certification integrity.
Because the supplied official information does not specify an exam duration, question count, passing score, language list, or detailed delivery arrangement, do not build your schedule around unofficial figures. Confirm current logistics through Red Hat before booking.
A better practice-lab pattern
Create a repeatable lab routine rather than isolated demonstrations. Begin with a written requirement, implement it using supported OpenShift interfaces, test the expected behavior, introduce a controlled fault, and document how you restored service. Repeat the task without copying the original commands.
Keep a short troubleshooting record for each exercise: the symptom, the first hypothesis, the evidence you checked, the change you made, and the final verification. This trains the reasoning needed when a technically correct command fails because of a context, permission, dependency, or resource-state problem.
Which EX380 skills need deliberate practice?
The official objectives and credential description point to several connected workstreams: application deployment, Operators, GitOps, authentication and authorization, persistent storage, data protection, and node recovery. Study them as operational systems with dependencies, not as unrelated product names.
The right practice question is not simply “Can I create this object?” Ask instead: “What must be true before this works, how will I verify it, what could break, and how would I restore the intended state?” That framing turns a reading list into an administration plan.
Application deployment and Operators
Red Hat lists deploying Kubernetes applications and managing Operators among the credential’s capabilities. Practise reading an application requirement, identifying its namespaces and dependencies, applying the required resources, and checking that the resulting workload is actually usable.
For Operator exercises, distinguish installation from operation. Verify the Operator’s installation state, understand the custom resource it manages, inspect status and events, and determine whether the requested application state has converged. A common mistake is to stop after creating a custom resource without checking whether the Operator reported success or an actionable failure.
GitOps with Jenkins
Red Hat lists implementing GitOps with Jenkins among the credential’s capabilities. Preparation should focus on the relationship between the source definition, the automation process, the target cluster, and the evidence that a deployment completed as intended.
Practise tracing a change from its declared source through the pipeline to the OpenShift workload. Check which object or resource reflects the change, how failures surface, and how you would avoid treating a successful pipeline step as proof that the application is healthy. Keep the exercise focused on repeatability and verification rather than on memorizing a particular demonstration.
Authentication, identities, and access control
EX380 objectives include configuring OpenShift authentication and identities, integrating LDAP and OIDC with Red Hat SSO Keycloak, and managing multiple identity providers. They also include configuring role-based access control, authentication tokens, and authentication certificates with kubeconfig files.
Practise these topics as separate layers. First establish how a user or service authenticates. Then determine which identity and group information is available. Finally apply the least access needed through roles, bindings, tokens, or certificates and verify access from the appropriate context.
Use more than an administrator account in the lab. Test a permitted operation and a denied operation, inspect the active context, and confirm that the credential or kubeconfig file being used is the one you intended. This catches a frequent preparation error: believing that a configuration works because a highly privileged session masked an authorization problem.
Persistent storage and application protection
Red Hat identifies persistent storage as a credential capability, while EX380 objectives include backing up and restoring applications with OpenShift API for Data Protection. The stated protection scope includes application data, resources, images, and volume snapshots.
A useful exercise is to separate the objects that define an application from the data that application writes. Practise identifying both, creating a protection workflow, checking its status, and restoring into a controlled target. Then verify application behavior and data presence rather than accepting a completed operation as sufficient evidence.
Do not assume that a backup is useful merely because a backup resource exists. Record what was included, where the protected material is represented, what dependencies the restore needs, and which checks demonstrate that recovery succeeded.
Worker-node recovery
Recovering failed worker nodes is listed among the credential’s capabilities. Preparation should include both the cluster perspective and the workload perspective: determine how the node failure affects scheduling, inspect the condition of affected workloads, and follow the supported recovery approach for the scenario.
Practise distinguishing a node problem from an application problem. Check node state, scheduling consequences, events, and workload placement before changing resources. After recovery, verify that the node returns to the intended role and that workloads have reached an acceptable state. Avoid making broad changes simply to make symptoms disappear.
How should you build a study sequence?
Study in dependency order: establish OpenShift administration fluency, then secure access, deploy and automate applications, add storage and protection, and finish with recovery and integrated exercises. This sequence reduces the risk of practising advanced workflows on a weak foundation.
Start with a skills inventory based on the official objective areas. Mark each topic as “can perform,” “can perform with reference,” or “cannot yet perform.” Schedule lab time for the last two categories, but spend extra time on tasks that combine several categories, such as deploying a protected application through an authenticated workflow.
Phase one: confirm the foundation
Review the administration topics associated with DO180 and DO280 for OpenShift version 4.18 and later versions, then test yourself in a lab. The goal is not to reread every lesson; it is to identify whether ordinary cluster and containerized-application administration is automatic enough to support advanced work.
Practise navigating namespaces, inspecting resources and events, reading status conditions, switching contexts safely, and diagnosing a workload that does not reach the expected state. If these actions are slow or uncertain, address them before moving to identity integration or recovery exercises.
Phase two: secure the platform
Next, work through authentication, identity providers, RBAC, tokens, certificates, and kubeconfig handling. Make each exercise produce observable evidence: a successful login, a deliberately denied operation, a correctly scoped service identity, or a verified certificate-based context.
Use separate test identities and write down the intended access boundary before configuring it. This prevents a common error in study labs: granting cluster-wide privileges because they are convenient, then never learning whether the narrower requirement would have worked.
Phase three: deploy and automate
Combine application deployment, Operators, and GitOps with Jenkins after the security foundation is stable. Build from a simple application to a managed application, then introduce a declared change and trace it through the automation path.
At each step, define success before you begin. For a deployment, that may include resource readiness and application reachability. For an Operator, it may include a healthy custom resource. For GitOps, it may include both the pipeline result and the target-state verification.
Phase four: protect and recover
Finish the core sequence with persistent storage, OpenShift API for Data Protection, and worker-node recovery. These topics are most valuable when tested against applications you deployed earlier, because they expose dependencies that isolated commands hide.
Create a restore checklist and use it repeatedly. Include the protected application resources, application data, images, and volume snapshots where the exercise requires them. For node recovery, include workload impact, scheduling behavior, remediation, and post-recovery validation.
Phase five: integrate under constraints
Use integrated practice to decide whether you are ready to schedule. Give yourself a written scenario that combines several domains, restrict unnecessary administrative shortcuts, and require a final verification report. The aim is dependable execution, not an artificial imitation of undisclosed exam tasks.
After each run, classify every delay: missing knowledge, command syntax, navigation, diagnosis, or verification. Fix the category causing the delay rather than repeating the same scenario unchanged. Readiness improves when each practice attempt has a specific correction target.
What should a practical roadmap look like?
A flexible roadmap should move from assessment to focused labs, then to mixed scenarios and a scheduling decision. The calendar length depends on your existing OpenShift experience, so use demonstrated performance—not a preset number of study days—as the trigger for the next phase.
In the first study block, inventory the official skill areas and establish a working lab. In the next block, practise authentication and authorization. Follow with application deployment, Operators, and GitOps. Then cover storage, protection, and worker recovery. Reserve the final block for integrated tasks and review of recurring mistakes.
At the end of each block, produce something verifiable: a working configuration, a controlled failure and recovery, or a concise runbook. If you cannot reproduce the result after resetting the lab, mark the topic as incomplete even if the first attempt appeared successful.
When integrated exercises become repeatable, check Red Hat’s current exam information and decide whether to schedule. If several domains still depend on copied commands or privileged shortcuts, delay booking and target those weaknesses first. Scheduling too early turns avoidable uncertainty into administrative pressure.
A weekly review loop
At the close of each study cycle, rebuild one earlier exercise from a clean starting point. Explain why each major step is required, inspect the result, and remove any permissions or resources that were only temporary. This checks retention and prevents a lab from succeeding because of hidden state.
Keep a compact personal reference organized by task outcome rather than by product feature. For example, group notes under “verify identity integration,” “diagnose an unready workload,” or “confirm restore completeness.” Do not turn the reference into a script you follow without understanding.
Which preparation mistakes cost the most?
The most damaging mistakes are usually procedural: studying only definitions, relying on an administrator account, skipping verification, and ignoring recovery. Correct them by making every lab task end with evidence and by testing both normal and failure paths.
Another mistake is treating all OpenShift environments as identical. EX380 is based on OpenShift Container Platform 4.18, while the official page also describes applicability to self-managed OpenShift and managed services. Use your environment for experience, but verify version-sensitive and service-specific assumptions before exam preparation depends on them.
Do not confuse familiarity with readiness. Watching a deployment succeed once, recognizing an Operator name, or reading about a backup workflow does not demonstrate that you can reproduce the result after a reset or diagnose it when a prerequisite is missing.
A diagnostic checklist for weak areas
If a task fails, ask five questions: Was I in the correct project or context? Did I have the intended identity and permissions? Did the dependent resource exist and become ready? Did the command report an error that I overlooked? What independent check proves the final state?
Use the answers to choose the next exercise. A context error calls for safer navigation habits; an RBAC error calls for identity testing; a dependency error calls for status and event inspection; a verification error calls for explicit acceptance criteria. This is more efficient than repeating a full lab without isolating the cause.
How do you schedule EX380 responsibly?
Red Hat provides an online scheduler for scheduling and managing certification exams through a Red Hat account. Before selecting an appointment, confirm the current official EX380 information, your account details, and the available scheduling options shown by Red Hat.
The supplied official sources do not establish a fixed price, appointment duration, delivery location, language list, rescheduling rule, or test-day equipment requirement. Do not rely on third-party listings for those details when making a booking decision; use the official scheduler and Red Hat exam information instead.
Schedule only after you can complete mixed administrative tasks without depending on a memorized sequence. Your final readiness check should include access control, authentication integration, application deployment, Operators, GitOps, storage, application protection, and node recovery, with verification for each area.
Red Hat states that its certifications have three-year validity and may be maintained through flexible renewal paths. After earning the credential, check the current certification program guidance when planning renewal rather than assuming that one path will always apply.
The final pre-booking decision
Book when your evidence shows repeatable execution across the objectives, not merely broad familiarity. Delay when you still lose time locating the right context, cannot explain why an operation failed, or finish a protection or recovery exercise without proving the application state afterward.
Before scheduling, save your official reference links, review any current exam-page changes, and decide what you will study in the final review period. Keep that review focused on identified weaknesses rather than attempting to learn every OpenShift feature outside the stated scope.
What should you do next?
Begin with the official EX380 page and write a personal checklist from its stated audience, prerequisite knowledge, capabilities, and objectives. Then classify your current ability for each area and create a lab exercise that produces observable evidence. This turns a broad certification goal into decisions you can act on immediately.
If foundational administration is the gap, work through the relevant DO180 and DO280 subject areas for OpenShift 4.18 and later versions before attempting advanced integrated scenarios. If the foundation is solid, prioritize identity boundaries, storage and protection verification, automation outcomes, and failure recovery.
When your practice results are consistent, use Red Hat’s scheduler to manage the booking process through your Red Hat account. Recheck official details close to scheduling because unsupported assumptions about format or logistics can create avoidable problems.
The credential is most useful when it reflects work you can perform after the exam as well as during it. Keep the lab notes, recovery checklists, and verification habits you developed; they provide a practical bridge from preparation to enterprise OpenShift administration.
Conclusion
EX380 preparation should be organized around reliable administration outcomes: secure identities, correctly deployed applications, controlled automation, durable storage, recoverable data, and resilient worker capacity. Red Hat’s performance-based format makes hands-on repetition essential. Use the OpenShift Container Platform 4.18 scope, the stated prerequisite knowledge, and the official objective areas to identify gaps; then schedule through Red Hat only when integrated practice shows that you can implement and verify the required work independently.