EX380 Exam Guide: Skills, Preparation Strategy, and Scheduling Decisions
EX380 validates whether you can plan, implement, and manage 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 advanced OpenShift administration skills. This guide helps you decide whether your current experience is sufficient, which capabilities to practise first, how to build a task-focused lab plan, and when to confirm scheduling and certification details with Red Hat.
What does EX380 validate?
EX380 is the Red Hat Certified Advanced System Administrator in OpenShift exam. Red Hat describes it as an assessment of the ability to plan, implement, and manage large-scale OpenShift Container Platform deployments in an enterprise. Passing earns the Red Hat Certified Advanced System Administrator in OpenShift credential.
The exam is based on Red Hat OpenShift Container Platform 4.18. That version matters when you choose documentation, lab material, and command examples. A preparation environment built around a substantially different OpenShift release may still help with general administration, but it should not be your only reference for version-sensitive behavior.
The credential also counts toward earning Red Hat Certified Architect in OpenShift. That makes EX380 relevant both to administrators seeking a senior-level credential and to candidates building a broader Red Hat OpenShift certification path.
Who should consider this exam?
EX380 is aimed at professionals who already administer OpenShift clusters and containerized applications, rather than candidates starting with Kubernetes or OpenShift fundamentals. Red Hat lists platform engineers, system administrators, cloud administrators, enterprise architects, SREs, and DevOps engineers among the intended audience.
Red Hat recommends a current Red Hat Certified Specialist in OpenShift Administration certification or equivalent OpenShift cluster and containerized-application administration skills. The stated prerequisite knowledge corresponds to the topics covered by the DO180 and DO280 courses for OpenShift version 4.18 and later versions.
Use that recommendation as a readiness test, not as a paperwork barrier. If you do not hold the earlier certification, assess whether you can independently inspect cluster state, diagnose failed workloads, work with storage and authentication, and explain the operational consequences of configuration changes. If those tasks still require step-by-step instructions, strengthen the foundation before concentrating on advanced objectives.
A useful readiness distinction
Course attendance and production exposure are not the same as task competence. A candidate may understand OpenShift concepts but still lose time when a deployment fails, a permission is too broad, or a recovery task depends on several resources being restored in the right order. Your preparation should therefore measure completed outcomes, not pages read or videos watched.
How is EX380 assessed?
Red Hat describes its certification exams as performance-based assessments. Candidates complete real tasks in live system environments rather than answer multiple-choice questions. Prepare to create, change, troubleshoot, validate, and recover OpenShift resources under practical constraints.
This format changes the meaning of “knowing” a topic. You need to identify the right object and command, understand dependencies, verify the result, and recover from an incorrect assumption. Memorizing isolated command strings is less useful than practising a repeatable workflow: inspect, plan, modify, validate, and document or clean up.
Do not treat exam dumps, leaked questions, or memorized answer sets as a preparation method. They cannot substitute for the ability to perform legitimate administration work, and relying on them can leave gaps in troubleshooting and verification.
What performance-based preparation looks like
A strong exercise has a required outcome and a verification condition. For example, instead of merely reading about identity providers, configure an authentication scenario in a controlled lab, test access with an appropriate user, inspect the resulting identity behavior, and return the environment to a known state. The same pattern works for storage, Operators, GitOps, and recovery.
Which technical capabilities should you practise?
The published EX380 capabilities span application deployment, cluster administration, security, automation, storage, and recovery. Red Hat highlights deploying Kubernetes applications, managing Operators, implementing GitOps with Jenkins, configuring enterprise authentication, managing persistent storage, and recovering failed worker nodes.
The official EX380 objectives specifically include OpenShift API for Data Protection, role-based access control, authentication mechanisms, identity providers, and kubeconfig-based access. Organize study around complete operational tasks rather than treating these as unrelated vocabulary lists.
The credential page and exam page describe skills that apply to self-managed OpenShift as well as managed services including Red Hat OpenShift Service on AWS and Azure Red Hat OpenShift. The underlying administration principles remain useful across those contexts, but do not assume that every infrastructure-level action is available or identical on a managed service.
Application deployment and Operators
Practise deploying Kubernetes applications in a way that lets you inspect their resources, configuration, health, and dependencies. Then work with Operators: identify the Operator-managed resources, understand the desired state, and determine whether a problem belongs to the application, the Operator, or the surrounding cluster configuration.
A common mistake is to edit generated or Operator-managed resources without understanding reconciliation. Before changing an object, identify its owner and the resource that should be treated as the source of intent. After the change, verify both the immediate object and the resulting workload behavior.
GitOps with Jenkins
Red Hat lists implementing GitOps with Jenkins among the credential capabilities. Practise tracing a desired configuration from its source through the automation process to the OpenShift resources it should produce. Your lab should include validation of the resulting deployment, not just successful execution of a pipeline.
Avoid studying GitOps as a collection of product names. Focus on ownership, change flow, credentials, failure visibility, and drift: what initiates the change, where configuration is stored, how the process authenticates, and how you establish that the cluster reached the intended state.
Authentication, RBAC, and kubeconfig
EX380 objectives include configuring role-based access control, authentication tokens, and authentication certificates with kubeconfig files. They also include configuring OpenShift authentication and identities, integrating LDAP and OIDC with Red Hat SSO Keycloak, and managing multiple identity providers.
Build exercises that separate authentication from authorization. First determine whether the identity can log in or obtain a credential. Then determine which groups, roles, bindings, and namespaces govern access. Finally, test the exact action with the relevant user or kubeconfig context. This prevents the frequent mistake of diagnosing a permission failure as an identity-provider failure.
For certificates and kubeconfig files, practise identifying the cluster, user, context, and credential source before using a file. Confirm that a test command is operating against the intended cluster and namespace. An incorrect context can make a correct command appear broken or can cause an unintended change in another environment.
Backup and recovery with OADP
EX380 objectives include backing up and restoring applications with OpenShift API for Data Protection, including application data, resources, images, and volume snapshots. Study backup and restore as an application recovery process, not as a single command.
Create a lab scenario with namespaced resources and persistent data, perform the appropriate backup workflow, remove or alter the application, and restore it. Verify resource objects, workload readiness, data integrity, images where relevant, and volume behavior. Record what was included and what was not; a backup that completes successfully is not necessarily a recovery that meets the application requirement.
A frequent preparation error is testing only control-plane metadata. Include persistent application data and the dependencies that make the workload usable. Recovery practice should also include reading status and logs so that you can distinguish a restore failure from a post-restore application configuration problem.
Persistent storage
Storage practice should connect claims, volumes, access modes, storage classes, and workload behavior. Build and inspect a persistent application, then test what happens when the claim cannot bind, the requested characteristics do not match available storage, or the workload mounts the volume in an unexpected way.
Do not stop when a PersistentVolumeClaim is created. Confirm binding, mount behavior, application read and write operations, and the effect of restarting or rescheduling the workload. Explain why the selected storage configuration satisfies the application rather than assuming that a bound claim proves the full task is complete.
Failed worker-node recovery
Recovering a failed worker node requires more than making a node appear healthy. Practise identifying the failure’s scope, protecting workloads where appropriate, using the supported administrative process, and validating that scheduling and application behavior have returned to the required state.
Use a controlled lab and follow current Red Hat procedures for the OpenShift 4.18-based exam environment. Avoid improvised destructive actions on a real cluster. Your objective is to understand the sequence and the evidence for completion: node condition, workload placement, capacity, and application health.
Are exam blueprint percentages available?
The supplied official EX380 research does not provide domain percentage weights. Do not assign numerical priority to authentication, storage, backup, GitOps, or any other domain based on an unofficial summary. Use the published objectives and your own performance gaps to decide study order, then check Red Hat’s current exam page for any later blueprint information.
A practical priority is to begin with the areas that combine several dependencies or that you cannot complete without notes. For example, identity, storage, and recovery often require inspection and verification across multiple resources. This is a preparation recommendation, not an official weighting of the exam domains.
How should you build an EX380 lab?
Use a repeatable OpenShift 4.18-aligned environment where you can safely create workloads, change configuration, test access, and recover from mistakes. The lab should support task completion and diagnosis, not just demonstrations that produce a successful screen or command output.
Start each exercise from a known state. Write a short task statement, define what success will look like, and note the commands or observations that prove it. After completing the task, deliberately introduce one controlled fault and diagnose it. This develops the difference between implementing a configuration and operating it.
Keep a personal command reference, but organize it by decisions and verification points. A useful entry records the question a command answers, the object or scope it inspects, the expected evidence, and the next action when the result is different. This is more adaptable than copying a long list of commands without context.
A lab sequence that builds dependency awareness
First establish basic workload and namespace operations. Next add persistent storage and access control. Then introduce Operators and automation, followed by enterprise authentication and backup or restore. Finish with fault injection and recovery. This order lets later exercises depend on earlier administration skills while keeping the troubleshooting surface manageable.
For every exercise, practise five moves: identify scope, inspect current state, make the smallest appropriate change, validate the user-facing outcome, and record how to undo or repeat the work. These moves are valuable across nearly every EX380 objective.
How to use documentation without becoming dependent on it
Use official documentation to resolve version-specific syntax, prerequisites, and supported procedures. Then close the documentation and repeat the task from your own notes. If you can perform the task only while following every line, the topic is not yet stable enough for a performance-based assessment.
When an exercise fails, do not immediately rebuild the environment. Preserve the evidence, form a hypothesis, and inspect the relevant resources, events, logs, conditions, and configuration. Rebuilding can hide the cause and creates false confidence.
What is a practical EX380 study roadmap?
A staged roadmap is more effective than switching randomly among advanced topics. Begin with a skills audit, build a 4.18-focused lab, practise the core administration workflow, then rotate through security, automation, storage, backup, and recovery. Finish with integrated tasks performed without a tutorial and review only the gaps revealed by those attempts.
Stage one: measure your starting point
List the official capability areas and mark each as independent, guided, or unfamiliar. For each independent claim, require a lab demonstration. For each guided or unfamiliar area, write the missing prerequisite: a command workflow, an OpenShift concept, an authentication dependency, a storage behavior, or a recovery procedure.
Pay particular attention to the recommended DO180 and DO280 knowledge. If basic application administration or cluster operations are weak, repair those gaps before spending most of your time on OADP, external identity integration, or worker-node recovery. Advanced topics become harder when foundational inspection and resource-management habits are missing.
Stage two: make core workflows automatic
Practise namespace and workload inspection, resource editing, status interpretation, event and log review, and validation of application behavior. The purpose is not speed for its own sake; it is to reduce cognitive load so that you can reason about dependencies when a task does not behave as expected.
Repeat each task after removing your step-by-step notes. Then change one input, such as the namespace, resource name, identity, or storage request, and confirm that you can adapt without blindly repeating the original command.
Stage three: study the high-dependency areas
Work through authentication and RBAC, LDAP or OIDC integration concepts, kubeconfig credentials, Operators, Jenkins-based GitOps, persistent storage, and OADP backup and restore. Keep each exercise outcome-based. A configuration is incomplete until the intended user, application, or recovery consumer can use it and you have checked the relevant status.
For every failed attempt, write a short incident note: symptom, scope, likely cause, evidence collected, correction, and verification. This habit improves troubleshooting and gives you a targeted list for later review without turning preparation into passive note-taking.
Stage four: integrate and rehearse
Combine domains in scenarios such as deploying an application that needs persistent storage and restricted access, automating a change through Jenkins, or restoring an application whose data and images matter. Integrated practice exposes ordering problems that isolated exercises conceal.
Use unfamiliar names and starting conditions in the lab. Do not rehearse a fixed script tied to one namespace or one resource. Instead, read the task, identify the target state, inspect what already exists, and choose the least disruptive route to completion.
Stage five: decide whether to schedule
Schedule when you can complete representative tasks without tutorial dependence, recover from ordinary errors through inspection, and verify outcomes consistently. If your result depends on remembering a particular lab’s object names or on guessing what the task setter intended, continue practising.
Before booking, confirm the current exam page, version information, account requirements, and available scheduling choices. Red Hat provides an online scheduler for scheduling and managing certification exams through a Red Hat account. Scheduling details can change, so use the scheduler and official exam information rather than an old third-party listing.
What should you do in the final preparation period?
In the final preparation period, stop collecting unrelated resources and concentrate on execution quality. Review the official objectives, repeat the tasks where your evidence is weakest, and practise validation and recovery. A final session should reveal remaining uncertainty, not merely confirm that familiar notes look clear.
Use a simple final checklist: can you identify the correct cluster and namespace, inspect before changing, handle permissions deliberately, interpret failure signals, protect persistent data, and prove that the requested outcome works? Any “not always” answer should become a short lab exercise.
Do not make large untested changes to your study environment at the last moment. Keep a stable lab snapshot or a documented rebuild process, and prefer a small number of complete scenarios over many unfinished demonstrations.
Mistakes that waste preparation time
Reading only conceptual material is a problem because EX380 is performance-based. Convert every important concept into an action and a verification step.
Practising only the happy path leaves you unprepared for dependency failures. Add controlled faults such as an incorrect permission, unavailable storage characteristic, invalid identity configuration, or incomplete application dependency, then diagnose them safely.
Treating a completed command as proof of success is another common error. Check the resource condition, workload behavior, access result, data state, or recovery outcome that the task actually requires.
Using generic Kubernetes material without reconciling it with OpenShift 4.18 can create version and platform assumptions. Anchor commands and procedures to current Red Hat material and test them in an appropriate environment.
Finally, confusing the credential’s breadth with a requirement to memorize every implementation detail leads to unfocused study. Use the official objectives to define scope, then prioritize the tasks that expose your own operational weaknesses.
How do scheduling and certification validity affect planning?
Red Hat’s online scheduler is the authoritative place to manage an individual certification exam through a Red Hat account. Because availability and administrative details may vary, confirm the current options there before fixing a preparation deadline or making travel and work arrangements.
Red Hat states that its certifications have three-year validity and may be maintained through flexible renewal paths. Treat this as a credential-maintenance consideration after passing, not as a reason to rush an attempt before your practical skills are ready. Review the certification program guidance for the renewal rules that apply to your situation.
The supplied official research does not establish a universal price, exam duration, question count, language list, delivery arrangement, or appointment availability for EX380. Do not rely on pages that present those details without a current Red Hat source. Check the official exam information and scheduler when those details affect your decision.
What should you do next?
Start by comparing your current OpenShift work with the EX380 objectives, then prove the result in a controlled lab. Your next decision should be based on completed tasks and diagnosed failures: strengthen foundational administration, target a specific advanced domain, or move to integrated rehearsal and scheduling verification.
Open the current Red Hat EX380 page and record the version and objective information you will use. Build a small task log with columns for objective, lab scenario, evidence of success, failure encountered, and next review date. This turns a broad certification goal into observable work.
If the audit shows that your core OpenShift administration is not yet reliable, use the DO180 and DO280 topic coverage identified by Red Hat as a foundation. If the foundation is solid, spend the available study time on cross-domain scenarios involving access, storage, automation, backup, and recovery rather than repeating basic demonstrations.
When your practice results are consistent, use Red Hat’s scheduler to review the current booking process through your Red Hat account. Keep the official pages bookmarked so that you can recheck version, validity, and administrative information before the appointment.
Conclusion
EX380 preparation should look like advanced OpenShift operations: inspect a real system, make a justified change, manage dependencies, troubleshoot evidence, and verify the result. The official scope is broad, but the decision process is practical. Establish the 4.18 baseline, close foundational gaps, practise each capability in a lab, integrate the domains, and schedule only after your performance—not your familiarity with study material—shows readiness.
Conclusion
EX380 is best approached as a working administrator’s assessment, not a recall exercise. Use the official objectives to define the boundary, use a controlled OpenShift 4.18-aligned lab to build capability, and use failed tasks to choose what to study next. Confirm scheduling and certification-maintenance details with Red Hat, and keep preparation focused on secure implementation, reliable validation, and recovery.
