Google PCA Practice Question: Managing Implementation and Ensuring Solution and Operations Reliability

Your company wants to implement a canary deployment for a microservice running on GKE. You need to gradually shift traffic from the stable version to the canary version while monitoring error rates. Which THREE components or practices should you use? (Choose 3)

⚠ Common exam trap

PCA often tests the confusion between feature flags and canary deployments; candidates pick feature flags because they sound like gradual rollout, but feature flags do not shift traffic between deployed versions.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Cloud Deploy with an automated canary strategy and verification

Option A is correct because Cloud Deploy natively supports canary deployment strategies with configurable phases (for example, 50% then 100%) and automated verification that can advance or halt a rollout based on analysis results. Option B is correct because Cloud Monitoring collects the error-rate metrics (such as HTTP 5xx ratios from the service) that Cloud Deploy's verification step or alerting policies use to detect failures and trigger a rollback. Option E is correct because Istio on GKE provides fine-grained traffic splitting via VirtualService weights, letting you shift a precise percentage of requests from the stable to the canary version while observing behavior. Option C is not appropriate because Cloud CDN caches responses at the edge and does not perform version-based traffic shifting or canary analysis. Option D is not appropriate because feature flags toggle functionality inside a single deployed version and do not by themselves implement gradual traffic shifting between two separately deployed versions.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Cloud Deploy with an automated canary strategy and verification
Why this is correct
Cloud Deploy's automated canary strategy progressively shifts traffic percentages between GKE revisions and runs verification steps, halting or rolling back when analysis fails. It directly provides the staged rollout and metric-gated promotion the scenario demands.
✓
Cloud Monitoring to track error rates and trigger rollback
Why this is correct
Cloud Monitoring supplies the error-rate metrics that Cloud Deploy's verification step evaluates, and its alerting can trigger rollback when thresholds breach. This satisfies the requirement to monitor error rates continuously and revert automatically during the canary rollout.
✗
Cloud CDN for caching responses
Why it's wrong here
Cloud CDN caches responses at the edge; it neither splits traffic between revisions nor reports application error rates. It is correct for reducing origin load and latency on static or cacheable content, not for weighted canary routing, which needs GKE Ingress or a service mesh.
✗
Feature flags in the application code
Why it's wrong here
Feature flags toggle code paths inside one deployed revision; they do not shift traffic between two separately deployed versions, which is what canary requires. Flags suit progressive feature rollout or kill switches, whereas canary needs weighted routing across distinct revisions.
✓
Istio for traffic splitting between versions
Why this is correct
Istio's VirtualService and DestinationRule resources let you weight traffic between the stable and canary Kubernetes services, shifting percentages incrementally. This satisfies the gradual traffic-shift constraint directly, while Envoy sidecars expose per-version error metrics for monitoring, enabling automated rollback if the canary degrades.

Go deeper

Google PCA Practice Question: Managing Implementation and Ensuring Solution and Operations Reliability

Why each option matters

Option-by-option breakdown

Related to this question