Analyzing and defining technical processes

Saltmarsh Energy manages its VPC networks, Cloud SQL instances and GKE clusters with Terraform modules stored in a shared repository. Last month a module change that passed code review deleted a production subnet when it was applied. The platform team wants to prove that a module change works on real Google Cloud resources before any team uses the new module version in production.

What should you recommend?

1. ARequire two reviewers instead of one on every pull request to the module repositoryMore reviewers reduce human error a little, but a reviewer reading code still cannot prove how the module behaves against the real Google Cloud APIs.
2. BRun terraform validate in the pipeline before each production applyterraform validate checks syntax and internal consistency only. It never calls the provider APIs, so it would not have shown the subnet deletion.
3. CApply module changes to production during a maintenance window so that problems can be rolled back quicklyTesting in production during a window still exposes production to the failure. Rollback of a deleted subnet and its dependent resources is slow and risky.
4. DAdd integration tests that deploy each module example into an isolated test project, check the created resources, and then destroy them, and run these tests in CI on every module changeIntegration tests that create, verify and destroy real resources in a disposable project prove module behavior against the actual APIs without touching production. Running them in CI makes the check automatic.

Kestrel Payments builds a container image for its checkout service with Cloud Build and releases it to three GKE clusters named dev-gke, stage-gke and prod-gke. The team uses a Cloud Deploy delivery pipeline with one target per cluster. Compliance requires that a named release manager approves every rollout to production, while dev and staging rollouts must stay fully automatic.

What should you do?

1. AAdd a manual approval step to the Cloud Build trigger that creates the releaseBuild approval gates the creation of the release for every environment, so dev and staging would also wait for a human, which breaks the requirement.
2. BCreate a separate delivery pipeline for production that only the release manager can runA separate pipeline breaks the single promotion path, so the same release is no longer promoted through dev and staging into production in one tracked flow.
3. CSet requireApproval to true on the prod-gke target and grant the release manager the Cloud Deploy Approver roleCloud Deploy supports approval on individual targets. Rollouts to prod-gke wait in a pending approval state until someone with the clouddeploy.approver role approves them, while the other targets roll out automatically.
4. DGive the release manager the Kubernetes Engine Admin role on prod-gke and remove Cloud Deploy access for everyone elseRestricting cluster access does not create an approval record for each rollout and stops the pipeline from deploying to production at all.

Elmstead Insurance runs a quote service made of eight microservices on GKE. Users report that about 5 percent of quote requests take more than 8 seconds, while the average latency on the dashboard looks normal. Each team insists its own service is fast, and the logs of each service show no errors.

What should you do first to find the root cause?

1. ADouble the number of replicas for every microserviceAdding capacity without evidence may hide the symptom temporarily and adds cost, but it does not identify which call is slow.
2. BRestart all pods in the cluster during a quiet periodRestarting is a mitigation step that destroys the state you need to investigate, and an intermittent latency issue is likely to return.
3. CAsk each team to add more log lines to its serviceMore logs per service still do not connect one request across eight services, so the slow hop remains hard to find.
4. DInstrument the services for distributed tracing with OpenTelemetry, send traces to Cloud Trace, and examine the slow requests to see which span adds the latencyDistributed tracing follows a single request through every service and shows the time spent in each span, which identifies the slow dependency for the tail requests that averages hide.

Marlowe Games deploys its matchmaking service to Cloud Run in three projects: dev, staging and prod. Today Cloud Build rebuilds the container image separately for each environment, and twice a release that passed staging failed in production because a dependency changed between builds. The team also wants production releases to reach a small share of users first and to roll back quickly if errors rise.

Which two actions should you perform? Each correct answer presents part of the solution.

1. ABuild the image once per commit, store it in Artifact Registry, and promote the same image digest through dev, staging and prod with Cloud DeployBuilding once and promoting the same immutable digest guarantees that production runs exactly what was tested in staging, which removes the drift caused by rebuilding.
2. BKeep separate builds per environment but set the base image tag to latest in each DockerfileThe latest tag is mutable, so separate builds can still pull different content, and the root cause of drift remains.
3. CLet developers deploy to production from their workstations with gcloud run deploy when a hotfix is urgentManual deployments bypass the pipeline, its tests and its audit trail, and make the environments drift further apart.
4. DConfigure a canary deployment strategy in the Cloud Deploy pipeline for the prod target, sending a small percentage of traffic to the new revision before full rolloutCloud Deploy canary deployments for Cloud Run shift traffic in percentages to the new revision, so a bad release affects only a small share of users and can be rolled back.
5. ERun the staging tests against the dev image so that staging can be removedRemoving an environment reduces confidence before production and does not address the dependency drift or the need for gradual rollout.