EX380 Red Hat Certified Specialist in OpenShift Automation and Integration Questions and Answers

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

==========

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.

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

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

==========

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.

==========

Patch deployment with preferred podAntiAffinity

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

"spec":{"template":{"spec":{"affinity":{

"podAntiAffinity":{

"preferredDuringSchedulingIgnoredDuringExecution":[{

"weight":100,

"podAffinityTerm":{

"labelSelector":{"matchLabels":{"app":"api"}},

"topologyKey":"kubernetes.io/hostname"

}

}]

}

}}}}

}'

Encourages spread across nodes to reduce single-node impact.

Verify spread

oc -n payments get pods -o wide

==========

Step 1: Make sure the context already exists in the kubeconfig file.

This follows the context creation Task SIMULATION .

Step 2: Run the command:

oc config use-context audit --kubeconfig audit.config

Step 3: Confirm the active context switches successfully.

The lab output shows:

Switched to context "audit".

Detailed explanation:

This command activates the audit context inside the specified kubeconfig file. Once selected, subsequent oc commands using that kubeconfig will default to the cluster, user, and namespace associated with that context. This is operationally important because many administration mistakes come from running commands against the wrong cluster or project. Using explicit context switching reduces that risk and makes the kubeconfig usable for the intended audit workflow. In exams and real environments alike, the context is what turns separate kubeconfig elements into a working session configuration. Without switching to the correct context, even a well-formed kubeconfig may not be used as expected.

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

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: 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.

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

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.

==========