Post Rollback System State And Root Cause Analysis

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A business-critical microservices application deployed across Google Kubernetes Engine (GKE) and managed with Cloud Service Mesh recently experienced significant latency degradation and an elevated rate of HTTP 5xx responses following a new release rollout. The automated deployment pipeline executed a rollback to restore the previous stable application revision.

To verify service functionality and performance metrics post-rollback, determine the incident's root cause, and establish preventive measures for future deployment strategies, what should the SRE team do?

Purge all historical telemetry in Cloud Logging sinks to minimize storage overhead, execute a synthetic load test at 200% peak capacity against the rolled-back pods, and redeploy the failed revision immediately with disabled timeout thresholds.

Request a quota increase for Global internal traffic director backend services in the fleet project, set all ServiceEntry resolution fields to DNS_ROUND_ROBIN, and restart all GKE cluster worker nodes simultaneously.

Verify baseline recovery across golden signals (error rates, latency, and inter-service round-trip times) in Cloud Monitoring, analyze Cloud Service Mesh access logs and distributed traces to isolate whether errors stemmed from backend application logic or proxy routing, and conduct a blameless post-incident review to document preventive action items.

Enable Binary Authorization breakglass overrides across all deployments, remove automated canary analysis gates from the deployment pipeline, and patch container images directly inside running pods using manual command-line overrides.

Professional Cloud DevOps Engineer

Post Rollback System State And Root Cause Analysis

Related questions