RedHat Updated EX380 Exam Questions and Answers by jai

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 >

==========

Find the alert name and labels

Web console: Observe → Alerts → click the alert to view label set.

Open Alertmanager silences

Observe → Alerting → Alertmanager → Silences → Create silence

Explanation: Silences mute alerts matching label filters.

Create the silence

Add matcher: alertname = < ALERT_NAME >

Duration: 2 hours

Save.

Verify the alert shows as silenced

The alert should indicate it is silenced in the UI.

==========

Step 1: Make sure the context already exists in the kubeconfig file.

This follows the context creation Task SIMULATION .

Step 2: Run the command:

oc config use-context audit --kubeconfig audit.config

Step 3: Confirm the active context switches successfully.

The lab output shows:

Switched to context "audit".

Detailed explanation:

This command activates the audit context inside the specified kubeconfig file. Once selected, subsequent oc commands using that kubeconfig will default to the cluster, user, and namespace associated with that context. This is operationally important because many administration mistakes come from running commands against the wrong cluster or project. Using explicit context switching reduces that risk and makes the kubeconfig usable for the intended audit workflow. In exams and real environments alike, the context is what turns separate kubeconfig elements into a working session configuration. Without switching to the correct context, even a well-formed kubeconfig may not be used as expected.

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

Step 1: Confirm that the repository being pushed to is the same repository watched by the GitOps/Argo CD application.

This linkage is essential because GitOps acts only on configured source repositories and paths.

Step 2: Commit the MachineConfig changes.

The lab uses:

git commit -am "Add MachineConfig for motd"

Step 3: Push the changes to the tracked branch.

The lab uses:

git push origin main

Step 4: Allow Argo CD to detect the repository change and begin synchronization.

In a standard GitOps model, the controller compares the Git repository to the cluster state and applies drift correction or new desired resources.

Detailed explanation:

This sub Task SIMULATION is the operational purpose behind the previous Git command Task SIMULATION . The point is not merely to store a file in Git; it is to update the declarative source that Argo CD uses to reconcile the cluster. Once the repository is updated, Argo CD detects the new commit and syncs the MachineConfig into the cluster according to its application definition. This demonstrates a core automation principle in OpenShift GitOps: administrators do not treat the cluster as the primary editable surface. Instead, they modify Git and let the automation layer enforce state. That provides traceability, peer review potential, rollback capability, and consistency across environments.