Patch deployment with toleration

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

"spec":{"template":{"spec":{"tolerations":[

{"key":"dedicated","operator":"Equal","value":"payments","effect":"NoSchedule"}

]}}}

}'

Toleration allows pods to schedule onto tainted nodes.

Verify scheduling

oc -n payments get pods -o wide

==========

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.

==========

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.

==========

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.

==========

Log in to OpenShift internal registry

oc registry login

Allows podman to push to the internal registry.

Pull external image

podman pull docker.io/library/nginx:1.25

Gets the image locally.

Tag for internal registry destination

podman tag nginx:1.25 image-registry.openshift-image-registry.svc:5000/orders/nginx:1.25

Uses the cluster service DNS name (works inside cluster network).

Push to internal registry

podman push image-registry.openshift-image-registry.svc:5000/orders/nginx:1.25

Update deployment to use internal image

oc -n orders set image deploy/web web=image-registry.openshift-image-registry.svc:5000/orders/nginx:1.25

Verify rollout

oc -n orders rollout status deploy/web

oc -n orders 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.

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

Step 1: Identify the pending certificate signing request.

The lab names it audit-csr.

Step 2: Run the approval command:

oc adm certificate approve audit-csr

Step 3: Confirm approval.

The lab output shows:

certificatesigningrequest.certificates.k8s.io/audit-csr approved

Detailed explanation:

In Kubernetes and OpenShift, a CSR must be approved before the requester can use the signed certificate for authentication. This Task approves the CSR named audit-csr, which is likely associated with the audit user or service account access flow in the lab. Certificate-based authentication is commonly used for kubeconfig access because it enables secure client identity without relying solely on tokens. Until the CSR is approved, the certificate cannot be trusted by the cluster API for authenticated operations. Administrative approval is therefore a gatekeeping step that ensures only intended certificate requests become valid credentials. This Task is part of a broader kubeconfig workflow that continues with setting credentials and defining context.

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