Courseiva

CCNA Application Deployment And Lifecycle Questions

62 questions · Application Deployment And Lifecycle · All types, answers revealed

Practice these questionsDomain overviewAll questions
1
MCQmedium

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

A.Deployments support triggers, DeploymentConfigs do not
B.Deployments can be scaled, DeploymentConfigs cannot
C.DeploymentConfigs are OpenShift-specific
D.DeploymentConfigs do not support rollbacks
AnswerC

DeploymentConfigs are an OpenShift-specific resource, absent from upstream Kubernetes, whereas Deployments are the native Kubernetes workload API. This distinction satisfies the stem's request for the primary difference: DeploymentConfigs rely on OpenShift's ImageStream triggers and custom rollout logic, while Deployments use standard Kubernetes controllers.

Why this answer

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.

Exam trap

EX280 often tests the misconception that DeploymentConfigs are simply a newer or enhanced version of Deployments, when in fact they are legacy OpenShift-specific resources that lack native Kubernetes compatibility.

How to eliminate wrong answers

Option A is wrong because Deployments do not support OpenShift-style triggers (ImageChange, ConfigChange); triggers are a feature of DeploymentConfigs. Option B is wrong because both Deployments and DeploymentConfigs can be scaled; scaling is a fundamental capability of both resource types. Option D is wrong because DeploymentConfigs do support rollbacks via `oc rollout undo`, just as Deployments do with `kubectl rollout undo`.

Practice this question →
2
MCQmedium

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

A.Canary
B.Blue-Green
C.Recreate
D.Rolling
AnswerD

Rolling updates replace instances incrementally, so a subset of pods remains available to serve traffic throughout the rollout. This satisfies the no-downtime constraint by keeping the application reachable while new versions are progressively introduced and old ones retired, provided readiness probes and sufficient replicas are configured.

Why this answer

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.

Exam trap

EX280 often tests the distinction between deployment strategies, and candidates frequently confuse rolling updates with blue-green or canary, assuming those are required for zero-downtime, when in fact rolling is the default and simplest method in OpenShift.

How to eliminate wrong answers

Option A is wrong because canary deployments, while they minimize risk by routing a small percentage of traffic to the new version, require advanced traffic management (e.g., service mesh or ingress controllers) and are not the default or simplest method for zero-downtime updates in OpenShift. Option B is wrong because blue-green deployments require double the resources (two full environments) and a mechanism to switch traffic instantly, which is more complex and costly than necessary for a typical update. Option C is wrong because recreate strategy stops all old pods before starting new ones, causing guaranteed downtime, which directly contradicts the requirement.

Practice this question →
3
MCQhard

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?

A.oc get replicasets --selector=app=my-app
B.oc get deployment/<deployment-name> -o yaml
C.oc describe deploymentconfig <deployment-config-name>
D.oc rollout history deployment/<deployment-name>
AnswerD

'oc rollout history' displays all recorded revisions for a deployment along with their change causes.

Why this answer

The `oc rollout history deployment/<deployment-name>` 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/<deployment-name> --to-revision=<n>`. It directly addresses the need to see available revisions and their associated change causes.

Exam trap

EX280 often tests the distinction between Deployments and DeploymentConfigs, and candidates may mistakenly choose `oc describe deploymentconfig` or `oc get replicasets` thinking they show revision history, but only `oc rollout history` provides the ordered revisions with change causes for Deployments.

How to eliminate wrong answers

Option A is wrong because `oc get replicasets --selector=app=my-app` lists ReplicaSets but does not show revision numbers or change causes in a directly usable format for rollback; while ReplicaSets are created per revision, the output lacks the ordered history and change-cause annotations that `oc rollout history` provides. Option B is wrong because `oc get deployment/<deployment-name> -o yaml` dumps the full Deployment configuration, which includes only the current revision and metadata, not a list of previous revisions or their change causes. Option C is wrong because `oc describe deploymentconfig <deployment-config-name>` is for DeploymentConfigs (the older OpenShift-specific resource), not Deployments (the standard Kubernetes resource); the question explicitly refers to a Deployment, and using the wrong resource type would fail or show irrelevant information.

Practice this question →
4
MCQhard

An administrator needs to perform a canary deployment strategy using standard OpenShift Deployment resources (not DeploymentConfigs). What is the standard Kubernetes/OpenShift native mechanism to route a small percentage of traffic to the canary deployment?

A.Setting the traffic-split annotation on the Deployment resource
B.Using an OpenShift Route with weighted backend services pointing to stable and canary Services
C.Configuring weight parameters directly in the Deployment spec rollingUpdate strategy
D.Enabling canary mode in the ImageStream tag metadata
AnswerB

An OpenShift Route supports `alternateBackends` with integer weights, splitting traffic between stable and canary Services without extra tooling. This satisfies the stem's native-mechanism constraint for standard Deployments, since both Services select pods by label and the Route itself performs the percentage split.

Why this answer

OpenShift Routes support weighted backends via the 'alternateBackends' field with a 'weight' value, allowing a single Route to split traffic between a stable Service and a canary Service. This is the native mechanism for canary traffic splitting without a service mesh, and it works with standard Deployments behind each Service.

Exam trap

EX280 often tests whether candidates assume Deployments themselves can split traffic, missing that OpenShift Routes (or a service mesh) are the actual traffic-splitting layer.

How to eliminate wrong answers

Option A is wrong because there is no 'traffic-split' annotation on Deployment resources — Deployments have no concept of traffic weighting. Option C is wrong because the rollingUpdate strategy controls pod replacement (maxSurge/maxUnavailable), not traffic percentages, and it cannot route a fraction of requests to a separate canary. Option D is wrong because ImageStream tag metadata (e.g., 'importPolicy', 'referencePolicy') governs image resolution and triggers, not traffic routing.

Practice this question →
5
MCQeasy

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?

A.In the spec.imageStreamRef field.
B.In the metadata.annotations['openshift.io/image.in-cluster'] field.
C.In the spec.template.spec.containers[].image field pointing to image-registry.openshift-image-registry.svc:5000/namespace/frontend:v1.0.
D.In the spec.strategy.rollingUpdate.image field.
AnswerC

The container image field is where OpenShift resolves an ImageStream tag to a pullable reference, so pinning spec.template.spec.containers[].image to the internal registry path with the v1.0 tag satisfies the requirement to use that specific tag.

Why this answer

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/<namespace>/<imagestream>:<tag>, 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.

Exam trap

EX280 often tests whether candidates know the exact internal registry path format and that ImageStream tags are consumed through the container image field, not a fictitious imageStreamRef field.

How to eliminate wrong answers

Option A is wrong because spec.imageStreamRef is not a valid field in a Pod/Deployment container spec; ImageStream references are resolved via the image field, not a dedicated ref field. Option B is wrong because metadata.annotations['openshift.io/image.in-cluster'] is not a real annotation used to select ImageStream tags. Option D is wrong because spec.strategy.rollingUpdate.image does not exist; the rollingUpdate strategy only accepts maxSurge and maxUnavailable.

Practice this question →
6
MCQmedium

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?

A.maxUnavailable: 20%
B.minReadySeconds: 20
C.maxSurge: 20%
D.rollingUpdatePeriod: 20%
AnswerA

Setting `maxUnavailable: 20%` in the rolling update strategy guarantees that no more than 20% of desired pods are unavailable at any moment, leaving at least 80% running. This directly satisfies the stem's requirement to maintain a minimum of 80% of the desired pod count throughout the deployment.

Why this answer

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.

Exam trap

EX280 often tests the difference between maxUnavailable (availability floor) and maxSurge (extra capacity), so candidates must not confuse the two when the question asks for maintaining a minimum percentage of Pods.

How to eliminate wrong answers

Option B is wrong because minReadySeconds specifies how long a new Pod must be ready before it is considered available; it does not guarantee a minimum percentage of available Pods. Option C is wrong because maxSurge controls how many extra Pods can be created above the desired count, not how many must remain available. Option D is wrong because rollingUpdatePeriod is not a valid Kubernetes Deployment strategy parameter.

Practice this question →
7
MCQeasy

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

A.helm remove my-redis
B.helm delete my-redis --purge
C.helm uninstall my-redis
D.helm drop my-redis
AnswerC

`helm uninstall my-redis` removes the release and, by default, deletes its release history from the cluster, satisfying the requirement to erase all records. Unlike `helm delete --keep-history`, which retains revision data for rollback, plain uninstall purges the release entirely, leaving no residual state.

Why this answer

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.

Exam trap

EX280 often tests Helm 3 command changes, so candidates must remember that 'helm uninstall' is the correct command, not 'helm delete' with '--purge' which is Helm 2 syntax.

How to eliminate wrong answers

Option A is wrong because helm remove is not a valid command; the correct verb is uninstall. Option B is wrong because helm delete my-redis --purge is Helm 2 syntax; in Helm 3, --purge is deprecated and delete is aliased to uninstall, but the standard command is uninstall. Option D is wrong because helm drop is not a valid command.

Practice this question →
8
MCQeasy

A developer has deployed a Helm chart in OpenShift and needs to list all currently installed Helm releases in the current namespace. Which command should be used?

A.helm get releases
B.helm status
C.helm search installed
D.helm list
AnswerD

`helm list` queries the Helm release storage backend (Kubernetes Secrets of type `helm.sh/release.v1` by default) and returns every release recorded in the active namespace, satisfying the requirement to enumerate installed releases. Adding `--all-namespaces` would broaden scope, but the stem restricts output to the current namespace.

Why this answer

The helm list command lists all Helm releases in the current namespace (or all namespaces with -A). It shows release name, namespace, revision, status, chart, and app version. This is the standard command to view installed releases.

Exam trap

EX280 often tests the confusion between helm list (list releases) and helm status (status of one release) or helm get (retrieve details of one release).

How to eliminate wrong answers

Option A is wrong because helm get releases is not a valid Helm command; helm get is used to get information about a specific release (e.g., helm get values). Option B is wrong because helm status shows the status of a single release, not a list of all releases. Option C is wrong because helm search installed is not a valid command; helm search is used to search for charts in repositories or Hub.

Practice this question →
9
MCQhard

You notice that your builds are failing due to a lack of memory. Where can you set resource limits for the build process?

A.In the BuildConfig resources field
B.In the LimitRange
C.In the project Quota
D.In the Deployment object
AnswerA

Setting `resources` in the BuildConfig lets you declare CPU and memory requests and limits for the build pod, so the scheduler reserves sufficient memory and the kubelet enforces the cap. This directly addresses the failing builds by guaranteeing the build container receives the memory it needs.

Why this answer

Build resource limits are configured in the `resources` field of the BuildConfig's `spec`, which is passed to the build pod that executes the build. This lets you cap CPU and memory for the build container so that memory-hungry builds (for example, large Maven or Node builds) don't get OOM-killed. The values follow standard Kubernetes resource requests/limits syntax.

Exam trap

EX280 often tests the misconception that namespace-level controls (LimitRange or ResourceQuota) are the right place to fix a specific build's memory problem, when the per-BuildConfig `resources` field is the direct answer.

How to eliminate wrong answers

Option B is wrong because a LimitRange sets default and min/max constraints for pods in a namespace but does not target the build process specifically and won't override a BuildConfig that needs higher limits. Option C is wrong because a project ResourceQuota caps aggregate namespace consumption and can cause builds to fail if exhausted, but it is not where you set per-build memory limits. Option D is wrong because the Deployment object governs the runtime application pods, not the build pods that compile/assemble the image.

Practice this question →
10
MCQhard

A developer has created a Kustomization file that applies a namespace prefix and some patches to base Kubernetes manifests. How can the developer apply these manifests to an OpenShift cluster using standard oc tooling without installing standalone Kustomize?

A.oc create -f kustomization.yaml
B.oc run -k ./directory
C.oc apply -k ./directory
D.oc kustomize apply ./directory
AnswerC

The -k flag tells oc to build and apply resources from a Kustomization directory, invoking the Kustomize functionality built into oc. This applies the namespace prefix and patches without installing standalone Kustomize, satisfying the standard-tooling constraint.

Why this answer

The `oc apply -k ./directory` command uses the integrated Kustomize support in the oc CLI to build and apply the Kustomization. This is the standard way to apply Kustomize manifests in OpenShift without installing standalone Kustomize.

Exam trap

The trap is thinking you need to install Kustomize separately or use a different command like `oc kustomize apply`; candidates may not know that `oc apply -k` is the correct integrated approach.

How to eliminate wrong answers

Option A is wrong because `oc create -f kustomization.yaml` would try to create a resource from the Kustomization file itself, which is not a valid Kubernetes resource. Option B is wrong because `oc run -k` is not a valid command; `oc run` is for creating a single pod, and -k is not a flag for it. Option D is wrong because `oc kustomize apply` is not a valid subcommand; `oc kustomize` builds the manifests but does not apply them.

Practice this question →
11
Multi-Selecthard

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

Select 3 answers
A.Relying on the default values defined in the chart's values.yaml file
B.Directly modifying the deployed Kubernetes Pod annotations via oc patch
C.Passing individual key-value pairs using the --set flag on the CLI
D.Supplying a custom YAML configuration file using the --values flag
E.Injecting values through the cluster-wide OAuth configuration map
AnswersA, C, D

Values from values.yaml supply defaults when no override is given, so installation proceeds with chart-defined configuration. This satisfies the requirement of passing configuration into the release without external flags, though overrides via --set or custom values files take precedence when supplied.

Why this answer

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.

Exam trap

EX280 often tests the distinction between pre-installation value injection and post-deployment modifications; candidates may pick `oc patch` as a way to pass values, but it does not affect Helm's templating.

Practice this question →
12
MCQeasy

An administrator needs to view the rollout history of a DeploymentConfig named web-frontend. Which command accomplishes this?

A.oc rollout history dc/web-frontend
B.oc describe dc/web-frontend
C.oc get revisions dc/web-frontend
D.oc log rollout dc/web-frontend
AnswerA

The 'oc rollout history' command with the dc/web-frontend resource argument queries the deployment configuration's revision history, listing each rollout with its revision number and change cause, directly satisfying the administrator's need to view rollout history.

Why this answer

The `oc rollout history` command is specifically designed to display the revision history of a DeploymentConfig (or Deployment). When used with the resource type and name (`dc/web-frontend`), it lists all revisions, their change causes, and the current active revision. This directly fulfills the requirement to view rollout history.

Exam trap

EX280 often tests the distinction between commands that show current state versus historical state; candidates might confuse `oc describe` (which shows current details) with `oc rollout history` (which shows past revisions).

How to eliminate wrong answers

Option B is wrong because `oc describe dc/web-frontend` provides detailed status and configuration information about the DeploymentConfig, but does not list the historical revisions or their change causes. Option C is wrong because `oc get revisions dc/web-frontend` is not a valid command; `revisions` is not a standalone resource type in OpenShift, and `oc get` cannot retrieve revision history in this manner. Option D is wrong because `oc log rollout dc/web-frontend` is not a valid command; `oc log` is used to retrieve logs from pods or builds, not to view rollout history.

Practice this question →
13
MCQeasy

An administrator needs to deploy a containerized web application using a Git repository as the source without writing a Dockerfile. Which OpenShift build strategy should be used?

A.Source-to-Image (S2I) strategy
B.Docker strategy
C.Custom strategy
D.Pipeline strategy
AnswerA

Source-to-Image builds inject application source directly into a builder image, which detects the runtime and assembles the final image without a Dockerfile. This satisfies the stem's constraint of using a Git repository as source while avoiding manual Dockerfile authoring, unlike Docker or custom strategies.

Why this answer

The Source-to-Image (S2I) strategy builds application images by combining builder images with source code, without requiring a Dockerfile. OpenShift injects the source into the builder image, runs assemble/run scripts, and produces a runnable image. This is the standard approach for deploying from Git when no Dockerfile exists.

Exam trap

EX280 often tests the distinction between build strategies, and candidates confuse S2I (no Dockerfile needed) with the Docker strategy (Dockerfile required).

How to eliminate wrong answers

Option B is wrong because the Docker strategy requires a Dockerfile in the repository to define the build. Option C is wrong because the Custom strategy requires the user to supply their own builder image with custom assemble/run logic, which is more complex than needed. Option D is wrong because Pipeline strategy uses Jenkins pipelines for CI/CD orchestration, not for building from source without a Dockerfile.

Practice this question →
14
Multi-Selectmedium

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

Select 2 answers
A.maxSurge
B.minReadySeconds
C.timeoutSeconds
D.rollbackWindow
E.maxUnavailable
AnswersA, E

maxSurge specifies how many extra Pods beyond the desired replica count may be created during a rolling update. It is one of the two parameters configurable under the rollingUpdate strategy, controlling rollout capacity alongside maxUnavailable.

Why this answer

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.

Exam trap

EX280 often tests the distinction between parameters that belong to the rollingUpdate strategy (maxSurge, maxUnavailable) and those that are separate Deployment fields (minReadySeconds) or unrelated (timeoutSeconds, rollbackWindow).

Practice this question →
15
MCQmedium

A DeploymentConfig in OpenShift has a Rolling strategy defined. Which parameter in the strategy configuration controls the maximum number of pods that can be created above the desired replica count during the update?

A.interval
B.maxSurge
C.updatePeriodSeconds
D.maxUnavailable
AnswerB

maxSurge defines how many pods may exceed the desired replica count during a rolling update, controlling extra capacity created above the target. maxUnavailable instead governs how many pods may be simultaneously unavailable, so maxSurge is the parameter requested.

Why this answer

In OpenShift's DeploymentConfig Rolling strategy, maxSurge specifies the maximum number of pods that can be created beyond the desired replica count during an update. This allows the deployment to temporarily exceed the desired number of replicas to ensure zero downtime. For example, if replicas=3 and maxSurge=1, the deployment can have up to 4 pods at once.

This parameter is defined in the strategy's rollingParams section.

Exam trap

EX280 often tests the distinction between maxSurge and maxUnavailable in rolling updates, where candidates might confuse which parameter controls extra pods versus unavailable pods.

How to eliminate wrong answers

Option A is wrong because interval is not a valid parameter in the Rolling strategy; it is not used to control pod creation. Option C is wrong because updatePeriodSeconds specifies the time to wait between individual pod updates, not the number of extra pods. Option D is wrong because maxUnavailable controls how many pods can be unavailable during the update, which is the opposite of maxSurge.

Practice this question →
16
MCQhard

An administrator needs to deploy a Helm chart into an OpenShift cluster while overriding specific chart values using a local YAML file. Which Helm CLI command should be executed?

A.helm push my-chart --override overrides.yaml
B.helm install my-release my-chart --values overrides.yaml
C.helm deploy my-release my-chart --values overrides.yaml
D.helm apply -f overrides.yaml my-chart
AnswerB

The --values flag supplies a local YAML file whose keys override the chart's default values during installation, which is exactly the stated requirement. helm install my-release my-chart --values overrides.yaml therefore deploys the chart with those overrides applied.

Why this answer

The Helm CLI command to install a chart with value overrides from a file is 'helm install <release-name> <chart> --values <file>'. The '--values' (or '-f') flag loads a YAML file whose keys override the chart's default values.yaml, and 'helm install' performs the initial deployment into the cluster.

Exam trap

EX280 often tests whether candidates confuse 'helm install' with kubectl-style verbs like 'apply' or 'deploy', or misremember the flag as '--override' instead of '--values'/'-f'.

How to eliminate wrong answers

Option A is wrong because 'helm push' uploads a chart to an OCI registry and does not accept '--override' or install charts. Option C is wrong because 'helm deploy' is not a Helm subcommand; the correct verb is 'install' (or 'upgrade' for existing releases). Option D is wrong because 'helm apply -f' is not a Helm command — that syntax resembles kubectl apply, and Helm does not use 'apply' for chart installation.

Practice this question →
17
MCQmedium

An OpenShift administrator needs to trigger a rollback of a Deployment to its previous working revision after a failed update. Which oc command should be used?

A.oc update deployment/my-app --revision=previous
B.oc rollout undo deployment/my-app
C.oc revert deployment/my-app
D.oc rollback deployment/my-app
AnswerB

oc rollout undo reverts the Deployment to its previous revision, restoring the last working state after the failed update. It directly satisfies the rollback requirement by targeting the Deployment's revision history rather than editing or recreating the resource.

Why this answer

The correct command to rollback a Deployment to its previous revision is oc rollout undo deployment/my-app. This command reverts the Deployment to the last successful revision.

Exam trap

EX280 often tests the correct syntax for rollback operations, so candidates must remember that 'oc rollout undo' is the command, not 'oc rollback' or 'oc revert'.

How to eliminate wrong answers

Option A is wrong because oc update deployment/my-app --revision=previous is not a valid command; oc update is used for updating resources but not for rollbacks. Option C is wrong because oc revert deployment/my-app is not a valid command; there is no revert subcommand. Option D is wrong because oc rollback deployment/my-app is not a valid command; the correct subcommand is rollout undo.

Practice this question →
18
MCQmedium

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?

A.oc patch dc/backend-api --type=json -p='[{"op": "add", "path": "/spec/paused", "value": true}]'
B.oc suspend dc/backend-api
C.oc stop rollout dc/backend-api
D.oc rollout pause dc/backend-api
AnswerD

The oc rollout pause command with the dc/backend-api resource halts the DeploymentConfig's rollout process, letting the administrator apply multiple configuration changes without triggering intermediate builds or rollouts. Resuming later applies changes in a single coordinated rollout.

Why this answer

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.

Exam trap

EX280 often tests whether candidates invent non-existent oc subcommands like 'suspend' or 'stop rollout' instead of recognizing the correct 'oc rollout pause' verb.

How to eliminate wrong answers

Option A is wrong because while patching spec.paused via JSON patch technically achieves the same state, it is not the standard command the question asks for and is error-prone (the path may already exist, requiring 'replace' instead of 'add'). Option B is wrong because 'oc suspend' is not a valid oc subcommand for DeploymentConfigs — suspend is a CronJob concept. Option C is wrong because 'oc stop rollout' does not exist; the correct verb is 'pause' (and its counterpart 'resume').

Practice this question →
19
MCQmedium

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?

A.Configure a Docker build with a ConfigChange trigger on the DeploymentConfig.
B.Configure a Source build with an ImageChange trigger on the input ImageStreamTag.
C.Configure a Pipeline build referencing a Tekton pipeline with manual execution parameters.
D.Configure a Custom build with a GitHub webhook trigger referencing the source repository.
AnswerB

An ImageChange trigger on the input ImageStreamTag causes OpenShift to start a new Source build automatically whenever the referenced base image is updated, satisfying the automatic rebuild requirement. The S2I builder image is the input, so the trigger must watch that ImageStreamTag rather than the output.

Why this answer

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.

Exam trap

EX280 often tests the difference between ImageChange triggers (for base image updates) and webhook triggers (for source code changes), and candidates may mistakenly select a webhook or ConfigChange trigger when the requirement is automatic rebuild on base image update.

How to eliminate wrong answers

Option A is wrong because a Docker build strategy does not use S2I and a ConfigChange trigger on a DeploymentConfig triggers deployment when the BuildConfig configuration changes, not when a base image is updated. Option C is wrong because a Pipeline build with Tekton does not inherently provide automatic image change triggers for base ImageStreams; it requires manual execution or separate triggers. Option D is wrong because a Custom build strategy allows arbitrary builder images but does not automatically trigger on base image changes; a GitHub webhook triggers on source code pushes, not on base image updates.

Practice this question →
20
MCQmedium

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

A.oc rollout history
B.oc show history
C.oc describe dc
D.oc get history
AnswerA

The oc rollout history command queries a DeploymentConfig's recorded revisions, listing each deployment with its revision number and change cause. This directly satisfies the requirement to view the deployment history, unlike oc status or oc describe, which show current state rather than revision timeline.

Why this answer

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.

Exam trap

EX280 often tests the distinction between commands that show current state (like `oc describe`) and those that show historical revisions (like `oc rollout history`), so candidates must remember that only `oc rollout history` provides the full deployment revision list.

How to eliminate wrong answers

Option B is wrong because `oc show history` is not a valid oc command; there is no 'show' subcommand in the OpenShift CLI. Option C is wrong because `oc describe dc` provides detailed information about the current state of a DeploymentConfig, including its latest deployment, but does not list the full revision history. Option D is wrong because `oc get history` is not a valid command; 'history' is not a resource type that can be retrieved with `oc get`.

Practice this question →
21
MCQeasy

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

A.DeploymentConfig
B.BuildConfig
C.Route
D.ImageStream
AnswerD

An ImageStream abstracts image repositories by tracking tags and automatically updating when new images are pushed. It provides the stable reference the stem requires, unlike a direct image pull spec, which pins a specific digest or tag.

Why this answer

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.

Exam trap

EX280 often tests the distinction between resources that manage builds, deployments, and networking versus those that abstract images, so candidates may confuse ImageStream with BuildConfig or DeploymentConfig.

How to eliminate wrong answers

Option A is wrong because a DeploymentConfig defines how to deploy an application (replication, triggers, strategy) and does not abstract image sets. Option B is wrong because a BuildConfig defines how to build a container image from source, not a stable reference to images. Option C is wrong because a Route exposes a service externally via a hostname, providing network access rather than image abstraction.

Practice this question →
22
MCQmedium

You want to prevent a specific pod from being scheduled on nodes that are already running other pods of the same application. What should you configure?

A.Pod anti-affinity
B.Tolerations
C.Node selector
D.Resource quotas
AnswerA

Pod anti-affinity uses label selectors with topologyKey to repel pods from nodes already hosting matching pods, directly preventing co-location of the same application's replicas. This satisfies the constraint of keeping identical pods apart across the cluster.

Why this answer

Pod anti-affinity is the correct mechanism because it lets you express a scheduling rule that repels a pod from nodes already hosting pods with specified labels. By using topologyKey (e.g., kubernetes.io/hostname) and labelSelector matching the application, you ensure no two pods of the same app land on the same node. This is the native Kubernetes scheduling constraint designed exactly for spreading workloads apart.

Exam trap

EX280 often tests the confusion between node affinity/anti-affinity (pod-centric scheduling rules) and taints/tolerations (node-centric repulsion), so candidates pick tolerations when the question asks to keep same-app pods apart.

How to eliminate wrong answers

Option B is wrong because tolerations only allow a pod to be scheduled onto nodes with matching taints; they do not repel pods from nodes running other pods. Option C is wrong because a node selector only attracts a pod to nodes with specific labels and cannot express 'avoid nodes already running app X'. Option D is wrong because resource quotas limit aggregate CPU/memory/object counts in a namespace and have no influence on per-node scheduling placement.

Practice this question →
23
Multi-Selecthard

Which THREE items are contained within a Helm Chart structure?

Select 3 answers
A.Dockerfile
B.values.yaml
C.Chart.yaml
D.templates/ directory
E.ImageStream
AnswersB, C, D

values.yaml supplies the default configuration values that templates reference, letting users override settings without editing chart templates. It is a standard top-level file in a Helm chart structure, satisfying the question's requirement for contained items.

Why this answer

B (values.yaml) is correct because it is the default configuration file in a Helm chart that supplies values used to render the templates, allowing users to override settings at install time. C (Chart.yaml) is correct because it is the required chart metadata file containing fields such as apiVersion, name, version, and description that identify and version the chart. D (templates/ directory) is correct because it holds the Kubernetes manifest templates (e.g., deployment.yaml, service.yaml) that Helm renders with values into final YAML.

A (Dockerfile) is not part of the Helm chart structure; it is used to build container images, which Helm charts typically reference rather than contain. E (ImageStream) is an OpenShift-specific API object, not a Helm chart component, so it does not belong.

Exam trap

EX280 often tests the misconception that a Dockerfile is part of a Helm chart — candidates confuse image build artifacts with chart packaging structure.

Practice this question →
24
MCQhard

An administrator is managing a DeploymentConfig named frontend in an OpenShift 4.14 cluster. The DeploymentConfig has a ConfigChange trigger enabled. The administrator needs to update the container image in the DeploymentConfig without triggering an automatic rollout, so that multiple changes can be made before a manual rollout. Which action should the administrator take?

A.Run oc rollout cancel dc/frontend before making changes, then run oc rollout latest dc/frontend after changes.
B.Run oc edit dc/frontend and change the triggers section to disable the ConfigChange trigger, then apply the change.
C.Run oc rollout pause dc/frontend, make the changes, then run oc rollout resume dc/frontend.
D.Run oc set triggers dc/frontend --remove --from-config, make the changes, then re-add the trigger.
AnswerC

The oc rollout pause command prevents the DeploymentConfig from starting new rollouts, even when triggers fire. After making changes, oc rollout resume allows the rollout to proceed. This is the correct way to batch multiple changes without intermediate rollouts.

Why this answer

Pausing a DeploymentConfig with oc rollout pause is the standard method to temporarily prevent rollouts from starting, even when triggers fire. This allows an administrator to make multiple changes and then resume the rollout to apply them all at once. It is a reversible and non-destructive operation that does not alter the trigger configuration.

Exam trap

The trap here is confusing pausing a rollout with removing or disabling triggers, which permanently changes the DeploymentConfig configuration and is not easily reversible.

Practice this question →
25
Multi-Selecteasy

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

Select 3 answers
A.Jenkinsfile
B.Custom
C.Source
D.HelmBuild
E.Docker
AnswersB, C, E

Custom builds run user-supplied builder images defined in the BuildConfig, letting teams execute arbitrary build logic beyond the Source-to-Image, Docker and Pipeline strategies. This satisfies the stem's requirement for a valid OpenShift build strategy, since Custom is a first-class strategy type alongside the others.

Why this answer

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.

Exam trap

EX280 often tests the distinction between BuildConfig strategies and pipeline strategies, tricking candidates into selecting Jenkinsfile as a build strategy when it is actually a pipeline definition.

Practice this question →
26
MCQeasy

Which command-line argument can you use to change the output format of 'oc get' to YAML?

A.-o yaml
B.--format yaml
C.--yaml
D.-f yaml
AnswerA

The `-o yaml` flag sets `oc get`'s output format to YAML, satisfying the stem's requirement for a command-line argument that changes the default table output. The `-o` (or `--output`) flag accepts format values including `yaml`, `json` and `wide`, making it the precise mechanism for this scenario.

Why this answer

The `-o` flag (short for `--output`) is the standard way to specify the output format for `oc get` and other `oc` commands. It accepts values like `yaml`, `json`, `wide`, `name`, etc. Therefore, `-o yaml` correctly changes the output to YAML.

Exam trap

EX280 often tests the difference between `-o` (output format) and `-f` (filename), as both are common flags but serve entirely different purposes.

How to eliminate wrong answers

Option B is wrong because `--format` is not a valid flag for `oc get`; the correct flag is `--output` or `-o`. Option C is wrong because `--yaml` is not a recognized flag; YAML output is specified via `-o yaml`. Option D is wrong because `-f` is used to specify a filename or directory (e.g., `-f file.yaml`), not to change output format.

Practice this question →
27
MCQeasy

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

A.oc get build
B.oc describe build
C.oc logs [pod-name]
D.oc logs build/[build-name]
AnswerD

`oc logs build/[build-name]` targets the Build resource directly, streaming output from the build pod that OpenShift creates for each build. This satisfies the stem's requirement to view logs for a specific build, unlike pod- or deployment-scoped alternatives.

Why this answer

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.

Exam trap

EX280 often tests whether candidates confuse `oc get`/`oc describe` (metadata and status) with `oc logs` (actual runtime output), and whether they know the `build/<name>` resource-qualified syntax instead of guessing a pod name.

How to eliminate wrong answers

Option A is wrong because `oc get build` only lists build objects and their status columns — it does not retrieve log output. Option B is wrong because `oc describe build` shows metadata, conditions, and events for the build object but not the container stdout/stderr logs. Option C is wrong because `oc logs [pod-name]` requires knowing the ephemeral build pod name, which is not the same as the build name and is not the intended abstraction for build logs.

Practice this question →
28
MCQmedium

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

A.base.yaml
B.overlay.yaml
C.kustomization.yaml
D.resources.yaml
AnswerC

Kustomize requires a kustomization.yaml file in each directory it builds, including the base, since this file declares the resources, patches and configuration to apply. Without it, the base directory defines no resources and kustomize build fails.

Why this answer

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.

Exam trap

EX280 often tests the assumption that a file named after the directory (base.yaml, overlay.yaml) is required, when Kustomize always looks for the fixed name kustomization.yaml.

How to eliminate wrong answers

Option A is wrong because 'base.yaml' is not a recognized Kustomize file name — the tool looks specifically for kustomization.yaml (or kustomization.yml / Kustomization). Option B is wrong because 'overlay.yaml' is not a Kustomize file; overlays are directories that contain their own kustomization.yaml referencing the base. Option D is wrong because 'resources.yaml' is not a Kustomize control file — resources are listed inside kustomization.yaml under the 'resources:' field, not in a separate file by that name.

Practice this question →
29
Multi-Selecthard

Which THREE pieces of data can an ImageStream reference?

Select 3 answers
A.Internal registry image
B.Specific image tag
C.Git repository
D.External registry image
E.DeploymentConfig
AnswersA, B, D

An ImageStream can reference an image held in the internal OpenShift registry, resolving it through the integrated registry's image metadata rather than an external source. This satisfies the stem's requirement for a valid reference target, since internal registry images are tracked directly by the ImageStream's tag and image objects.

Why this answer

An ImageStream in OpenShift tracks image references, and it can point to an image in the internal registry (option A), which is the typical case when builds push images to the integrated registry and deployments pull from it. It can also reference a specific image tag (option B), since ImageStreamTags are the mechanism by which an ImageStream maps a tag name to a concrete image ID. Additionally, an ImageStream can reference an image in an external registry (option D), allowing OpenShift to track and import images hosted outside the cluster.

Option C is incorrect because a Git repository is a source for builds (e.g., BuildConfig source), not something an ImageStream references. Option E is incorrect because a DeploymentConfig consumes ImageStreams via triggers or image change parameters; it is not a target that an ImageStream references.

Exam trap

EX280 often tests the confusion between ImageStreams and BuildConfigs, leading candidates to incorrectly select Git repository as an ImageStream reference.

Practice this question →
30
Multi-Selectmedium

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

Select 2 answers
A.Creating an alias or tag pointing one ImageStream tag to another using oc tag
B.Running unit tests against container image layers using oc test-image
C.Compiling raw source code into an executable binary using oc tag
D.Importing images from an external container registry into an ImageStream using oc import-image
E.Directly modifying kernel parameters on worker nodes via oc image
AnswersA, D

The oc tag command creates or updates an ImageStreamTag, letting an administrator point one tag at another's image or an external reference. This satisfies the stem's alias requirement, enabling promotion or rollback without rebuilding images.

Why this answer

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.

Exam trap

EX280 often tests whether candidates can separate genuine oc ImageStream operations (tag, import-image) from fabricated commands (test-image, image for kernel tuning) that sound plausible but do not exist.

Practice this question →
31
MCQhard

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

A.--override
B.--config
C.--set-file
D.--values
AnswerD

`--values` (or `-f`) supplies a YAML file whose keys override the chart's default `values.yaml`, letting you inject environment-specific settings at install or upgrade time. It directly satisfies the stem's requirement to pass custom values per environment, and multiple files can be layered with later ones taking precedence.

Why this answer

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.

Exam trap

EX280 often tests the distinction between --values and --set-file, as candidates may confuse passing a full values file with setting individual values from files.

How to eliminate wrong answers

Option A is wrong because --override is not a valid Helm flag; Helm does not have an --override option for passing values files. Option B is wrong because --config is not a Helm flag; it might be confused with other tools' configuration flags, but Helm uses --values for this purpose. Option C is wrong because --set-file is used to set individual values from file contents (e.g., --set-file key=path), not to pass a complete values file; it's for specific values, not wholesale overrides.

Practice this question →
32
MCQhard

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?

A.Create two separate Routes
B.Modify the Deployment strategy
C.Use the 'oc scale' command
D.Use Route weights
AnswerD

Route weights let you split incoming traffic across multiple Services by assigning relative percentages, so you can gradually shift requests from the old version to the new one. This is the native OpenShift mechanism when no Service Mesh is available.

Why this answer

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.

Exam trap

EX280 often tests the misconception that scaling replicas or using multiple Routes can achieve canary deployments, but the key is that only Route weights provide native traffic splitting without a Service Mesh.

How to eliminate wrong answers

Option A is wrong because creating two separate Routes would expose two different hostnames or paths, requiring clients to choose which version to access; it does not automatically split traffic between versions on the same endpoint. Option B is wrong because modifying the Deployment strategy (e.g., RollingUpdate) controls how pods are replaced during an update, not how traffic is distributed between two simultaneously running versions; it cannot achieve a canary release with fine-grained traffic control. Option C is wrong because 'oc scale' only adjusts the number of pod replicas for a Deployment or ReplicationController; while scaling can influence the proportion of pods, it does not directly control traffic routing and is not a reliable or standard way to split traffic between versions.

Practice this question →
33
Multi-Selectmedium

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

Select 2 answers
A.Source (S2I)
B.Ansible
C.Knative
D.Helm
E.Docker
AnswersA, E

Source-to-Image is a native OpenShift build strategy, compiling application source against a builder image to produce a runnable image without a Dockerfile. It satisfies the BuildConfig requirement directly, alongside Docker and custom strategies, and needs no additional operator installation.

Why this answer

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.

Exam trap

EX280 often tests the exact set of native build strategies — candidates may incorrectly include Helm or Ansible because they are common in DevOps toolchains, but only Source and Docker are BuildConfig strategies.

Practice this question →
34
MCQhard

A team runs a Deployment named catalog-api in project retail. After a configuration change, pods crash with an application error, and the administrator needs to return the Deployment to the last known-good revision. The administrator runs oc rollout history deployment/catalog-api and sees revision 7 as the current one. Which single command restores the previous working revision?

A.oc delete deployment/catalog-api && oc apply -f catalog-api-backup.yaml
B.oc rollout undo deployment/catalog-api --to-revision=6
C.oc rollout restart deployment/catalog-api
D.oc set image deployment/catalog-api catalog-api=registry.example.com/catalog-api:previous
AnswerB

This is correct because the undo subcommand with --to-revision restores the pod template recorded for the specified earlier revision and then triggers a rollout of that template. Revision 6 precedes the failing revision 7, so it represents the last known-good state. The Deployment controller creates a new ReplicaSet from the restored template, returning the application to service without manual editing.

Why this answer

Deployment revisions are retained in the controller's ReplicaSet history, so the last known-good pod template can be restored by undoing to a specific revision. Using the undo subcommand with the revision number that preceded the failure reinstates that template and starts a rollout, bringing the application back without manual manifest edits or loss of history.

Exam trap

The trap here is assuming that restarting a Deployment reverts its configuration, when a restart simply recreates pods from the same current, still-failing template.

Practice this question →
35
Multi-Selecthard

Which THREE things can you configure in a BuildConfig?

Select 3 answers
A.Build Strategy
B.Source Code Reference
C.Replicas
D.Triggers
E.Route settings
AnswersA, B, D

Build strategy is a core BuildConfig field, letting you select Source, Docker, or Custom strategies to control how the build executes. This directly satisfies the question's requirement for configurable BuildConfig elements, alongside triggers and output. Each strategy defines distinct build behaviour, so specifying it is essential when defining how OpenShift builds your application image.

Why this answer

In OpenShift, a BuildConfig defines how a build is performed, and its spec includes the build strategy (for example Source, Docker, or Custom), so option A 'Build Strategy' is correct. It also includes the source configuration (spec.source), which specifies the Source Code Reference such as a Git repository URL and ref or a binary/context directory, making option B correct. Additionally, a BuildConfig can define triggers (spec.triggers) like ImageChange, ConfigChange, GitHub/GitLab webhooks, or generic webhooks to automatically start builds, so option D is correct.

Option C 'Replicas' is not part of a BuildConfig; replica counts belong to workload controllers such as DeploymentConfigs or Deployments. Option E 'Route settings' is also not part of a BuildConfig; routes are configured via Route resources to expose services externally.

Exam trap

EX280 often tests the misconception that BuildConfigs manage runtime concerns like replicas or routes, when in fact they only govern image construction — runtime scaling and exposure are separate resources.

Practice this question →
36
MCQhard

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?

A.Webhook
B.Periodic
C.ImageChange
D.ConfigChange
AnswerC

An ImageChange trigger watches a referenced ImageStreamTag and starts a build automatically when a new image lands on that tag. This satisfies the requirement that pushing an image to a dependent tag triggers the build without manual intervention.

Why this answer

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.

Exam trap

EX280 often tests the distinction between trigger types by describing an event (image push, code commit, schedule, config edit) and expecting you to map it to the correct trigger — candidates frequently confuse Webhook with ImageChange.

How to eliminate wrong answers

Option A is wrong because a Webhook trigger only fires when an external system calls the BuildConfig's webhook URL (GitHub/GitLab/generic) — it does not monitor image pushes. Option B is wrong because a Periodic trigger runs the build on a cron schedule, not in response to image events. Option D is wrong because a ConfigChange trigger only fires when the BuildConfig's own spec changes at creation/update time, not when a dependent image is pushed.

Practice this question →
37
MCQeasy

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

A.Continuous Deployment trigger
B.WebHook trigger
C.ConfigChange trigger
D.ImageChange trigger
AnswerD

An ImageChange trigger watches the referenced ImageStream tag and starts a new build automatically when the base image updates. Enabling it in the BuildConfig satisfies the stem's requirement to trigger builds whenever the base image in the ImageStream changes.

Why this answer

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.

Exam trap

EX280 often tests the difference between BuildConfig triggers (ImageChange, ConfigChange, WebHook) and DeploymentConfig triggers, so candidates must not confuse a deployment trigger with a build trigger.

How to eliminate wrong answers

Option A is wrong because 'Continuous Deployment trigger' is not a BuildConfig trigger type; deployment triggers exist on DeploymentConfigs, not BuildConfigs. Option B is wrong because a WebHook trigger requires an external HTTP call (GitHub, GitLab, generic) to start a build, not an ImageStream change. Option C is wrong because a ConfigChange trigger starts a build only when the BuildConfig itself is modified, not when a base image changes.

Practice this question →
38
MCQmedium

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

A.To notify an external system
B.To run tests on the image
C.To push the image to an external registry
D.To restart the Deployment
AnswerB

The postCommit hook executes commands inside a temporary container built from the freshly produced image, after the build completes. It satisfies the stem's purpose by running tests, such as integration or unit checks, against the actual image output, verifying the artefact before it is pushed or deployed.

Why this answer

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.

Exam trap

EX280 often tests the distinction between build hooks and other build lifecycle events, and candidates may confuse postCommit with post-build actions like pushing or notifying, leading them to select options that describe those actions instead of testing.

How to eliminate wrong answers

Option A is wrong because notifying an external system is typically done via build webhooks or custom notifications, not the postCommit hook. Option C is wrong because pushing the image to an external registry is controlled by the build's output configuration and push secrets, not the postCommit hook. Option D is wrong because restarting a Deployment is handled by image change triggers or manual rollout commands, not by the postCommit hook.

Practice this question →
39
Multi-Selectmedium

Which TWO of the following are valid ways to trigger a build in OpenShift?

Select 2 answers
A.Restarting the OpenShift cluster
B.Sending a HTTP POST to the webhook URL
C.Executing 'oc start-build'
D.Updating a ConfigMap
E.Changing a Namespace
AnswersB, C

Webhook triggers let external systems start builds without cluster credentials: a POST to the build config's webhook URL fires the build server-side. This satisfies the stem's requirement for a valid trigger mechanism, alongside the GitHub, GitLab and generic webhook variants OpenShift exposes.

Why this answer

Option B is correct because OpenShift BuildConfigs can expose generic, GitHub, or GitLab webhook endpoints, and issuing an HTTP POST to that webhook URL (e.g., via curl) triggers a new build of the associated BuildConfig. Option C is correct because the 'oc start-build' command is the standard CLI method to manually start a build, either by BuildConfig name (with options like --from-build, --follow, or --from-dir) or by referencing an existing build. Restarting the OpenShift cluster (A) is an administrative action that does not initiate builds, updating a ConfigMap (D) only changes configuration data and does not by itself start a build, and changing a Namespace (E) is a context/scope operation with no build-triggering semantics.

Exam trap

EX280 often tests the distinction between valid build triggers and unrelated cluster operations, so candidates may mistakenly think that restarting the cluster or modifying resources like ConfigMaps or Namespaces can trigger builds.

Practice this question →
40
Multi-Selectmedium

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

Select 2 answers
A.PeriodicTrigger
B.ConfigChange
C.WebhookTrigger
D.GitTrigger
E.ImageChange
AnswersB, E

ConfigChange is a native DeploymentConfig trigger type that rolls out a new revision when the DC template changes.

Why this answer

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

Practice this question →
41
Multi-Selecthard

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

Select 3 answers
A.Pausing a rollout to make multiple configuration updates
B.Triggering a direct source build from a local directory
C.Viewing the revision history of a deployment
D.Checking the current status of an ongoing rollout
E.Scaling the number of replicas up or down
AnswersA, C, D

The oc rollout pause command halts a deployment rollout, allowing several configuration changes to be applied before resuming, so updates deploy together rather than triggering separate rollouts. This satisfies the stem's requirement for an action available through the oc rollout subcommand.

Why this answer

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`).

Exam trap

EX280 often tests the distinction between `oc rollout` and other `oc` subcommands like `oc scale` and `oc start-build`, so candidates must remember that `oc rollout` is exclusively for managing rollout lifecycle, not for scaling or building.

Practice this question →
42
MCQeasy

Which OpenShift resource defines the desired state of a containerized application, including replica count and image version?

A.Deployment
B.Pod
C.ImageStream
D.Service
AnswerA

A Deployment declares the desired state for a containerised application, specifying the replica count and container image version. The Deployment controller continuously reconciles actual cluster state against this declaration, recreating or updating pods to match, which satisfies the stem's requirement for defining desired state.

Why this answer

A Deployment in OpenShift defines the desired state of a containerized application, including the replica count, container image version, and update strategy. It manages ReplicaSets and Pods declaratively, ensuring the specified number of replicas and image version are maintained. This makes Deployment the correct resource for defining desired state including replicas and image version.

Exam trap

EX280 often tests the distinction between workload controllers (Deployment) and networking or image abstractions (Service, ImageStream) — candidates may incorrectly pick Pod or Service when asked about desired state including replicas and image version.

How to eliminate wrong answers

Option B is wrong because a Pod represents a single running instance of a container and does not define desired replica count or manage rolling updates. Option C is wrong because an ImageStream is an OpenShift abstraction for tracking container image tags and streams, not for defining application desired state or replica count. Option D is wrong because a Service provides a stable network endpoint for accessing Pods, not the desired state of the application deployment.

Practice this question →
43
Multi-Selecthard

Which THREE components are part of a Kustomize configuration?

Select 3 answers
A.kustomization.yaml
B.BuildConfigs
C.Resources
D.Helm Charts
E.Patches
AnswersA, C, E

The main entry point.

Why this answer

In Kustomize, the kustomization.yaml file (Option A) is the mandatory entry-point manifest that declares which resources, patches, and other directives Kustomize should process, so it is a core component of any Kustomize configuration. Resources (Option C) are the base Kubernetes manifests (Deployments, Services, ConfigMaps, etc.) listed under the resources field that Kustomize reads and composes. Patches (Option E) are the strategic-merge or JSON 6902 overlays declared under fields like patchesStrategicMerge and patches that customize those resources per environment.

BuildConfigs (Option B) are OpenShift build objects, not Kustomize components, and Helm Charts (Option D) belong to the Helm package manager, which Kustomize can reference only via a helmCharts generator but is not itself a Kustomize component.

Exam trap

EX280 often tests whether candidates confuse Kustomize with Helm — the trap is selecting Helm Charts as a Kustomize component when Kustomize is deliberately template-free and uses kustomization.yaml, resources, and patches.

Practice this question →
44
MCQmedium

You are preparing to deploy an application to an OpenShift Container Platform 4.14 cluster. The application is defined across multiple Kubernetes manifests, and you need to ensure that a set of common labels and a namespace prefix are applied to all resources. You want to use Kustomize to manage this without writing custom scripts. Which of the following best describes how to achieve this using the oc CLI?

A.Run oc apply -f kustomization.yaml to apply the customized resources directly.
B.Run oc new-app --kustomize . to deploy the application from the Kustomize directory.
C.Use the oc kustomize command to generate the customized manifests, then pipe the output to oc apply -f -.
D.Create a kustomization.yaml file that references the base manifests, then run oc apply -k . to apply the customized resources.
AnswerD

The oc apply -k command is specifically designed to apply resources defined in a kustomization.yaml file. It processes the base manifests, applies any transformations such as common labels and name prefixes, and then submits the resulting resources to the cluster. This is the standard, declarative way to use Kustomize with OpenShift.

Why this answer

Kustomize is integrated into the oc CLI, and the oc apply -k command is the correct way to apply a kustomization directory. It reads the kustomization.yaml, applies transformations like common labels and name prefixes, and then applies the resulting resources to the cluster. This declarative approach is preferred over manual generation and piping.

Exam trap

The trap here is assuming that oc apply -f can process a kustomization.yaml file directly, but it cannot because that file is not a Kubernetes resource manifest.

Practice this question →
45
MCQeasy

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

A.oc trigger-build frontend
B.oc run-build frontend
C.oc start-build frontend
D.oc build frontend
AnswerC

The oc start-build command triggers a new build from an existing BuildConfig, referencing it by name. This satisfies the requirement to initiate a build from the 'frontend' BuildConfig without supplying source or binary input manually.

Why this answer

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

Exam trap

EX280 often tests whether candidates invent plausible-sounding but nonexistent oc subcommands (trigger-build, run-build, build), so they pick a wrong verb instead of the real start-build.

How to eliminate wrong answers

Option A is wrong because oc trigger-build is not a valid oc subcommand; there is no such verb in the OpenShift CLI. Option B is wrong because oc run-build does not exist; oc run is for creating pods/deployments from images, not builds. Option D is wrong because oc build is not a valid subcommand either; the correct verb is start-build.

Practice this question →
46
MCQmedium

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?

A.Under the includes: key
B.Under the bases: key
C.Under the resources: key
D.Under the overlays: key
AnswerC

Kustomize overlays compose a base by listing its directory path under the resources: field in prod/kustomization.yaml. This pulls the shared base manifests into the prod build, letting the overlay apply prod-specific patches, replicas and image tags without duplicating common resources.

Why this answer

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.

Exam trap

EX280 often tests the deprecated `bases:` vs current `resources:` distinction — candidates who learned Kustomize before v3 pick `bases:` because it was historically correct.

How to eliminate wrong answers

Option A is wrong because `includes:` is not a valid Kustomize field — it does not exist in the kustomization.yaml schema. Option B is wrong because `bases:` was deprecated in Kustomize v2.1.0 and removed in v3; while older OpenShift documentation used it, current `oc kustomize` rejects or warns on it, and the exam expects the modern field. Option D is wrong because `overlays:` is not a kustomization.yaml key — overlays are directories that reference bases, not a field you declare inside a kustomization file.

Practice this question →
47
MCQmedium

During an S2I build, an administrator needs to pass sensitive build arguments, such as subscription keys, without hardcoding them into the BuildConfig or exposing them in the final image history. How should this be handled?

A.Storing them in an ImageStream annotation
B.Using build secrets mounted via the source secret or build strategy configuration
C.Defining them as plain environment variables in the BuildConfig spec
D.Injecting them via the Route host header
AnswerB

Build secrets can be securely mounted into the builder pod during the build process without being baked into the final image layers.

Why this answer

Build secrets in OpenShift are designed specifically for passing sensitive data like subscription keys, tokens, or credentials into an S2I build without embedding them in the BuildConfig or leaving them in the final image layers. When configured via the source secret (e.g., `sourceSecret` in the BuildConfig) or through the build strategy's `secrets` field, the secret is mounted into the build pod's filesystem at a temporary location and is not committed to the resulting image. This ensures the sensitive data is available only during the build process and is discarded afterward, satisfying both security and compliance requirements.

Exam trap

EX280 often tests the misconception that environment variables in a BuildConfig are secure because they are not visible in the OpenShift web console; in reality, they are stored in plaintext and can leak into image layers, whereas build secrets are the only supported method for ephemeral, non-persistent sensitive data injection.

How to eliminate wrong answers

Option A is wrong because ImageStream annotations are metadata fields used for descriptive or operational purposes (e.g., tags, descriptions) and are not designed to inject runtime or build-time secrets; they are visible to anyone with read access to the ImageStream and would expose the sensitive data. Option C is wrong because plain environment variables in the BuildConfig spec are stored in plaintext in the BuildConfig object and are also baked into the image history if used during the build, directly violating the requirement to avoid hardcoding and exposure. Option D is wrong because Route host headers are used for HTTP routing and TLS termination, not for passing build arguments; they have no mechanism to inject secrets into an S2I build and would be a severe security anti-pattern.

Practice this question →
48
MCQeasy

A developer wants to inspect the generated Kubernetes manifests from a Helm chart without actually installing the chart into the OpenShift cluster. Which Helm command should be used?

A.helm dry-run my-release my-chart
B.helm template my-release my-chart
C.helm show chart my-chart
D.helm inspect values my-chart
AnswerB

`helm template my-release my-chart` renders the chart's templates locally and prints the resulting Kubernetes manifests to stdout, contacting no cluster and creating no resources. This satisfies the stem's constraint of inspecting generated manifests without installing the chart, unlike `helm install`, which applies them to the cluster.

Why this answer

'helm template' renders a chart's templates locally and prints the resulting Kubernetes manifests to stdout without contacting the cluster or installing anything. It is the canonical command for inspecting what a chart would produce, and it accepts a release name and chart reference. This lets developers review, diff, or pipe the output before committing to an install.

Exam trap

EX280 often tests whether candidates confuse 'helm template' (renders manifests locally) with 'helm show' subcommands (display chart metadata or values) or with the --dry-run flag that must accompany install/upgrade.

How to eliminate wrong answers

Option A is wrong because 'helm dry-run' is not a standalone command — dry-run is a flag (--dry-run) used with 'helm install' or 'helm upgrade', not a subcommand. Option C is wrong because 'helm show chart' displays the chart's metadata (Chart.yaml contents) such as version and description, not the rendered manifests. Option D is wrong because 'helm inspect values' (now 'helm show values') prints the chart's default values.yaml, not the generated Kubernetes resources.

Practice this question →
49
Multi-Selectmedium

Which TWO of the following are valid deployment strategies supported by OpenShift?

Select 2 answers
A.Parallel
B.Sequential
C.Recreate
D.Rolling
E.Canary
AnswersC, D

Recreate terminates all existing pods before starting new ones, producing a brief outage but guaranteeing no version overlap. OpenShift supports it natively as a DeploymentConfig strategy, making it valid where simultaneous old and new pod versions cannot coexist.

Why this answer

Options D (Rolling) and C (Recreate) are the two deployment strategies natively supported by OpenShift's DeploymentConfig/Deployment resources. Rolling performs a gradual, zero-downtime replacement of pods using a rolling update with configurable maxUnavailable and maxSurge parameters, while Recreate terminates all existing pods before starting new ones, causing a brief outage but avoiding version overlap. Both are explicitly defined strategy types in OpenShift's deployment configuration API.

Options A (Parallel), B (Sequential), and E (Canary) are not built-in OpenShift deployment strategies; canary-style rollouts can be approximated via custom techniques or routes but are not a native strategy type.

Exam trap

EX280 often tests whether candidates confuse deployment strategies with release methodologies (canary, blue-green), so they incorrectly select Canary as a built-in strategy when it is only an external pattern.

Practice this question →
50
MCQeasy

A developer has built a container image and pushed it to an external registry. They now want to deploy this image as a new application in an OpenShift 4.14 project. Which oc command should they use to create a Deployment that runs the image and exposes it with a Service?

A.oc apply -f deployment.yaml --image=myregistry.com/myimage:latest
B.oc new-app --image-stream=myimage:latest
C.oc create deployment myapp --image=myregistry.com/myimage:latest
D.oc new-app --docker-image=myregistry.com/myimage:latest
AnswerD

The oc new-app command with --docker-image is used to create a new application from an external container image. It creates a Deployment (or DeploymentConfig) and a Service, and optionally a Route. This is the correct way to deploy an image from an external registry.

Why this answer

The oc new-app command is designed to quickly create applications from various sources, including external container images. Using the --docker-image flag allows specifying an image from an external registry, and new-app automatically creates the necessary Deployment and Service resources, and may create a Route if applicable.

Exam trap

The trap here is assuming that oc new-app requires an ImageStream, but it can directly use an external image with --docker-image.

Practice this question →
51
MCQhard

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

A.ReadinessProbe
B.StartupProbe
C.LivenessProbe
D.HealthProbe
AnswerA

A ReadinessProbe determines whether the container is prepared to accept traffic; failing it removes the pod from Service endpoints without restarting it. This matches the stem's requirement of verifying readiness to start receiving traffic, unlike a LivenessProbe, which restarts unhealthy containers.

Why this answer

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.

Exam trap

The trap is confusing readiness with liveness — candidates pick LivenessProbe because it sounds like a health check, but only ReadinessProbe controls whether traffic is sent to the pod.

How to eliminate wrong answers

Option B is wrong because a StartupProbe only checks whether the application has started; once it succeeds, it is disabled and does not gate ongoing traffic. Option C is wrong because a LivenessProbe detects whether a container is still running and triggers a restart on failure — it does not control traffic routing. Option D is wrong because 'HealthProbe' is not a Kubernetes probe type; the three valid types are liveness, readiness, and startup.

Practice this question →
52
Multi-Selectmedium

Which TWO pieces of information are needed when defining a new Helm repository?

Select 2 answers
A.Chart version
B.Username
C.Namespace
D.Repository Name
E.Repository URL
AnswersD, E

Helm identifies each repository by a unique name, which becomes the prefix for charts installed from it (for example, bitnami/nginx). Without a distinct name, Helm cannot resolve or reference the repository, so it is mandatory alongside the URL.

Why this answer

When defining a new Helm repository, the two required pieces of information are the repository name (option D) and the repository URL (option E). The repository name (D) serves as the local alias used by Helm commands such as `helm repo add <name> <url>`, allowing you to reference the repo later (e.g., `helm install mychart <name>/<chart>`). The repository URL (E) is the actual endpoint where the `index.yaml` and chart packages are hosted, which Helm fetches to resolve and download charts.

A chart version (A) is not needed to define a repository; it is specified later when installing or pulling a specific chart. A username (B) is only required for private repositories that enforce authentication, not for defining a repository in general. A namespace (C) is a Kubernetes concept used at install time to scope resources, not part of a Helm repository definition.

Exam trap

EX280 often tests the distinction between repository definition and chart installation, so candidates may incorrectly think chart version is needed when adding a repo.

Practice this question →
53
MCQmedium

An administrator manages a Deployment named payments-api in the project finance-prod. During a maintenance window, changes to the pod template must be staged without any new pods being created. Once all edits are complete, a single rollout should start. Which oc command should the administrator run first?

A.oc rollout undo deployment/payments-api
B.oc rollout pause deployment/payments-api
C.oc rollout status deployment/payments-api
D.oc scale deployment/payments-api --replicas=0
AnswerB

This is correct because pausing a Deployment suspends the rollout controller so that staged pod-template edits are recorded in the Deployment spec but no new ReplicaSet is created and no pods are replaced. Subsequent changes accumulate until the Deployment is resumed, at which point a single rollout begins. This matches the requirement to stage multiple edits without triggering intermediate rollouts.

Why this answer

Pausing a Deployment suspends the rollout controller, so multiple pod-template edits accumulate in the Deployment spec without creating intermediate ReplicaSets or pods. When the Deployment is resumed with oc rollout resume, OpenShift performs a single rollout reflecting all staged changes. Reporting status, undoing a revision, or scaling to zero all fail to suppress rollout creation and therefore do not meet the staged-change requirement.

Exam trap

The trap here is confusing scaling a Deployment to zero replicas with pausing its rollout, when only pausing suppresses the creation of new ReplicaSets from pod-template edits.

Practice this question →
54
Multi-Selectmedium

Which TWO of the following can be used to troubleshoot a failing deployment?

Select 2 answers
A.oc rollout undo
B.oc describe deployment
C.oc logs
D.oc delete project
E.oc start-build
AnswersB, C

`oc describe deployment` surfaces the deployment's status conditions, replica counts, and the ReplicaSet and pod events behind a rollout failure, satisfying the need to pinpoint why pods never reached a ready state. It reports scheduling, image pull, and probe errors aggregated from the controller, giving the diagnostic detail a failing deployment requires.

Why this answer

Option B, `oc describe deployment`, is correct because it surfaces the deployment's status conditions, replica counts, events, and the underlying ReplicaSet/pod status, which is exactly what you need to diagnose why a rollout is failing. Option C, `oc logs`, is correct because retrieving container logs from the failing pods (or build/deployment logs) reveals application-level errors, crash reasons, and startup failures that explain the deployment failure. Option A, `oc rollout undo`, is a remediation command that reverts to a previous revision rather than a troubleshooting tool, so it does not help diagnose the failure.

Option D, `oc delete project`, destroys the namespace and all its resources, which is destructive and not a diagnostic step. Option E, `oc start-build`, triggers a new build and does not investigate why an existing deployment is failing.

Exam trap

EX280 often tests the distinction between troubleshooting commands and remediation or destructive commands, so candidates might mistakenly choose 'oc rollout undo' as a troubleshooting step when it is actually a fix.

Practice this question →
55
Multi-Selectmedium

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

Select 2 answers
A.Kustomize replaces the Kubernetes API server entirely during resource creation.
B.Kustomize is natively integrated into the oc command line tool using the -k flag.
C.Kustomize requires a centralized chart repository server similar to ChartMuseum.
D.Kustomize allows modifying base manifests using patches and name prefixes/suffixes.
E.Kustomize requires writing complex Go templates with conditional logic statements.
AnswersB, D

The oc client embeds Kustomize directly, so applying a directory containing a kustomization.yaml via the -k flag builds and deploys the rendered manifests. This native integration satisfies the statement that Kustomize works through oc without requiring separate kustomize binaries or plugins.

Why this answer

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 <dir>' or 'oc kustomize <dir>', 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.

Exam trap

EX280 often tests the confusion between Kustomize and Helm, tricking candidates into selecting answers about chart repositories or Go templating that apply to Helm, not Kustomize.

Practice this question →
56
MCQeasy

A developer wants to track multiple versions and tags of container images within an OpenShift cluster efficiently. Which OpenShift resource provides this capability?

A.Route
B.ImageStream
C.DeploymentConfig
D.BuildConfig
AnswerB

ImageStreams abstract image references, tracking multiple versions and tags via image tags and history within OpenShift. This satisfies the developer's need to manage and reference changing container images without hardcoding registry paths, enabling triggers and rollbacks.

Why this answer

An ImageStream is an OpenShift resource that acts as an abstraction layer over container images, allowing you to track multiple versions and tags of an image. It maintains a history of image changes and provides a stable reference that can trigger builds and deployments when new images are pushed or tagged. This makes it ideal for efficiently managing image versions and tags within the cluster.

Exam trap

EX280 often tests the distinction between resources that manage images versus those that manage deployments or builds, causing candidates to confuse ImageStreams with BuildConfigs or DeploymentConfigs.

How to eliminate wrong answers

Option A is wrong because a Route exposes a service to external traffic and has nothing to do with tracking container image versions or tags. Option C is wrong because a DeploymentConfig defines how to deploy an application, including triggers and strategies, but it does not itself track multiple versions or tags of images; it relies on ImageStreams for that capability. Option D is wrong because a BuildConfig defines how to build a container image from source code, but it does not provide version or tag tracking of existing images.

Practice this question →
57
MCQmedium

When creating a build using S2I, what does the 'assemble' script do?

A.Sets up the user environment
B.Starts the application
C.Downloads the base image
D.Builds the application artifacts
AnswerD

The assemble script executes the build logic inside the builder image, compiling source and producing the runnable artefacts placed in the build context. This is the S2I phase that transforms application source into deployable output, distinct from the run script that starts the resulting image.

Why this answer

In Source-to-Image (S2I), the assemble script is responsible for building the application artifacts from the source code. It runs after the source code is copied into the builder image and performs the necessary build steps, such as compiling code, installing dependencies, and preparing the application for execution. This is a core part of the S2I build process.

Exam trap

EX280 often tests the confusion between the assemble and run scripts. The trap is thinking that assemble starts the application, but it actually builds it.

How to eliminate wrong answers

Option A is wrong because setting up the user environment is typically handled by the run script or the builder image's setup, not the assemble script. Option B is wrong because starting the application is the role of the run script, which is executed when the container is launched. Option C is wrong because downloading the base image is done by the S2I tooling before the build process, not by the assemble script.

Practice this question →
58
MCQmedium

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

A.Delete the current deployment
B.Return to the state at initial deployment
C.Roll back to the previous revision
D.Roll back to revision 1
AnswerC

With no revision given, rollout undo reverts the Deployment to the immediately preceding ReplicaSet revision, satisfying the default rollback behaviour. Kubernetes records each template change as a numbered revision, so omitting --to-revision simply steps back one, restoring the prior pod template and configuration.

Why this answer

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.

Exam trap

EX280 often tests whether candidates confuse the default 'previous revision' behavior of `rollout undo` with the explicit `--to-revision=1` flag that targets the initial deployment.

How to eliminate wrong answers

Option A is wrong because `rollout undo` never deletes a Deployment — it swaps the active ReplicaSet to a prior revision, leaving the Deployment object intact. Option B is wrong because returning to the initial deployment would require explicitly specifying `--to-revision=1`; the default is the immediately previous revision, not the first one. Option D is wrong because revision 1 is only the target if the administrator explicitly passes `--to-revision=1`; the default is the prior revision regardless of how many revisions exist.

Practice this question →
59
MCQeasy

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

A.Helm
B.oc build
C.Kustomize
D.S2I
AnswerA

Helm charts bundle Kubernetes manifests, default values and dependency charts into a single versioned artefact, so an application's configuration and dependencies ship together. This satisfies the stem's packaging-and-distribution requirement, unlike raw manifests or templates alone.

Why this answer

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.

Exam trap

EX280 often tests the distinction between packaging/distribution tools (Helm) and build/configuration tools (S2I, Kustomize, oc start-build), so candidates must not pick a build tool when the question asks for packaging.

How to eliminate wrong answers

Option B is wrong because 'oc build' is not a real command; builds are started with 'oc start-build' and are used to produce images, not package applications. Option C is wrong because Kustomize is a configuration overlay tool that customizes YAML without templating, but it does not package dependencies or provide a distribution format like a chart. Option D is wrong because S2I (Source-to-Image) builds container images from source code; it does not package an application with its dependencies and configuration for distribution.

Practice this question →
60
Multi-Selecthard

Which THREE items are required to successfully deploy a basic application using S2I?

Select 3 answers
A.BuildConfig
B.External Load Balancer
C.A pre-existing Database
D.Builder Image
E.Source Code
AnswersA, D, E

A BuildConfig defines the build strategy, source reference and output image stream, triggering and orchestrating the S2I assembly. It is one of the three required items, since without it no build is instantiated from the source and builder image.

Why this answer

Option A (BuildConfig) is required because S2I builds are driven by an OpenShift BuildConfig that defines the source, strategy (Source-to-Image), and output image stream for the application. Option D (Builder Image) is required because the S2I build strategy needs an S2I-enabled builder image (e.g., a builder image stream such as nodejs or python) that contains the assemble and run scripts to compile and package the source. Option E (Source Code) is required because S2I takes application source (from a Git repository, binary, or local directory) as the input that the builder image's assemble script transforms into a runnable image.

Option B (External Load Balancer) is not required for a basic S2I deployment, since OpenShift Routes or Services handle exposure internally. Option C (A pre-existing Database) is not required, as a basic application deployment does not depend on an external database being present.

Exam trap

EX280 often tests whether candidates confuse optional components like databases or load balancers with the essential building blocks of an S2I build, leading them to select unnecessary items.

Practice this question →
61
MCQhard

You want to automate the application lifecycle so that every time a code change is pushed, the build and deployment occur automatically. Which combination of features should you use?

A.Only cron jobs
B.Manual build and manual rollout
C.BuildConfig Webhook and ImageStream triggers
D.DeploymentConfigs only
AnswerC

A BuildConfig webhook triggers a build on each code push, and ImageStream triggers then deploy the resulting image automatically. Together they satisfy the stem's requirement for fully automated build and deployment on every code change, without manual intervention.

Why this answer

In OpenShift, BuildConfig webhooks (GitHub, GitLab, Bitbucket, or generic) allow external code repositories to trigger a new build automatically when a change is pushed. ImageStream triggers then detect when a new image is pushed to an ImageStream and automatically start a new deployment (via DeploymentConfig or Deployment). Together, they create a fully automated CI/CD pipeline from code push to deployment.

This is the standard OpenShift-native approach for automating the application lifecycle.

Exam trap

EX280 often tests the misconception that DeploymentConfigs alone can automate deployments, confusing manual triggers with automatic ones, or overlooking the need for a build trigger (webhook) and an image trigger (ImageStream) to achieve full automation.

How to eliminate wrong answers

Option A is wrong because cron jobs only schedule tasks at fixed times and cannot react to code changes; they lack integration with source control or image streams. Option B is wrong because manual build and manual rollout require human intervention, which defeats the purpose of automation. Option D is wrong because DeploymentConfigs alone only manage deployment and scaling; they do not trigger builds or respond to code pushes without additional triggers like ImageStreams or webhooks.

Practice this question →
62
MCQhard

What is the result of using a 'Recreate' strategy during a deployment?

A.Zero downtime deployment
B.Rolling update
C.Temporary service outage
D.Instant switch
AnswerC

The Recreate strategy terminates all existing pods before starting new ones, so no instances serve traffic during the gap. This satisfies the stem's scenario, producing a temporary service outage, unlike RollingUpdate which maintains availability throughout the transition.

Why this answer

The Recreate strategy terminates all existing Pods before creating new ones, which necessarily causes a temporary service outage because there is a period with zero running Pods. This is in contrast to RollingUpdate, which maintains availability by incrementally replacing Pods. The Recreate strategy is used when the application cannot run multiple versions concurrently.

Exam trap

EX280 often tests the trade-off between Recreate (downtime, no version overlap) and RollingUpdate (no downtime, version overlap), so candidates must recognize that Recreate inherently causes an outage.

How to eliminate wrong answers

Option A is wrong because zero downtime requires a rolling update or blue-green deployment, not Recreate. Option B is wrong because a rolling update is a different strategy (RollingUpdate) that replaces Pods incrementally. Option D is wrong because 'Instant switch' is not a standard deployment strategy and does not describe Recreate's behavior.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Application Deployment And Lifecycle questions.

Start 20-question session