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

Create a namespace for the sync job

oc new-project id-sync

Keeps the automation components organized.

Create a service account for the sync job

oc -n id-sync create sa group-sync

CronJob runs under this SA identity.

Grant cluster permissions to manage groups

oc adm policy add-cluster-role-to-user cluster-admin system:serviceaccount:id-sync:group-sync

In real environments you should scope down, but lab Task SIMULATIONs often accept cluster-admin for speed.

Create a ConfigMap for groupsync.yaml and Secret(s) for bind password/CA

Mount them into the job container.

Create CronJob to run group sync

Command inside job:

oc adm groups sync --sync-config=/config/groupsync.yaml --confirm

The CronJob ensures periodic reconciliation with LDAP.

Verify job runs

oc -n id-sync get cronjob

oc -n id-sync get jobs

oc -n id-sync logs job/ < job-name >

==========

Verify logging namespace and resources

oc get ns openshift-logging

oc -n openshift-logging get clusterlogforwarder

ClusterLogForwarder configures pipelines and outputs.

Create/Edit ClusterLogForwarder (example structure)

Define an output (external system) and pipeline selecting application logs.

Apply via YAML:

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

Validate collector pods are healthy

oc -n openshift-logging get pods

Forwarding relies on collectors (vector/fluentd depending config).

Generate a test log line

oc -n openshift-logging run logger --image=busybox --restart=Never -- /bin/sh -c 'echo hello-forwarding; sleep 5'

This creates a known message to search in the external endpoint.

Confirm logs arrive at destination

Use your external system’s query/search to confirm hello-forwarding.

==========

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.

==========

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.

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

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.

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

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: Ensure the target project exists.

The lab specifies the namespace/project auth-audit.

Step 2: Run the command:

oc create sa audit -n auth-audit

Step 3: Verify creation.

The lab output shows:

serviceaccount/audit created

Detailed explanation:

This creates a service account named audit in the auth-audit namespace. Service accounts provide non-human identities for workloads and automation processes running inside the cluster. They are also commonly used when controlled API access is needed for scripts, jobs, or external kubeconfig generation. Creating a dedicated service account instead of using the default one is good practice because it supports least privilege and clearer access tracking. In exam and administration scenarios, service accounts are often paired with explicit RBAC bindings to grant only the permissions needed for the intended Task SIMULATION . This step lays the identity foundation before assigning a role in the following Task SIMULATION .

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

Step 1: Verify the cluster name, namespace, and user name that should be referenced.

The lab uses cluster api-ocp4-example-com:6443, namespace audit-ns, and user audit-sa.

Step 2: Run the command:

oc config set-context audit --cluster api-ocp4-example-com:6443 --namespace audit-ns --user audit-sa --kubeconfig audit.config

Step 3: Confirm context creation.

The lab output shows:

Context "audit" created.

Detailed explanation:

A kubeconfig context ties together three things: a cluster endpoint, a user identity, and optionally a default namespace. This Task creates a context named audit in the file audit.config. Contexts are useful because they simplify repeated administration by letting the user switch between prepared working environments instead of re-entering cluster and namespace details each time. The namespace portion is especially helpful for project-scoped operations, because commands run under that context default to the chosen namespace. Accuracy matters here: if the user name in the context does not match the credentials entry or the cluster name does not exist in the kubeconfig, the context will not function as intended.

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

Confirm resources and PVCs exist

oc -n orders get all

oc -n orders get pvc

Ensures there is something meaningful to back up.

Create backup including volume snapshots

velero backup create orders-full --include-namespaces orders --snapshot-volumes

Captures Kubernetes objects and requests PV snapshots where supported.

Check status/details

velero backup describe orders-full --details

velero backup logs orders-full

Review warnings/errors and confirm snapshot actions.

==========

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.

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