EX280 Application Deployment And Lifecycle Practice Test 5 — 15 Questions

Question 1

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

Accepted Answer

-o yaml. 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.

Answer

--format yaml

Answer

--yaml

Answer

-f yaml

Question 2

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

Accepted Answer

Temporary service outage. 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.

Answer

Zero downtime deployment

Answer

Rolling update

Answer

Instant switch

Question 3

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?

Accepted Answer

Pod anti-affinity. 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.

Answer

Tolerations

Answer

Node selector

Answer

Resource quotas

Question 4

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

Accepted Answer

Builds the application artifacts. 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.

Answer

Sets up the user environment

Answer

Starts the application

Answer

Downloads the base image

Question 5

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

Accepted Answer

Sending a HTTP POST to the webhook URL. 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.

Answer

Restarting the OpenShift cluster

Answer

Updating a ConfigMap

Answer

Changing a Namespace

Question 6

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

Accepted Answer

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

Answer

External Load Balancer

Answer

A pre-existing Database

Question 7

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

Accepted Answer

In the BuildConfig resources field. 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.

Answer

In the LimitRange

Answer

In the project Quota

Answer

In the Deployment object

Question 8

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

Accepted Answer

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

Answer

Pod

Answer

ImageStream

Answer

Service

Question 9

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?

Accepted Answer

BuildConfig Webhook and ImageStream triggers. 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.

Answer

Only cron jobs

Answer

Manual build and manual rollout

Answer

DeploymentConfigs only

Question 10

Which THREE components are part of a Kustomize configuration?

Accepted Answer

kustomization.yaml. 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.

Answer

BuildConfigs

Answer

Helm Charts

Question 11

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

Accepted Answer

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

Answer

Parallel

Answer

Sequential

Answer

Canary

Question 12

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

Accepted Answer

Repository Name. 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 `, allowing you to reference the repo later (e.g., `helm install mychart /`). 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.

Answer

Chart version

Answer

Username

Answer

Namespace

Question 13

Which THREE pieces of data can an ImageStream reference?

Accepted Answer

Internal registry image. 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.

Answer

Git repository

Answer

DeploymentConfig

Question 14

Which THREE items are contained within a Helm Chart structure?

Accepted Answer

values.yaml. 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.

Answer

Dockerfile

Answer

ImageStream

Question 15

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

Accepted Answer

oc describe deployment. 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.

Answer

oc rollout undo

Answer

oc delete project

Answer

oc start-build