Task 3.1: Application Delivery

• AmaxUnavailable set to 1 and maxSurge set to 0

  Incorrect

  This removes an old Pod before a new one exists, so availability drops to 3 during the rollout.

• BmaxUnavailable set to 0 and maxSurge set to 1

  Correct

  With no Pods allowed to be unavailable and one extra allowed, the controller starts a new Pod, waits for it to be ready, and only then removes an old one.

• CThe Recreate strategy instead of RollingUpdate

  Incorrect

  Recreate stops every old Pod before creating new ones, which causes downtime.

• DrevisionHistoryLimit set to 0

  Incorrect

  That only controls how many old ReplicaSets are kept for rollback; it has no effect on availability during a rollout.

maxUnavailable caps how many Pods may be missing and maxSurge how many may be added during a rolling update; 0 and 1 keep full capacity at the cost of one extra Pod.

• Akubectl rollout restart deployment/web

  Incorrect

  restart replaces the Pods but keeps the current, faulty version.

• Bkubectl scale deployment/web --replicas=0

  Incorrect

  Scaling to zero stops the errors by stopping the service entirely.

• Ckubectl delete deployment web and re-apply the old manifest

  Incorrect

  That causes downtime and needs the old manifest at hand, while a built-in rollback exists.

• Dkubectl rollout undo deployment/web

  Correct

  rollout undo rolls the Deployment back to its previous revision, reusing the old ReplicaSet.

Deployments keep their rollout history as old ReplicaSets, so a rollback to the last good revision is a single command.

• ABlue-green, bringing up the new Deployment and then switching the Service selector

  Correct

  Blue-green keeps two complete environments and switches traffic in one step; switching back is the same change in reverse.

• BA canary release that sends 5% of the traffic to the new version, then more

  Incorrect

  A canary runs both versions side by side and shifts traffic gradually, which the incompatible versions cannot tolerate.

• CA rolling update with maxSurge at 25% so new Pods start before old ones stop

  Incorrect

  A rolling update also mixes old and new Pods behind the Service while it progresses.

• DThe Recreate strategy, which stops the old Pods before starting the new ones

  Incorrect

  Recreate avoids mixing versions, but it removes the old Pods before the new ones are up and tested, so there is downtime and no ready fallback.

When versions cannot coexist and downtime is unacceptable, blue-green lets the new environment be prepared in full and receive the traffic all at once.

• AA CI pipeline that runs kubectl apply after each merge

  Incorrect

  A pipeline pushes changes when it runs; between runs nothing notices or reverts a manual change.

• BPackaging the manifests as a Helm chart in a chart repository

  Incorrect

  Packaging makes resources reusable and installable; it does not keep watching the cluster.

• CGitOps, using a tool such as Argo CD or Flux

  Correct

  GitOps continuously evaluates and reconciles the live state against the state defined in version control, which also undoes drift.

• DRecording every kubectl edit in a change ticket

  Incorrect

  Tickets document changes after the fact; they neither make Git the source of truth nor reconcile anything.

GitOps treats version control as the source of truth and uses automated reconciliation, typically by an in-cluster agent, to keep the live system in line with it.

• AHelm, with one chart and a different values file per environment

  Correct

  Helm manages packages of pre-configured resources called charts, and values let one chart render differently per environment.

• BA ConfigMap per environment that holds the replica count

  Incorrect

  A ConfigMap feeds configuration to containers; the Deployment's replica field does not read from it.

• CRunning kubectl scale by hand after each production deployment

  Incorrect

  Manual commands drift from the files and still leave the tag and labels unchanged.

• DKustomize, with a shared base and an overlay per environment

  Correct

  Kustomize adds, removes or updates configuration in manifests without templates, and kubectl applies it with -k.

• EA HorizontalPodAutoscaler with a different minReplicas per environment

  Incorrect

  An autoscaler adjusts replicas from metrics, but it cannot change the image tag or labels.

Helm and Kustomize both produce environment-specific manifests from one shared definition: Helm through templated charts and values, Kustomize through bases and overlays.

• ANothing; the kubelet pushes the new value into the running containers at its next sync

  Incorrect

  Periodic syncs refresh ConfigMaps mounted as volumes, not values already injected as environment variables.

• BRestart the Pods, for example with kubectl rollout restart, to load the new value

  Correct

  Environment variables are set when a container starts; ConfigMaps consumed as environment variables are not updated in running Pods.

• CMark the ConfigMap immutable so that its new value is enforced

  Incorrect

  Immutability blocks later changes to the ConfigMap; it does not deliver the new value.

• DDelete the ConfigMap and create it again under the same name

  Incorrect

  Recreating it does not touch the environment of containers that are already running.

Environment values are fixed for the life of a container, so a change reaches the application only through new Pods.

• AenvFrom with a configMapRef to the ConfigMap

  Correct

  envFrom defines all of a ConfigMap's data as container environment variables.

• Benv with one valueFrom entry per key

  Incorrect

  That works but lists every key by hand, which the team wants to avoid.

• CA volume mount of the ConfigMap at /etc/env

  Incorrect

  A volume mount gives files, not environment variables.

• DThe downward API with fieldPath set to the ConfigMap

  Incorrect

  The downward API exposes Pod fields, not ConfigMap data.

envFrom imports a whole ConfigMap as environment variables; env with valueFrom picks single keys.

• AInto the same ConfigMap as the other settings

  Incorrect

  A ConfigMap does not provide secrecy or encryption.

• BInto the container image at build time

  Incorrect

  Baking credentials into images exposes them to anyone who can pull the image.

• CInto a Secret, the rest into a ConfigMap

  Correct

  ConfigMaps hold non-confidential data and provide no secrecy; confidential values belong in Secrets.

• DInto an annotation on the Deployment object

  Incorrect

  Annotations are readable metadata, not a place for credentials.

Split configuration by sensitivity: ConfigMaps for ordinary settings, Secrets for credentials.

• AA CronJob for each step, timed so they do not overlap

  Incorrect

  Timed jobs do not express dependencies between steps.

• BOne Job whose script runs each step in turn

  Incorrect

  One script hides the steps from Kubernetes and loses per-step containers.

• CArgo, with its Kubernetes-native workflow engine

  Correct

  Argo provides Kubernetes-native tools to run workflows, among other things.

• DA Deployment with one init container per step

  Incorrect

  Init containers prepare a Pod; they do not form a pipeline with dependencies of its own.

Workflow engines such as Argo Workflows model steps and dependencies as containers on the cluster.

• Akubectl apply --dry-run=client -f manifests/

  Incorrect

  A client dry run only prints the objects locally; the cluster's admission never sees them.

• Bkubectl create --save-config -f manifests/

  Incorrect

  That creates the objects for real.

• Ckubectl explain on each kind in the manifests

  Incorrect

  explain documents fields; it validates nothing.

• Dkubectl apply --dry-run=server -f manifests/

  Correct

  A server dry run submits the request to the API server, including admission, without persisting the objects.

Server-side dry runs go through validation and admission, so they catch what the cluster would reject.