Application Deployment And Lifecycle practice questions

In the ImageStream tag policy

Why it fails: ImageStream tag policies manage import behaviors, not build-time registry credentials.

In the Route resource annotations

Why it fails: Routes only handle external ingress traffic routing.

In the global cluster OAuth configuration

Why it fails: OAuth configuration handles user authentication to the OpenShift web console and API, not container registry pulls.

In the OAuth client definition

Why it fails: OAuth clients are for user authentication tokens, not container image registry trust.

In the individual BuildConfig strategy environment variables

Why it fails: Registry TLS trust cannot be bypassed via BuildConfig environment variables.

In the Project request template metadata

Why it fails: Project request templates define default resources created when a new project is provisioned, not cluster-wide container runtime trust.

The cluster-wide storage class definitions

Why it fails: Storage classes manage persistent volume provisioning, which is unrelated to build execution logic.

The default OAuth client secret

Why it fails: OAuth client secrets handle API authentication and do not affect build execution.

BlueGreen

Why it fails: BlueGreen is not a native single-strategy type in standard Deployment specs.

Canvas

Why it fails: Canvas is not a deployment strategy.

oc get events --sort-by='.metadata.creationTimestamp'

Why it fails: Event logs are useful, but require filtering to find the specific deployment failure events.

oc describe deployment <deployment-name>

Why it fails: While 'oc describe' shows events, 'oc rollout status' is specifically designed to track rollout progress and blockages.

oc debug deployment/<deployment-name>

Why it fails: 'oc debug' is used for troubleshooting running pods, not for checking rollout progression states.

oc adm helm install my-release private-repo/chart-name

Why it fails: 'oc adm helm' is not a valid subcommand in OpenShift 4.

oc create helmchart --name=my-release --source=private-repo

Why it fails: OpenShift does not have a 'create helmchart' subcommand.

oc new-app --helm-chart=private-repo/chart-name

Why it fails: 'oc new-app' does not natively accept raw Helm chart references directly from private repositories without operator backing.

oc diff -f kustomization.yaml

Why it fails: 'oc diff' compares live cluster state against manifests, but requires rendered output when using Kustomize overlays.

oc convert -k .

Why it fails: 'oc convert' is used for converting API versions, not for building Kustomize targets.

oc apply -k . --dry-run=client

Why it fails: While 'oc apply -k' with dry-run works, 'oc kustomize' is specifically built to output the rendered Kustomize overlay directly.

Route health-check trigger

Why it fails: Routes handle incoming traffic routing and do not trigger builds.

CronJob schedule trigger

Why it fails: CronJob triggers are managed by Kubernetes CronJob objects, not natively inside BuildConfig triggers.

In the global cluster proxy configuration under spec.trustedCA.

Why it fails: The global cluster proxy handles cluster-egress traffic routing, but S2I builds use specific build config CA configuration.

In the Node configuration file on each worker node under /etc/origin/node/.

Why it fails: Node configuration files do not control container build-time trust stores directly in OpenShift 4.

In the imagestream spec.trust.ca field.

Why it fails: ImageStreams do not contain a trust.ca field.

Change the build strategy to Docker

Why it fails: Changing the strategy does not fix the underlying registry permission issue.

Make the ImageStream public

Why it fails: This is not a configurable setting and is insecure.

Create an ImagePullSecret for the ServiceAccount

Why it fails: While possible, assigning roles via RBAC is the standard OpenShift way for internal registry images.

In the DeploymentConfig

Why it fails: Deployments do not define build logic.

In the Build object

Why it fails: The Build object is the result of the BuildConfig, it does not define the source.

In the ImageStream

Why it fails: ImageStreams only track image metadata.

Hardcode credentials in the Dockerfile

Why it fails: Hardcoding credentials in the Dockerfile exposes them in image layers and source control, and OpenShift cannot use them for registry authentication during the build. It is tempting because it appears to make credentials available, and would be correct only if security and auditability were irrelevant.

Use an environment variable in the deployment

Why it fails: Deployment environment variables apply to the running pod, not the build process, so the build still cannot authenticate to the private registry. It is tempting because environment variables commonly pass configuration, and would be correct for supplying runtime settings to a deployed application rather than build-time registry credentials.

Mount a ConfigMap

Why it fails: A ConfigMap holds non-confidential configuration data, and OpenShift builds cannot read registry credentials from one, so authentication still fails. It is tempting because ConfigMaps do inject build settings, and would be correct for supplying ordinary configuration values rather than secret credentials.

startup-command

Why it fails: This is not a valid hook name.

init-container

Why it fails: While init-containers run before the app, deployment hooks are the 'lifecycle' answer.

post-deployment hook

Why it fails: This runs after the deployment is complete.

Manual

Why it fails: Manual is not an automatic trigger.

Cron

Why it fails: Not a native trigger type.

Webhook

Why it fails: Webhooks are for builds.

oc build logs

Why it fails: This is for builds, not deployments.

oc trigger

Why it fails: Not a valid command.

oc watch

Why it fails: Not a dedicated rollout command.

Custom

Why it fails: The Custom strategy allows you to provide your own deployment logic via a custom deployment image, but it requires additional implementation and does not inherently provide zero downtime. It is typically used for advanced scenarios like blue-green deployments, but it is not a built-in strategy and requires significant configuration. It is not the straightforward choice for zero downtime with standard strategies.

Blue-Green

Why it fails: Blue-Green is not a built-in deployment strategy in OpenShift DeploymentConfigs. It must be implemented manually or via a custom strategy, often using routes and services. While it can achieve zero downtime, it is not a selectable strategy in the DeploymentConfig specification. The question asks for a strategy that supports both Rolling and Recreate, implying a built-in choice.

Recreate

Why it fails: The Recreate strategy terminates all existing pods before creating new ones, resulting in downtime. It does not support zero downtime because there is a period when no pods are running. While it is simpler and avoids version conflicts, it is not suitable for applications requiring continuous availability. Therefore, it fails the zero-downtime requirement.

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

Why it fails: A Route provides external hostname access with edge TLS termination and depends on an existing Service named reports. It does not create the internal Service, does not produce the cluster-local DNS name, and uses port 8080 rather than the required port 80. This does not satisfy internal access by the specified DNS name.

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

Why it fails: This creates a Service but maps port 8080 to container port 8080, so clients would connect on 8080 instead of the required port 80. It also does not derive the pod selector automatically from the Deployment the way expose does, risking an empty endpoint set. The port mapping and selector handling both miss the requirement.

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

Why it fails: This command requires an existing Service named reports to expose, but none exists yet because the workload is a Deployment. It also creates a Route rather than a Service, which is for external HTTP access, not the required internal cluster DNS name. The syntax therefore does not match the scenario's need to create the internal Service.

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

Why it fails: The oc create job subcommand does not accept an --image flag; Jobs are normally created from a manifest or by other generators. Even though a Job is conceptually suited to run-to-completion work, this specific command syntax fails. The correct concise approach here is creating a Pod with a Never restart policy.

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

Why it fails: Creating a Deployment establishes a controller that maintains a desired replica count, so the pod is recreated if it exits. A completed migration would be treated as a failed replica and restarted, causing the migration to run again. A Deployment is designed for continuous services, not for a single run-to-completion task.

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

Why it fails: A restart policy of Always causes the container to be restarted whenever it exits, so a migration that completes successfully would run again repeatedly. This is appropriate for long-running services, not one-off tasks. It therefore contradicts the requirement that the task must not be restarted after completion.

An ImageStreamTag trigger on the DeploymentConfig

Why it fails: Image change triggers cause a new rollout when a tracked image stream tag is updated; they automate deployment but do not split traffic between versions. The scenario concerns the Deployment API and controlled traffic, not automatic triggering on image updates. This feature does not direct a subset of requests to new pods.

A PodDisruptionBudget on the Deployment

Why it fails: A PodDisruptionBudget constrains voluntary disruptions such as node drains by requiring a minimum number of available pods. It governs availability during maintenance operations and has no role in directing or weighting traffic between old and new versions. It is unrelated to canary traffic distribution.

A NetworkPolicy that limits ingress to the new pods

Why it fails: A NetworkPolicy controls which sources may connect to selected pods at the network layer; it does not distribute or weight application traffic between versions. It could restrict who reaches the canary, but it cannot route a percentage of production requests to it. It therefore does not provide the traffic splitting the scenario requires.

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

Why it fails: oc update has no --revision flag and does not perform rollbacks; it would fail argument parsing. It is tempting because 'update' sounds like revision management, but oc update is for modifying object fields, whereas oc rollout undo restores the previous ReplicaSet revision.

oc revert deployment/my-app

Why it fails: No such subcommand exists; oc has no 'revert' verb for Deployments. It is tempting because 'revert' describes the desired outcome, and rollback tooling exists in other systems, but OpenShift performs this via oc rollout undo, which reads the DeploymentConfig or Deployment revision history.

oc rollback deployment/my-app

Why it fails: The oc rollback command was removed in OpenShift 4; rollouts are now managed through DeploymentConfig revision history or by rolling back a Deployment with oc rollout undo. It is tempting because it matches the older syntax, but it would be correct only on OpenShift 3 clusters.