EX280 Application Deployment And Lifecycle Practice Test 4 — 15 Questions

Question 1

You want to trigger a new build automatically whenever the base image in an ImageStream changes. What must be enabled in the BuildConfig?

Accepted Answer

ImageChange trigger. The ImageChange trigger in a BuildConfig watches a specified ImageStream tag and starts a new build whenever that tag's image digest changes. This is the mechanism used to rebuild an application automatically when its base image (e.g., a builder image or a parent image) is updated. Configuring an ImageChange trigger with the base ImageStream as the source enables this behavior.

Answer

Continuous Deployment trigger

Answer

WebHook trigger

Answer

ConfigChange trigger

Question 2

When managing application lifecycles and rollouts using standard Kubernetes Deployments in OpenShift 4.14, which TWO parameters are explicitly configurable under the rollingUpdate strategy settings? (Choose two.)

Accepted Answer

maxSurge. In a Kubernetes Deployment's spec.strategy.rollingUpdate, the two explicitly configurable parameters are maxSurge (option A) and maxUnavailable (option E). maxSurge defines how many extra Pods beyond the desired replica count can be created during an update, and maxUnavailable defines how many Pods below the desired count can be unavailable during the rollout; both accept an integer or percentage and are the only fields under rollingUpdate. minReadySeconds (option B) is a valid Deployment field, but it sits at spec.minReadySeconds, not under the rollingUpdate strategy settings. timeoutSeconds (option C) is not a Deployment rollingUpdate parameter (it appears in probes and other APIs), and rollbackWindow (option D) is not a standard Kubernetes Deployment field at all, so neither belongs here.

Answer

minReadySeconds

Answer

timeoutSeconds

Answer

rollbackWindow

Question 3

You are using Kustomize to manage environment-specific configurations. Which file must be present in the base directory to define resources?

Accepted Answer

kustomization.yaml. Every Kustomize directory — base or overlay — must contain a kustomization.yaml file, which declares the resources, patches, and transformations for that layer. In the base directory, this file lists the Kubernetes manifests (Deployments, Services, ConfigMaps) that make up the common configuration. Without it, 'kubectl kustomize' or 'oc apply -k' cannot resolve the directory.

Answer

base.yaml

Answer

overlay.yaml

Answer

resources.yaml

Question 4

When performing a 'rollout undo' on a Deployment, what is the default behavior if no revision is specified?

Accepted Answer

Roll back to the previous revision. The `oc rollout undo` command (and its kubectl equivalent) defaults to reverting a Deployment to the immediately preceding revision when no `--to-revision` flag is supplied. OpenShift tracks each DeploymentConfig/Deployment revision via ReplicaSets, and the undo operation simply scales up the prior ReplicaSet while scaling down the current one. This makes 'previous revision' the implicit target, not revision 1 or the initial state.

Answer

Delete the current deployment

Answer

Return to the state at initial deployment

Answer

Roll back to revision 1

Question 5

Which command is used to start a new build from an existing BuildConfig named 'frontend'?

Accepted Answer

oc start-build frontend. oc start-build frontend is the correct command to trigger a new build from an existing BuildConfig named 'frontend'. It creates a new Build object, which the build controller then executes according to the BuildConfig's strategy (Source, Docker, or Custom).

Answer

oc trigger-build frontend

Answer

oc run-build frontend

Answer

oc build frontend

Question 6

Which command allows you to view the logs of a specific build?

Accepted Answer

oc logs build/[build-name]. The `oc logs` command can target a build object directly by using the `build/[build-name]` syntax, which streams the logs from the build pod that OpenShift creates for that build. This is the canonical way to inspect build output without first looking up the generated pod name. The build name is the value shown in `oc get builds` output.

Answer

oc get build

Answer

oc describe build

Answer

oc logs [pod-name]

Question 7

You have a Helm chart that requires custom values for different environments. Which flag allows you to pass a custom values file?

Accepted Answer

--values. The --values flag (or -f) is used with Helm commands like helm install or helm upgrade to specify a YAML file containing custom values that override the chart's default values.yaml. This is the standard way to provide environment-specific configurations. The flag can be used multiple times, with later files taking precedence.

Answer

--override

Answer

--config

Answer

--set-file

Question 8

What is the primary difference between a Deployment and a DeploymentConfig in OpenShift?

Accepted Answer

DeploymentConfigs are OpenShift-specific. DeploymentConfigs are a legacy OpenShift-specific resource that predates native Kubernetes Deployments. They are not part of upstream Kubernetes and are only available in OpenShift, whereas Deployments are a standard Kubernetes API resource. This is the primary architectural difference: DeploymentConfigs rely on OpenShift's ImageStreams and custom rollout logic, while Deployments use ReplicaSets and the standard Kubernetes deployment controller.

Answer

Deployments support triggers, DeploymentConfigs do not

Answer

Deployments can be scaled, DeploymentConfigs cannot

Answer

DeploymentConfigs do not support rollbacks

Question 9

You need to perform a canary deployment by shifting traffic between two versions of your app. What is the standard way to accomplish this in OpenShift without using a Service Mesh?

Accepted Answer

Use Route weights. In OpenShift, a Route can be configured with multiple backends (services) and each backend can be assigned a weight. By setting different weights, you can split traffic between two versions of your application, enabling a canary deployment. This is the standard method without a Service Mesh because it leverages the built-in HAProxy router's weighted round-robin capabilities. The weights are integers that represent relative proportions of traffic; for example, 80 and 20 would send 80% to one service and 20% to the other.

Answer

Create two separate Routes

Answer

Modify the Deployment strategy

Answer

Use the 'oc scale' command

Question 10

Which tool would you use to package an application including its dependencies and configuration for easy distribution in OpenShift?

Accepted Answer

Helm. Helm is a package manager for Kubernetes/OpenShift that bundles application manifests, dependencies, and configuration into a single chart for easy distribution and versioned installation. It supports templating, values files, and dependency management, making it the standard tool for packaging and distributing applications. The other options are build or configuration tools, not packaging/distribution tools.

Answer

oc build

Answer

Kustomize

Answer

S2I

Question 11

What is the purpose of the 'postCommit' hook in a BuildConfig?

Accepted Answer

To run tests on the image. The 'postCommit' hook in an OpenShift BuildConfig is designed to execute a command inside a temporary container created from the newly built image, immediately after the build completes and the image is committed. This is specifically intended for running tests, such as unit tests or integration tests, to validate the image's functionality before it is pushed or deployed. It does not notify external systems, push images, or restart deployments; those are handled by other mechanisms like webhooks, push secrets, or deployment triggers.

Answer

To notify an external system

Answer

To push the image to an external registry

Answer

To restart the Deployment

Question 12

How do you define a health check that verifies if your application is ready to start receiving traffic?

Accepted Answer

ReadinessProbe. A ReadinessProbe determines whether a container is ready to accept traffic. If the probe fails, the pod is removed from the Service's endpoints, so no traffic is routed to it until the probe succeeds. This directly matches the requirement of verifying readiness to receive traffic.

Answer

StartupProbe

Answer

LivenessProbe

Answer

HealthProbe

Question 13

You need to update an application without downtime. Which deployment strategy is most appropriate?

Accepted Answer

Rolling. Rolling deployment is the most appropriate strategy for updating an application without downtime because it incrementally replaces old pods with new ones, ensuring that a portion of the application remains available throughout the update. This is the default deployment strategy in OpenShift (and Kubernetes), and it maintains service continuity by scaling down the old ReplicaSet while scaling up the new one, with configurable parameters like maxUnavailable and maxSurge to control the pace. Unlike other strategies, rolling updates do not require additional infrastructure or complex traffic routing, making it the standard choice for zero-downtime updates in OpenShift.

Answer

Canary

Answer

Blue-Green

Answer

Recreate

Question 14

How do you view the history of deployments for a DeploymentConfig?

Accepted Answer

oc rollout history. The `oc rollout history` command is specifically designed to display the revision history of a DeploymentConfig, showing each deployment's revision number, cause, and change details. It queries the DeploymentConfig's status and associated ReplicationControllers to present a chronological list of rollouts. This is the standard OpenShift CLI method for auditing deployment changes.

Answer

oc show history

Answer

oc describe dc

Answer

oc get history

Question 15

Which resource in OpenShift acts as an abstraction over a set of images to provide a stable reference?

Accepted Answer

ImageStream. An ImageStream in OpenShift is a named abstraction that points to one or more container images, tracking image updates via tags. It provides a stable reference (e.g., myapp:latest) that can be resolved to a specific image digest at deploy time, decoupling workloads from underlying registry locations. This allows builds and deployments to trigger automatically when new images are pushed to the stream.

Answer

DeploymentConfig

Answer

BuildConfig

Answer

Route