RedHat EX380 Red Hat Certified Specialist in OpenShift Automation and Integration Exam Practice Test

Create the schedule

velero schedule create orders-daily \

--schedule "0 1 * * *" \

--include-namespaces orders \

--snapshot-volumes

Cron format: minute hour day month weekday.

Verify schedule exists

velero schedule get

Confirm backups are created by the schedule

velero backup get | grep orders-daily

Scheduled backups usually have names derived from the schedule.

==========

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

==========

Export objects to YAML

oc -n orders get deploy,svc,route,cm,secret -o yaml > orders-app.yaml

Exports key application resources.

Create target namespace

oc new-project orders-copy

Apply exported YAML

oc -n orders-copy apply -f orders-app.yaml

Recreates resources (some fields may need adjustment, like namespaces or immutable fields).

Validate

oc -n orders-copy get all

==========

Step 1: Identify the application namespace after restore.

The lab shows the namespace as my-app-namespace.

Step 2: Run the SCC assignment command:

oc adm policy add-scc-to-user anyuid -z default -n my-app-namespace

Step 3: Confirm the role binding is applied.

The lab output shows:

clusterrole.rbac.authorization.k8s.io/system:openshift:scc:anyuid added: "default"

Detailed explanation:

After a restore, the application may fail if its pods require a security context not permitted by the default SCC allocation. This command grants the anyuid SCC to the default service account in the my-app-namespace project. The -z default syntax targets the default service account, which many restored workloads use if no custom service account is defined. The anyuid SCC allows containers to run with arbitrary user IDs, which some legacy or prebuilt images require. In OpenShift, SCC mismatches commonly cause pods to remain in pending or crash-related states. Assigning the proper SCC resolves those admission issues so workloads can start successfully. This step is therefore a post-restore operational fix to align security policy with application requirements.

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

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 >

==========

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.

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

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.

==========

Step 1: Ensure the client certificate and private key files are available.

The lab uses audit.crt and tls.key.

Step 2: Run the command:

oc config set-credentials audit --client-certificate audit.crt --client-key tls.key --embed-certs --kubeconfig audit.config

Step 3: Confirm the user entry is written.

The lab output shows:

User "audit" set.

Detailed explanation:

This command creates or updates the audit user entry inside the kubeconfig file audit.config. It points the user to a client certificate and private key, and the --embed-certs option stores certificate material directly inside the kubeconfig rather than only referencing external files. That makes the kubeconfig more portable because it can be moved and used without separately copying the certificate files, provided the embedded content is valid. In certificate-based authentication, the private key proves client possession while the certificate presents the approved identity. If the certificate and key do not match, authentication will fail. This step does not yet define what cluster or namespace the user works against; it only defines the credential identity.

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

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.

==========

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.

==========

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 .

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

Label the chosen worker nodes

oc label node worker-1 workload=payments

oc label node worker-2 workload=payments

Node labels are key/value metadata used by the scheduler.

Add a nodeSelector to the deployment

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

"spec":{"template":{"spec":{"nodeSelector":{"workload":"payments"}}}}

}'

Forces pods to schedule only to nodes that match the label.

Verify placement

oc -n payments get pods -o wide

Confirms pods are running on the intended nodes.

==========