EX280 Application Deployment And Lifecycle Practice Test 3 — 15 Questions

Question 1

An administrator wants to pause rollouts on a DeploymentConfig named backend-api to make multiple configuration changes without triggering intermediate builds or rollouts. Which command pauses the rollout?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

oc rollout pause dc/backend-api. The 'oc rollout pause dc/backend-api' command sets spec.paused=true on the DeploymentConfig, which halts the rollout controller from creating new ReplicationControllers or scaling them during the pause window. This is the documented, first-class CLI verb for pausing rollouts and is the intended administrative action before making multiple template or trigger changes.

Answer

oc patch dc/backend-api --type=json -p='[{"op": "add", "path": "/spec/paused", "value": true}]'

Answer

oc suspend dc/backend-api

Answer

oc stop rollout dc/backend-api

Question 2

An administrator needs to configure a BuildConfig so that whenever a new image is pushed to a dependent ImageStream tag, a new build is automatically triggered. Which trigger type must be added to the BuildConfig?

Accepted Answer

ImageChange. The ImageChange trigger is specifically designed to watch an ImageStreamTag and automatically start a new BuildConfig run whenever the referenced image stream tag is updated (e.g., a new image is pushed). This is the standard mechanism for chaining builds or rebuilding an application when its base/builder image changes. It is configured under spec.triggers with type: ImageChange and an imageChange.imageStreamTag reference.

Answer

Webhook

Answer

Periodic

Answer

ConfigChange

Question 3

An administrator needs to completely remove a Helm release named my-redis from the cluster, including its history. Which Helm command should be executed?

Accepted Answer

helm uninstall my-redis. The correct command to completely remove a Helm release and its history is helm uninstall my-redis. In Helm 3, uninstall replaces the delete command and removes the release and its history by default.

Answer

helm remove my-redis

Answer

helm delete my-redis --purge

Answer

helm drop my-redis

Question 4

A developer is using Kustomize to manage environment overlays (dev and prod) for an OpenShift application. Where should the common base resources be referenced in the prod/kustomization.yaml file?

Accepted Answer

Under the resources: key. In modern Kustomize (v3+ and the version bundled with OpenShift's `oc kustomize`), overlays reference their base directory using the `resources:` field in kustomization.yaml. The prod overlay lists `../../base` (or the base path) under `resources:`, which causes Kustomize to compose the base manifests with the prod-specific patches and transformations. This is the canonical way to build a layered configuration.

Answer

Under the includes: key

Answer

Under the bases: key

Answer

Under the overlays: key

Question 5

An administrator is configuring a DeploymentConfig in OpenShift and wants to set up automated triggers for new rollouts. Which TWO trigger types are natively supported in a DeploymentConfig spec? (Choose two.)

Accepted Answer

ConfigChange. DeploymentConfigs support ConfigChange (triggering when the DeploymentConfig template changes) and ImageChange (triggering when a referenced ImageStream tag updates).

Answer

PeriodicTrigger

Answer

WebhookTrigger

Answer

GitTrigger

Question 6

An administrator needs to create a new OpenShift build using a BuildConfig. Which TWO build strategies are natively supported out-of-the-box by OpenShift? (Choose two.)

Accepted Answer

Source (S2I). Option A (Source, i.e., Source-to-Image/S2I) is correct because OpenShift natively supports the Source build strategy, which injects application source into a builder image and produces a runnable image without a Dockerfile. Option E (Docker) is correct because the Docker build strategy is a built-in OpenShift strategy that builds an image from a Dockerfile using the container runtime. These are two of the standard strategies available in a BuildConfig (alongside Custom and Pipeline). Option B (Ansible) is not a native BuildConfig strategy; Ansible automation is typically run via Ansible Automation Platform or as a custom build, not as a built-in strategy. Option C (Knative) is a serverless/eventing platform, not a BuildConfig build strategy. Option D (Helm) is a package manager for Kubernetes manifests, not an OpenShift build strategy.

Answer

Ansible

Answer

Knative

Answer

Helm

Question 7

Which THREE methods can be used to pass parameters or configuration values into a Helm chart installation in OpenShift? (Choose three.)

Accepted Answer

Relying on the default values defined in the chart's values.yaml file. Option A is correct because Helm automatically loads the chart's built-in values.yaml file as the base set of default configuration values whenever a chart is installed, so relying on those defaults is a legitimate way configuration is supplied to the release. Option C is correct because the --set flag lets you override individual values as key-value pairs directly on the command line (e.g., helm install myrelease mychart --set image.tag=latest), which is a standard method for injecting parameters at install time. Option D is correct because the --values (or -f) flag lets you supply a custom YAML file whose keys are merged over the chart defaults, enabling structured, reusable configuration input. Option B does not belong because oc patch modifies live Kubernetes objects after deployment and has no role in Helm's templating or value-passing mechanism. Option E does not belong because the cluster-wide OAuth configuration map governs OpenShift authentication settings, not Helm chart parameter injection.

Answer

Directly modifying the deployed Kubernetes Pod annotations via oc patch

Answer

Injecting values through the cluster-wide OAuth configuration map

Question 8

When managing ImageStreams in OpenShift, which TWO tasks can an administrator perform using oc commands? (Choose two.)

Accepted Answer

Creating an alias or tag pointing one ImageStream tag to another using oc tag. Option A is correct because the `oc tag` command creates or updates tags and aliases within an ImageStream, allowing one tag to point to another tag or image (e.g., `oc tag myis:latest myis:stable`). Option D is correct because `oc import-image` imports image metadata from an external container registry into an ImageStream, creating or updating the ImageStream tags with the remote image's manifest and layers. Option B is incorrect because there is no `oc test-image` subcommand in OpenShift; unit testing of images is not an `oc` function. Option C is incorrect because `oc tag` only manages image tag references and does not compile source code into binaries. Option E is incorrect because `oc image` does not modify kernel parameters on worker nodes; kernel tuning is done via MachineConfig or node-level tooling, not image commands.

Answer

Running unit tests against container image layers using oc test-image

Answer

Compiling raw source code into an executable binary using oc tag

Answer

Directly modifying kernel parameters on worker nodes via oc image

Question 9

Which THREE actions can be performed using the oc rollout subcommand in OpenShift? (Choose three.)

Accepted Answer

Pausing a rollout to make multiple configuration updates. Option A is correct because `oc rollout pause` suspends a deployment rollout so you can apply multiple configuration changes before resuming with `oc rollout resume`, preventing intermediate rollouts. Option C is correct because `oc rollout history` displays the revision history of a deployment or deployment config, including revision numbers and change causes. Option D is correct because `oc rollout status` reports the current status of an ongoing rollout, waiting until it completes or fails. Option B is not part of `oc rollout`; direct source builds from a local directory are performed with `oc start-build --from-dir` or `oc new-build`. Option E is not part of `oc rollout`; scaling replicas is done with `oc scale` (or `oc scale dc/deployment`).

Answer

Triggering a direct source build from a local directory

Answer

Scaling the number of replicas up or down

Question 10

Which TWO statements are true regarding Kustomize usage within OpenShift? (Choose two.)

Accepted Answer

Kustomize is natively integrated into the oc command line tool using the -k flag.. Option B is correct because OpenShift's oc CLI natively integrates Kustomize, allowing users to build and apply a kustomization directory directly with commands like 'oc apply -k ' or 'oc kustomize ', without needing a separate kustomize binary. Option D is correct because Kustomize's core purpose is declarative customization of base YAML manifests through kustomization.yaml features such as strategic-merge and JSON 6902 patches, plus namePrefix and nameSuffix transformers, which is exactly how OpenShift users overlay environment-specific changes. Option A is wrong because Kustomize is a client-side manifest rendering tool and never replaces or bypasses the Kubernetes API server; resources are still created via the API server. Option C is wrong because Kustomize works with plain directories of YAML and requires no centralized chart repository like ChartMuseum (that concept belongs to Helm). Option E is wrong because Kustomize deliberately avoids Go templating and conditional logic, using declarative patches and overlays instead.

Answer

Kustomize replaces the Kubernetes API server entirely during resource creation.

Answer

Kustomize requires a centralized chart repository server similar to ChartMuseum.

Answer

Kustomize requires writing complex Go templates with conditional logic statements.

Question 11

You need to deploy a Node.js application from a Git repository using Source-to-Image (S2I) on OpenShift 4.14, and you want to ensure the build triggers automatically whenever a new image is pushed to the dependent base ImageStream. Which BuildConfig strategy and configuration element achieves this?

Accepted Answer

Configure a Source build with an ImageChange trigger on the input ImageStreamTag.. The Source build strategy is the S2I builder, which is designed to take application source code from a Git repository and combine it with a builder image to produce a runnable image. To automatically trigger a new build when the dependent base ImageStream is updated (e.g., a new version of the Node.js builder image is pushed), you must configure an ImageChange trigger that references the input ImageStreamTag used by the build. This trigger watches the specified ImageStreamTag and starts a build whenever the tag's image ID changes, ensuring the application is rebuilt with the latest base image.

Answer

Configure a Docker build with a ConfigChange trigger on the DeploymentConfig.

Answer

Configure a Pipeline build referencing a Tekton pipeline with manual execution parameters.

Answer

Configure a Custom build with a GitHub webhook trigger referencing the source repository.

Question 12

An administrator needs to roll back a Deployment in OpenShift to a specific previous revision because the latest update introduced a critical database connection bug. Which command identifies the available revisions and their associated change causes before executing the rollback?

Accepted Answer

oc rollout history deployment/. The `oc rollout history deployment/` command is specifically designed to display the revision history of a Deployment, including the revision number and the change cause (the reason for each rollout). This allows the administrator to identify which revision to roll back to before executing `oc rollout undo deployment/ --to-revision=`. It directly addresses the need to see available revisions and their associated change causes.

Answer

oc get replicasets --selector=app=my-app

Answer

oc get deployment/<deployment-name> -o yaml

Answer

oc describe deploymentconfig <deployment-config-name>

Question 13

An ImageStream named 'frontend' in a project contains multiple tags, including 'latest' and 'v1.0'. You want to update an existing Deployment to specifically use the 'v1.0' tag of this ImageStream. Where must this reference be updated in the Deployment specification?

Accepted Answer

In the spec.template.spec.containers[].image field pointing to image-registry.openshift-image-registry.svc:5000/namespace/frontend:v1.0.. In OpenShift, an ImageStream tag is consumed by referencing the internal registry image path in the container's image field. The correct form is image-registry.openshift-image-registry.svc:5000//:, which the kubelet resolves through the internal registry and the ImageStream tag. Updating spec.template.spec.containers[].image to this fully qualified reference with the v1.0 tag ensures the Deployment pulls that specific tag.

Answer

In the spec.imageStreamRef field.

Answer

In the metadata.annotations['openshift.io/image.in-cluster'] field.

Answer

In the spec.strategy.rollingUpdate.image field.

Question 14

Which THREE of the following are valid build strategies supported by OpenShift BuildConfigs? (Choose three.)

Accepted Answer

Custom. Option B (Custom) is correct because OpenShift BuildConfigs support the Custom build strategy, which lets you define your own builder image that runs a user-supplied build logic and produces the resulting image. Option C (Source) is correct because the Source build strategy (Source-to-Image, S2I) uses a builder image with assemble/run scripts to compile source code into a runnable image. Option E (Docker) is correct because the Docker build strategy builds an image by executing a Dockerfile with the docker build process inside the cluster. Option A (Jenkinsfile) is not a BuildConfig strategy; Jenkins pipelines are handled by OpenShift Pipelines/Jenkins, not by BuildConfig strategy types. Option D (HelmBuild) is not a supported OpenShift BuildConfig strategy; Helm is a package manager for Kubernetes manifests and is not a build strategy.

Answer

Jenkinsfile

Answer

HelmBuild

Question 15

You need to ensure that your application deployment always maintains at least 80% of its desired pod count during a rolling update. Which strategy parameter should you configure?

Accepted Answer

maxUnavailable: 20%. In a rolling update strategy, maxUnavailable defines the maximum number of Pods that can be unavailable during the update. Setting maxUnavailable: 20% ensures that at least 80% of the desired Pod count remains available at all times, satisfying the requirement. This parameter directly controls the availability floor during the rollout.

Answer

minReadySeconds: 20

Answer

maxSurge: 20%

Answer

rollingUpdatePeriod: 20%