Prepare Smarter for the EX380 Exam
Build your exam confidence with flexible preparation resources designed around the latest EX380 exam objectives. Practice at your own pace using PDF questions, online exam simulations, or desktop practice software.
Identity Management – Create HTPasswd Secret
Correct Answer: A
Step 1: Open a terminal with oc access to the cluster.
This Task is CLI-driven and targets the openshift-config namespace.
Step 2: Run the command:
oc create secret generic rhds-ldap-secret --from-literal bindPassword=redhatocp -n openshift-config
Step 3: Verify that the secret is created successfully.
The lab output shows:
secret/rhds-ldap-secret created
Detailed explanation:
This step creates a generic secret named rhds-ldap-secret in the openshift-config namespace. The secret stores a key called bindPassword with the value redhatocp. In an identity-provider or LDAP integration workflow, the bind password is used by OpenShift when connecting to the external directory service. Storing this value in a secret is the correct operational pattern because authentication material should not be embedded directly into configuration objects. The openshift-config namespace is specifically important because cluster authentication configuration commonly references secrets and configmaps from that namespace. If the secret name or key is wrong, the authentication configuration that depends on it may fail to validate or connect properly.
============
GitOps and MachineConfig – Push MachineConfig to Git
Correct Answer: A
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.
============
Prevent workloads from running on dedicated nodes (taints)
Task Information : Apply a taint to dedicated nodes so only pods with tolerations can run there.
Correct Answer: A
Taint nodes
oc adm taint nodes worker-1 dedicated=payments:NoSchedule
oc adm taint nodes worker-2 dedicated=payments:NoSchedule
NoSchedule blocks new pods that do not tolerate the taint.
Confirm taints
oc describe node worker-1 | grep -i taints -A2
Ensures taints are present.
Validate effect
A normal deployment without tolerations will remain Pending if it can only land on those tainted nodes.
==========
Create and apply a MachineConfig (set MOTD on workers)
Task Information : Create a MachineConfig that writes /etc/motd on worker nodes.
Correct Answer: A
Create the MachineConfig YAML (example content encoded in base64)
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
name: 99-worker-motd
labels:
machineconfiguration.openshift.io/role: worker
spec:
config:
ignition:
version: 3.2.0
storage:
files:
- path: /etc/motd
mode: 0644
contents:
source: data:text/plain;charset=utf-8;base64,VGhpcyBpcyBhIHdvcmtlciBub2RlLg==
MachineConfig uses Ignition format; file content is typically base64.
Apply it
oc apply -f 99-worker-motd.yaml
Watch worker MachineConfigPool roll out
oc get mcp worker
MCP will show Updating then Updated.
Validate on a worker node (if you have node access)
Confirm /etc/motd contains the expected text.
==========
GitOps and MachineConfig – Trigger Argo CD Synchronization by Repository Update
Correct Answer: A
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.