EX380 Exam Dumps - Red Hat Certified Specialist in OpenShift Automation and Integration

Identify failing node and status

oc get nodes

Confirms which node is NotReady.

Inspect node conditions and events

oc describe node < worker >

Shows kubelet condition issues (network, disk pressure, runtime, etc.).

Check MachineConfigPool state

oc get mcp

oc describe mcp worker

If MCP is degraded, node may be stuck applying a config.

Check node logs (kubelet)

oc adm node-logs < worker > --path=kubelet.log

Often reveals why node isn’t reporting Ready.

Remediate based on symptom

Examples:

If out of disk: free space, then verify kubelet recovers.

If stuck MCO: investigate current/desired config and fix broken MachineConfig.

If node cordoned/drained incorrectly: uncordon after remediation.

oc adm uncordon < worker >

Confirm node returns Ready

oc get node < worker >

==========

Step 1: Make sure the MachineConfig YAML has already been created or modified in the local Git repository.

This Task assumes the file change is ready to be committed.

Step 2: Run the command:

git commit -am "Add MachineConfig for motd" & & git push origin main

Step 3: Verify the commit succeeds and the push goes to the main branch.

The lab output shows:

[main 8d32a1] Add MachineConfig for motd

Detailed explanation:

This Task is part of a GitOps workflow. Instead of manually applying changes directly to the cluster, the desired configuration is stored in Git, and a GitOps controller such as Argo CD synchronizes the cluster to match the repository state. The command commits all tracked modified files with the message Add MachineConfig for motd and then pushes the change to the main branch. In this model, Git becomes the source of truth. A MachineConfig is typically used to manage node-level operating system configuration in OpenShift, so pushing it through GitOps ensures the change is auditable, repeatable, and reconciled declaratively. If the commit does not include the intended YAML, the synchronization mechanism will not apply the desired change.

============

Create target namespace

oc new-project gitops-demo

Destination must exist (unless Argo is configured to auto-create).

Create Application manifest

apiVersion: argoproj.io/v1alpha1

kind: Application

metadata:

name: demo-app

namespace: openshift-gitops

spec:

project: default

source:

repoURL: https://git.example.com/org/repo.git

targetRevision: main

path: manifests/demo

destination:

server: https://kubernetes.default.svc

namespace: gitops-demo

syncPolicy:

automated:

prune: true

selfHeal: true

automated: enables auto sync.

prune: removes deleted objects from Git.

selfHeal: corrects drift.

Apply Application

oc apply -f demo-app.yaml

Verify sync health

oc -n openshift-gitops get application demo-app -o yaml | grep -i -E "sync|health" -n

oc -n gitops-demo get all

==========

Create a group sync config file (example groupsync.yaml)

This file defines how OpenShift queries LDAP for groups and members.

Run a one-time group sync

oc adm groups sync --sync-config=groupsync.yaml --confirm

--confirm actually applies changes (without it, it’s a dry-run preview).

Verify groups created/updated

oc get groups

oc describe group < groupname >

Confirms group objects exist and membership is present.

==========