Free Practice Questions for RedHat EX380 Exam

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 a local htpasswd file with a test user

htpasswd -c -B -b /tmp/htpass.txt testuser RedHat123!

-c creates a new file (use only once).

-B uses bcrypt hashing (recommended).

-b supplies password non-interactively (good for labs).

Create the HTPasswd secret in openshift-config

oc -n openshift-config create secret generic htpass-secret --from-file=htpasswd=/tmp/htpass.txt

OAuth reads the htpasswd key from this secret.

Edit OAuth and add the HTPasswd provider (keep LDAP intact)

oc edit oauth cluster

Add another entry under spec.identityProviders:

- name: local-htpasswd

mappingMethod: claim

type: HTPasswd

htpasswd:

fileData:

name: htpass-secret

This adds a second login option while preserving LDAP.

Restart OAuth pods

oc -n openshift-authentication delete pod -l app=oauth-openshift

Ensures the updated list of identity providers is loaded.

Verify login works for htpasswd user

Log in via console using testuser.

Confirm the user is created:

oc get user testuser

==========

Run group sync with prune controls

oc adm groups sync --sync-config=groupsync.yaml --confirm --prune-whitelist=/tmp/whitelist.txt

Prune removes stale memberships/groups, but whitelist protects selected groups from pruning.

Verify group membership reflects LDAP

oc describe group < groupname >

Confirms removed users are no longer listed.

==========

Generate private key and CSR

openssl genrsa -out audit2.key 2048

openssl req -new -key audit2.key -out audit2.csr -subj "/CN=audit2/O=auditors"

CN becomes username; O can map to groups in some setups.

Base64 encode CSR for the API object

CSR=$(base64 -w0 audit2.csr)

Kubernetes CSR object expects base64-encoded request data.

Create the CSR object

cat < < EOF | oc apply -f -

apiVersion: certificates.k8s.io/v1

kind: CertificateSigningRequest

metadata:

name: audit2-csr

spec:

request: ${CSR}

signerName: kubernetes.io/kube-apiserver-client

usages:

- client auth

EOF

Approve the CSR

oc adm certificate approve audit2-csr

Approval triggers certificate issuance.

Extract the signed certificate

oc get csr audit2-csr -o jsonpath='{.status.certificate}' | base64 -d > audit2.crt

Produces the client certificate file.

Build kubeconfig using cert/key

oc config set-credentials audit2 \

--client-certificate=audit2.crt --client-key=audit2.key \

--embed-certs=true --kubeconfig=audit2.kubeconfig

oc config set-cluster lab \

--server="$(oc whoami --show-server)" \

--insecure-skip-tls-verify=true \

--kubeconfig=audit2.kubeconfig

oc config set-context audit2 \

--cluster=lab --user=audit2 --namespace=default \

--kubeconfig=audit2.kubeconfig

Creates a kubeconfig that authenticates using client certificates.

Test

oc --kubeconfig=audit2.kubeconfig get ns

==========

Create namespace and service account

oc new-project ci

oc -n ci create sa ci-bot

The SA will represent automation access.

Grant permissions (example: edit in namespace)

oc -n ci policy add-role-to-user edit system:serviceaccount:ci:ci-bot

Without permissions, token auth succeeds but API actions are denied.

Generate token (TokenRequest)

TOKEN=$(oc -n ci create token ci-bot)

OCP issues a short-lived token by default (good practice).

Create kubeconfig using the token

oc config set-cluster lab --server="$(oc whoami --show-server)" \

--insecure-skip-tls-verify=true --kubeconfig=ci-bot.kubeconfig

oc config set-credentials ci-bot --token="$TOKEN" --kubeconfig=ci-bot.kubeconfig

oc config set-context ci --cluster=lab --user=ci-bot --namespace=ci \

--kubeconfig=ci-bot.kubeconfig

oc config use-context ci --kubeconfig=ci-bot.kubeconfig

This produces a self-contained kubeconfig for CI automation.

Test access

oc --kubeconfig=ci-bot.kubeconfig get pods

==========

Annotate the namespace with default tolerations

oc annotate ns payments \

scheduler.alpha.kubernetes.io/defaultTolerations='[{"key":"dedicated","operator":"Equal","value":"payments","effect":"NoSchedule"}]' \

--overwrite

Some clusters honor this pattern; if not, the fallback is mutating admission or editing workloads.

Create a new pod/deployment in the namespace

Then verify its spec includes tolerations:

oc -n payments get pod < pod > -o yaml | grep -n tolerations -A5

==========

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.

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

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.

Patch deployment with toleration

oc -n payments patch deploy api --type=merge -p '{

"spec":{"template":{"spec":{"tolerations":[

{"key":"dedicated","operator":"Equal","value":"payments","effect":"NoSchedule"}

]}}}

}'

Toleration allows pods to schedule onto tainted nodes.

Verify scheduling

oc -n payments get pods -o wide

==========