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

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.

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

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.

==========

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

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

==========

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 secret for cloud credentials (S3-compatible example)

oc -n openshift-adp create secret generic cloud-credentials \

--from-file=cloud=/path/to/credentials

Velero uses this secret to authenticate to object storage.

Create/Update the DataProtectionApplication (DPA)

Apply a DPA CR that defines:

backupLocations (bucket, endpoint URL, region, etc.)

snapshotLocations (if using snapshots)

Verify BackupStorageLocation and SnapshotLocation

velero backup-location get

velero snapshot-location get

Status should be Available, meaning storage config is valid.

==========

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

==========

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

==========