Cloud Native Application Delivery

A platform team wants to adopt GitOps for cluster configuration. Which statement best captures the defining principle that distinguishes GitOps from other delivery approaches?

• AA Git repository holds the declared desired state, and an in-cluster agent continuously reconciles the running state to match what is committed.check_circle Correct
• BA CI server holds the authoritative configuration and issues kubectl apply commands to the cluster whenever a build succeeds.
• CDevelopers connect to the cluster with kubectl and make live changes directly, then export the result back into a Git repository as a backup.
• DContainer images are signed and stored in a registry, and the cluster pulls the newest image tag on a fixed schedule regardless of any repository.

Why A is correct: This is correct because GitOps uses a versioned declarative source of truth in Git and a reconciliation agent that continuously converges actual cluster state towards the committed desired state.

Why B is wrong: This is tempting because CI pipelines do deploy to clusters, but it describes a push model where an external system imperatively applies changes rather than a Git repository being the declarative source of truth that the cluster reconciles against.

Why C is wrong: This inverts the flow and is tempting because it involves Git, but here Git is a passive backup rather than the authoritative source, so live manual edits are the real source of truth, which GitOps forbids.

Why D is wrong: This is tempting because it uses the word pull, but it describes image polling, not reconciliation of declared manifests from Git, and it ignores the declarative desired-state repository entirely.

A stateless API depends on an external cache. When the cache becomes briefly unavailable, each API Pod cannot serve correct responses, but it recovers on its own once the cache returns and should not be restarted in the meantime. During the outage the team wants Kubernetes to stop sending client traffic to the affected Pods and then resume automatically once they are healthy again. Which probe produces this behaviour?

• AA liveness probe, so the kubelet restarts each affected Pod until the cache dependency comes back
• BA readiness probe, so each affected Pod is removed from the Service endpoints until it can serve againcheck_circle Correct
• CA startup probe, so traffic is withheld from each Pod for the duration of the cache outage
• DA liveness probe with a high failure threshold, so traffic pauses without an immediate restart

Why A is wrong: A liveness probe is tempting because it also reacts to unhealthy state, but a failing liveness probe restarts the container, which is the wrong response for a Pod that recovers on its own.

Why B is correct: A failing readiness probe takes the Pod out of the Service's endpoint set without restarting it, so traffic stops during the outage and resumes automatically once the probe passes again.

Why C is wrong: A startup probe only governs the one-time initial boot window of a container and plays no role in ongoing traffic decisions during a later dependency outage.

Why D is wrong: Raising the failure threshold only delays the restart; a liveness probe still ultimately restarts the container and never controls Service endpoint membership or traffic routing.

A team releases a new version by initially routing only about 5 percent of live traffic to it while the remaining 95 percent keeps hitting the stable version, watching error rates before shifting more traffic across. Which deployment strategy does this describe?

• ABlue-green, keeping two complete environments and cutting all traffic over in a single switch.
• BCanary, sending a small slice of traffic to the new version and expanding it as confidence grows.check_circle Correct
• CRecreate, stopping all old Pods and then starting the new Pods once the old ones are gone.
• DRolling update, swapping Pods a few at a time until every Pod runs the new version.

Why A is wrong: This is tempting because both limit blast radius, but blue-green moves all traffic at once rather than routing a small percentage to the new version first.

Why B is correct: This is correct because canary exposes the new version to a limited traffic percentage first, letting the team observe behaviour before increasing the share.

Why C is wrong: This is plausible as a valid strategy name, but Recreate replaces everything with downtime and does no gradual traffic splitting at all.

Why D is wrong: This is tempting because it also updates gradually, but it replaces Pods incrementally rather than deliberately steering a fixed small share of traffic for evaluation.

A platform team wants to define their build-and-test pipelines as Kubernetes custom resources, where each individual step runs in its own container as a Pod on the cluster, composed into reusable Tasks and Pipelines. Which tool provides this Kubernetes-native pipeline model?

• AArgo CD, which continuously syncs the cluster to manifests stored in a git repository.
• BHelm, which packages and templates Kubernetes manifests into versioned, releasable charts.
• CPrometheus, which scrapes and stores time-series metrics from instrumented targets.
• DTekton, which models pipelines as custom resources and runs each step in its own container.check_circle Correct

Why A is wrong: Tempting because Argo CD is a popular delivery tool in the same ecosystem, but it is a GitOps deployment controller that reconciles declared state, not a pipeline engine that runs build-and-test steps as Tasks.

Why B is wrong: Tempting because Helm is central to delivery, but it is a packaging and templating tool for deploying applications, not a system for running containerised pipeline steps.

Why C is wrong: Tempting because Prometheus appears throughout cloud native toolchains, but it is a monitoring system and has no role in defining or running CI/CD pipeline steps.

Why D is correct: Correct because Tekton is a Kubernetes-native pipeline framework whose Tasks and Pipelines are custom resources, executing each step in its own containerised Pod on the cluster.