RedHat EX380 Actual Free Exam Questions & Community Discussion

See the solution below in Explanation:
Explanation:
* 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

See the solution below in Explanation:
Explanation:
* 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 >

See the solution below in Explanation:
Explanation:
Step 1: Confirm the service account exists in auth-audit.
It must exist before a role can be assigned to it.
Step 2: Run the command:
oc adm policy add-cluster-role-to-user cluster-reader system:serviceaccount:auth-audit:audit Step 3: Verify the binding is added.
The lab output shows:
clusterrole.rbac.authorization.k8s.io/cluster-reader added: "system:serviceaccount:auth-audit:audit" Detailed explanation:
This binds the cluster-reader cluster role to the audit service account. The full subject format system:
serviceaccount:namespace:name is required because OpenShift RBAC needs the exact service account identity. The cluster-reader role is broader than a project-scoped view role because it allows read-level access across cluster resources. This is appropriate for auditing or inspection use cases where the account must observe but not modify. The distinction between cluster roles and namespaced roles is important: cluster roles apply to non-namespaced resources and broad cluster visibility, while local roles are limited to individual projects. This Task is a classic RBAC operation that combines identity creation with controlled privilege assignment.

See the solution below in Explanation:
Explanation:
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.

See the solution below in Explanation:
Explanation:
Step 1: Log in to the OpenShift web console.
This Task is explicitly defined as a GUI workflow.
Step 2: Navigate to Operators .
Installed logging components are managed through the operator framework.
Step 3: Open Installed Operators .
This lists operators already deployed in the cluster.
Step 4: Select Red Hat OpenShift Logging .
This operator manages the cluster logging stack and its custom resources.
Step 5: Open the ClusterLogging instance.
The Task SIMULATION refers to editing the existing ClusterLogging custom resource.
Step 6: Switch to YAML View .
This allows direct editing of the logging custom resource specification.
Step 7: Edit the collection type and set it to vector.
This changes the log collector implementation.
Step 8: Click Save .
The operator will reconcile the resource and apply the updated collector configuration.
Detailed explanation:
The ClusterLogging custom resource controls the logging stack behavior in OpenShift. Changing the collection type to vector updates which collector technology is used for gathering node and container logs. In operator-managed platforms, direct YAML edits to the custom resource are the preferred method for changing managed behavior because the operator then applies and maintains the desired state. This Task tests both navigation skills in the web console and knowledge of where logging behavior is configured. Saving the resource triggers reconciliation, which is a core OpenShift operator pattern: the declared configuration is read and enforced by the operator rather than by manual per-pod changes.