EX280 Application Deployment And Lifecycle — Timed 10 Questions

Question 1

A BuildConfig uses an S2I strategy and needs to pull private base images from a secured external container registry. Where must the administrator configure the pull credentials so the builder pod can authenticate?

10 minute time limit — choose an answer to begin.

Accepted Answer

In the BuildConfig spec under strategy.dockerStrategy.pullSecret or source/strategy configuration. For an S2I BuildConfig, pull credentials for private base images are configured in the BuildConfig's strategy section, specifically under `strategy.sourceStrategy.pullSecret` (for S2I) or `strategy.dockerStrategy.pullSecret` (for Docker strategy). This secret is used by the builder pod to authenticate to the registry.

Answer

In the ImageStream tag policy

Answer

In the Route resource annotations

Answer

In the global cluster OAuth configuration

Question 2

An OpenShift cluster administrator needs to ensure that custom S2I builder images stored in an insecure internal registry can be successfully pulled by build pods without failing TLS verification. Where must the insecure registry be defined?

Accepted Answer

In the cluster Image resource configuration (imageregistry.config.openshift.io/cluster or image.config.openshift.io). The cluster-wide image configuration resource (image.config.openshift.io/cluster) contains the registrySources section where insecure registries are listed. This configuration is consumed by the internal registry, build pods, and kubelet to determine which registries should be contacted without TLS verification. By defining the insecure registry here, all builds and pods across the cluster can pull from it without certificate errors.

Answer

In the OAuth client definition

Answer

In the individual BuildConfig strategy environment variables

Answer

In the Project request template metadata

Question 3

An administrator is troubleshooting a failed OpenShift build. Which THREE resources or logs should the administrator check to diagnose the failure? (Choose three.)

Accepted Answer

The logs of the specific build pod using oc logs build/. Option A is correct because running `oc logs build/` retrieves the aggregated logs of the build pod, showing the exact output of the build steps and any errors that caused the failure. Option C is correct because inspecting the BuildConfig with `oc get bc/ -o yaml` reveals the build strategy (Source, Docker, or Custom), source references, triggers, and output configuration, which are common sources of build misconfiguration. Option E is correct because `oc get events` in the namespace surfaces scheduling failures, image pull errors, quota or limit issues, and other Kubernetes-level events that explain why a build pod could not run or complete. Option B is not relevant because storage class definitions are cluster-scoped and only matter if the build uses a volume that depends on them, which is not indicated here. Option D is not relevant because the default OAuth client secret relates to authentication and identity provider configuration, not to build execution or build pod failures.

Answer

The cluster-wide storage class definitions

Answer

The default OAuth client secret

Question 4

An administrator needs to configure a Deployment strategy in OpenShift. Which THREE deployment strategy types are natively supported by standard Kubernetes/OpenShift Deployments? (Choose three.)

Accepted Answer

Rolling (for DeploymentConfigs) / RollingUpdate (for Deployments). Option A is correct because OpenShift's DeploymentConfig resource natively supports the Rolling strategy (with parameters like maxSurge and maxUnavailable), which is the equivalent of the RollingUpdate strategy used by standard Kubernetes Deployments. Option C is correct because Recreate is a natively supported strategy in both Kubernetes Deployments and OpenShift DeploymentConfigs, terminating all existing pods before creating new ones, which is useful when the application cannot run multiple versions concurrently. Option E is correct because RollingUpdate is the default strategy for standard Kubernetes Deployments (and thus OpenShift Deployments), incrementally replacing pods to maintain availability during an update. Option B is not correct because BlueGreen is not a native strategy type; it must be implemented manually or via routes/services and additional tooling such as Argo Rollouts. Option D is not correct because Canvas is not a deployment strategy in Kubernetes or OpenShift; it is unrelated to the Deployment spec's strategy field.

Answer

BlueGreen

Answer

Canvas

Question 5

A production Deployment using the Rolling update strategy is failing its readiness probe during a rollout, causing the update to block and eventually time out. You need to inspect the reason for the rollout failure using the OpenShift CLI without deleting the failing pods immediately. Which oc command provides the most direct diagnostic information regarding the rollout status and blockage reason?

Accepted Answer

oc rollout status deployment/. 'oc rollout status deployment/' streams the rollout progress and reports the specific reason the rollout is blocked, such as 'Waiting for deployment spec update to be observed' or 'deployment is not progressing: ReplicaSet has timed out progressing'. It is the most direct CLI command for diagnosing rollout blockage without deleting pods.

Answer

oc get events --sort-by='.metadata.creationTimestamp'

Answer

oc describe deployment <deployment-name>

Answer

oc debug deployment/<deployment-name>

Question 6

An administrator needs to deploy a packaged Helm chart onto an OpenShift 4.14 cluster from a private Helm repository. Which oc command should be used to install the chart while securely managing repository credentials?

Accepted Answer

helm install my-release private-repo/chart-name --repo https://charts.example.com. The 'oc helm' CLI wrapper does not exist natively as 'oc helm'; however, Helm v3 integrates directly with Kubernetes/OpenShift clusters using standard 'helm install' or by configuring Helm repository add commands before installing. Alternatively, using 'oc apply' with pre-rendered manifests or 'helm install' directly against the cluster context is standard. Let's look at the standard Helm workflow used in OpenShift contexts.

Answer

oc adm helm install my-release private-repo/chart-name

Answer

oc create helmchart --name=my-release --source=private-repo

Answer

oc new-app --helm-chart=private-repo/chart-name

Question 7

You have modified a set of Kubernetes manifests using Kustomize and want to preview the exact output that will be applied to your OpenShift cluster without actually executing the changes. Which command should you run?

Accepted Answer

oc kustomize .. 'oc kustomize .' renders the Kustomize overlay in the current directory and prints the fully-resolved YAML to stdout without contacting the cluster or applying anything. It is the canonical way to preview the exact manifests that would be applied, making it ideal for dry inspection of Kustomize output.

Answer

oc diff -f kustomization.yaml

Answer

oc convert -k .

Answer

oc apply -k . --dry-run=client

Question 8

Which THREE of the following mechanisms can be used to automatically trigger a new build in an OpenShift BuildConfig? (Choose three.)

Accepted Answer

ImageChange trigger. Option B (ImageChange trigger) is correct because an OpenShift BuildConfig can define an ImageChange trigger that automatically starts a new build whenever the image stream tag referenced in the build's source or output is updated. Option D (Webhook trigger, GitHub or Generic) is correct because BuildConfigs expose webhook endpoints (GitHub, GitLab, Bitbucket, and Generic) that, when called by the SCM or CI system, cause OpenShift to start a new build immediately. Option E (ConfigChange trigger) is correct because it starts a build automatically whenever the BuildConfig itself is created or modified, which is useful for producing an initial build on configuration changes. Option A (Route health-check trigger) is not a BuildConfig trigger at all — routes only perform HTTP/TCP health checks for traffic routing and cannot initiate builds. Option C (CronJob schedule trigger) is not a BuildConfig trigger either; scheduled builds in OpenShift are handled by a separate BuildConfig-level cron-like mechanism or by external CronJobs, not by a CronJob schedule trigger on the BuildConfig.

Answer

Route health-check trigger

Answer

CronJob schedule trigger

Question 9

You are troubleshooting a BuildConfig that fails during the source clone phase due to an untrusted custom internal Certificate Authority (CA) used by your corporate Git server. Where must you configure the custom CA certificate so that the OpenShift cluster's build pods trust the Git server during S2I builds?

Accepted Answer

In a ConfigMap referenced by the build.openshift.io/inject-trusted-cabundle annotation or build defaults in the cluster.. OpenShift BuildConfigs run in build pods that need to trust the Git server's custom CA. The build.openshift.io/inject-trusted-cabundle annotation on a ConfigMap causes the cluster to inject the CA bundle into the build pod's trust store. Alternatively, you can configure build defaults in the cluster-wide Build configuration (build.config.openshift.io/cluster) to reference a ConfigMap containing the CA, which is then mounted into all build pods. This ensures S2I builds can clone from the Git server without TLS errors.

Answer

In the global cluster proxy configuration under spec.trustedCA.

Answer

In the Node configuration file on each worker node under /etc/origin/node/.

Answer

In the imagestream spec.trust.ca field.

Question 10

You have a S2I build that fails because the builder image is not accessible by the restricted ServiceAccount. What is the most secure way to resolve this?

Accepted Answer

Grant the 'system:image-puller' role to the ServiceAccount. The 'system:image-puller' role is a ClusterRole that grants permission to pull images from ImageStreams. When a ServiceAccount lacks this role, it cannot access the builder image, causing S2I builds to fail. Granting this role to the specific ServiceAccount follows the principle of least privilege, as it only provides the necessary pull access without exposing the image to all users or changing the build strategy. This is the most secure and OpenShift-native solution.

Answer

Change the build strategy to Docker

Answer

Make the ImageStream public

Answer

Create an ImagePullSecret for the ServiceAccount