EX280 Application Deployment And Lifecycle Practice Test 2 — 15 Questions

Question 1

You are preparing a deployment strategy for an application in OpenShift 4.14. The application requires zero downtime during updates and must support both the Rolling and Recreate strategies. Which deployment strategy should you choose?

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

Accepted Answer

Rolling. The Rolling strategy is designed to update pods incrementally while maintaining availability, thus achieving zero downtime. It is one of the built-in strategies and is suitable for applications that can run multiple versions concurrently. The Recreate strategy causes downtime, and Custom or Blue-Green are not native strategies. Therefore, Rolling is the correct choice for zero-downtime deployments.

Answer

Custom

Answer

Blue-Green

Answer

Recreate

Question 2

An administrator must expose an application running as a Deployment named reports in project analytics so that users inside the cluster can reach it by the DNS name reports.analytics.svc.cluster.local on port 80. The pods listen on container port 8080. Which oc command creates the required object with the least configuration?

Accepted Answer

oc expose deployment/reports --port=80 --target-port=8080. Creating a Service from an existing Deployment with the expose subcommand automatically derives the pod selector, names the Service after the Deployment, and maps the requested service port to the container's target port. That produces the internal DNS name on port 80 as required. Creating a Route targets external access, and creating a Service manually risks the wrong port mapping or selector.

Answer

oc create route edge reports --service=reports --port=8080

Answer

oc create service clusterip reports --tcp=8080:8080

Answer

oc expose svc/reports --port=80 --target-port=8080

Question 3

A developer needs to run a one-off database migration task in project billing that uses the image registry.example.com/tools/migrate:1.4 and must not be restarted after completion. Which oc command creates the appropriate workload?

Accepted Answer

oc run db-migrate --image=registry.example.com/tools/migrate:1.4 --restart=Never. A one-off task that must run to completion and not restart is best created as a Pod with a restart policy of Never, which the run subcommand supports directly with the restart flag. Policies of Always, or controllers such as Deployments that maintain replicas, would recreate or restart the container and re-run the migration. The job generator also does not accept an image flag.

Answer

oc create job db-migrate --image=registry.example.com/tools/migrate:1.4

Answer

oc create deployment db-migrate --image=registry.example.com/tools/migrate:1.4

Answer

oc run db-migrate --image=registry.example.com/tools/migrate:1.4 --restart=Always

Question 4

An administrator is preparing a Deployment named inventory in project storefront for a controlled rollout. The administrator wants the new version to receive no production traffic until it is validated, while still allowing a small amount of test traffic to reach it. Which TWO OpenShift features allow directing a subset of traffic to the new pods during the rollout? (Choose two.)

Accepted Answer

A Route with multiple backends and per-backend weights. Directing a portion of traffic to a new version requires both a way to select the new pods and a way to weight traffic between versions. A Service whose selector matches the new labels isolates the canary pods, and a Route with multiple weighted backends splits requests between the stable and canary Services. Network policies, disruption budgets, and image triggers affect connectivity, availability, and automation, not traffic distribution.

Answer

An ImageStreamTag trigger on the DeploymentConfig

Answer

A PodDisruptionBudget on the Deployment

Answer

A NetworkPolicy that limits ingress to the new pods

Question 5

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?

Accepted Answer

oc rollout undo deployment/my-app. 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.

Answer

oc update deployment/my-app --revision=previous

Answer

oc revert deployment/my-app

Answer

oc rollback deployment/my-app

Question 6

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?

Accepted Answer

oc apply -k ./directory. 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.

Answer

oc create -f kustomization.yaml

Answer

oc run -k ./directory

Answer

oc kustomize apply ./directory

Question 7

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?

Accepted Answer

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

Answer

interval

Answer

updatePeriodSeconds

Answer

maxUnavailable

Question 8

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?

Accepted Answer

helm install my-release my-chart --values overrides.yaml. The Helm CLI command to install a chart with value overrides from a file is 'helm install --values '. 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.

Answer

helm push my-chart --override overrides.yaml

Answer

helm deploy my-release my-chart --values overrides.yaml

Answer

helm apply -f overrides.yaml my-chart

Question 9

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

Accepted Answer

oc rollout history dc/web-frontend. 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.

Answer

oc describe dc/web-frontend

Answer

oc get revisions dc/web-frontend

Answer

oc log rollout dc/web-frontend

Question 10

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

Accepted Answer

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

Answer

Route

Answer

DeploymentConfig

Answer

BuildConfig

Question 11

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?

Accepted Answer

Source-to-Image (S2I) strategy. 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.

Answer

Docker strategy

Answer

Custom strategy

Answer

Pipeline strategy

Question 12

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?

Accepted Answer

helm template my-release my-chart. '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.

Answer

helm dry-run my-release my-chart

Answer

helm show chart my-chart

Answer

helm inspect values my-chart

Question 13

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?

Accepted Answer

Using build secrets mounted via the source secret or build strategy configuration. 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.

Answer

Storing them in an ImageStream annotation

Answer

Defining them as plain environment variables in the BuildConfig spec

Answer

Injecting them via the Route host header

Question 14

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?

Accepted Answer

Using an OpenShift Route with weighted backend services pointing to stable and canary Services. 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.

Answer

Setting the traffic-split annotation on the Deployment resource

Answer

Configuring weight parameters directly in the Deployment spec rollingUpdate strategy

Answer

Enabling canary mode in the ImageStream tag metadata

Question 15

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?

Accepted Answer

helm list. 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.

Answer

helm get releases

Answer

helm status

Answer

helm search installed