Pass the RedHat Red Hat OpenShift EX380 Questions and answers with ExamsMirror

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

==========

Deploy event router resources

Apply a deployment/serviceaccount/rolebinding manifest for eventrouter:

oc apply -f eventrouter.yaml -n openshift-logging

Eventrouter watches event API and writes them to stdout (collected by logging).

Verify eventrouter pod is running

oc -n openshift-logging get pods | grep -i event

Trigger some events

oc -n default run evtest --image=busybox --restart=Never -- sleep 1

oc -n default delete pod evtest

Creation/deletion generates events.

Query logs for events

In the logging UI/backend, search for the namespace/pod name evtest or eventrouter messages.

Explanation: Validates that events are being converted to searchable logs.

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.

==========

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.

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

Step 1: Log in to the OpenShift web console with an account that has sufficient cluster administrative privileges.

This Task is performed from the GUI, not the CLI. The lab hint explicitly places this under the worker node details page in the console.

Step 2: Navigate to Compute .

This area contains node-level resources, including control plane and worker nodes.

Step 3: Open Nodes .

Here you can view all nodes currently registered in the cluster.

Step 4: Select the required worker node .

Choose the exact worker node referenced by the lab Task SIMULATION .

Step 5: Open the Details tab.

The taint configuration is managed from the selected node’s details view.

Step 6: Locate the Taints section and click Edit .

A taint is used to control pod scheduling. If a worker has a taint, pods without matching tolerations may not schedule there.

Step 7: Remove the unwanted taint entry.

Removing the taint makes the worker eligible again for normal scheduling behavior, depending on the rest of the cluster policy.

Step 8: Click Save .

This commits the change so the node is updated and the scheduler can evaluate it without that taint.

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

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.

==========

Create PDB

cat < < EOF | oc -n payments apply -f -

apiVersion: policy/v1

kind: PodDisruptionBudget

metadata:

name: api-pdb

spec:

minAvailable: 2

selector:

matchLabels:

app: api

EOF

minAvailable: 2 blocks evictions that would reduce availability below 2.

Verify PDB

oc -n payments get pdb

oc -n payments describe pdb api-pdb

==========

Step 1: Make sure Velero is installed and configured in the environment.

The Task SIMULATION assumes an existing backup named backup-app-daily is already present.

Step 2: Run the restore command:

velero restore create --from-backup backup-app-daily

Step 3: Confirm the restore request is submitted.

The lab output shows:

Restore request "backup-app-daily-2024" submitted successfully.

Detailed explanation:

This command instructs Velero to create a restore operation using the existing backup called backup-app-daily. Velero is commonly used to protect Kubernetes and OpenShift resources by backing up object definitions and, when configured, persistent data integrations. The command does not manually recreate resources one by one; instead, it leverages the metadata captured during backup. A successful restore submission means the request has been accepted, not necessarily that every object has already been fully restored. In practical administration, you would often follow this by checking restore status and validating the application namespace, pods, services, routes, and storage bindings. This lab Task SIMULATION focuses specifically on initiating the restore from the named backup source.

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

Install OADP via Web Console

Operators → OperatorHub → search OADP / OpenShift API for Data Protection → Install

Explanation: This operator manages Velero and backup integrations.

Verify the operator CSV is installed

oc get csv -A | grep -i -E "oadp|data protection|velero"

Confirms installation succeeded.

Verify pods in the OADP namespace (commonly openshift-adp)

oc get pods -n openshift-adp

You should see Velero/OADP-related pods in Running state.

==========

Start the restore

velero restore create orders-restore --from-backup orders-full

Monitor restore status

velero restore get

velero restore describe orders-restore --details

Validate restored resources

oc -n orders get all

oc -n orders get pvc

Ensure deployments/pods/services and PVCs exist and pods become Running.

==========