Task 4.1: Analyzing and defining technical processes.

• ADaily automated Cloud SQL backups, restored into the DR region when the primary region fails

  Incorrect

  A daily backup can be almost a day old when the region fails, far beyond a 15-minute RPO.

• BA move of the order database to a Spanner instance with a multi-region configuration

  Incorrect

  Spanner's synchronous replication gives an even smaller RPO, but it means a database migration and a costlier service than the target calls for.

• CA Cloud SQL high-availability configuration that spans two zones of the existing region

  Incorrect

  The standby sits in the same region, so it protects against a zone failure, not the loss of the whole region.

• DA cross-region Cloud SQL read replica, promoted to a primary if the region fails

  Correct

  The replica stays close behind the primary in another region and can be promoted to take over when the primary's region becomes unavailable.

Match the data protection to the RPO. Continuous asynchronous replication to a cross-region replica keeps the loss window to minutes at the price of one replica, while daily backups lose too much and in-region HA does not survive a regional outage.

• AKeep the reviews and action items, and focus them on systemic causes and process gaps rather than on individuals

  Correct

  The framework asks for a blameless culture that looks for learning and systemic issues, so people report what happened without fear.

• BKeep the reviews and action items, and record in each report which engineer caused the outage

  Incorrect

  Naming a culprit is the blame that makes engineers hide details, and it leaves the systemic causes unexamined.

• CKeep the reviews and action items, but skip the interviews and build the timeline from logs alone

  Incorrect

  The framework has the review gather information through interviews as well as documents; logs alone miss the decisions people made.

• DKeep the reviews and action items, but hold them as a management meeting and send the results to the engineers

  Incorrect

  A review needs a multidisciplinary team with expertise in the incident; excluding the engineers loses what they know.

The reviews already exist; their culture is the problem. The operational excellence pillar calls for a multidisciplinary, blameless post-incident review that identifies the immediate cause and the systemic issues, so that people report incidents without fear of retribution.

• AA terraform fmt step that checks the formatting of the configuration files

  Incorrect

  terraform fmt checks code style; it does not evaluate what the change would create.

• BA gcloud beta terraform vet step that checks each plan against the policies

  Correct

  terraform vet checks a Terraform plan against constraint policies and can halt the deployment before the change reaches production.

• CCloud Asset Inventory feeds that report resources after they are changed

  Incorrect

  Feeds report changes after they happen, which is too late to stop a violation.

• DA manual approval step in the pipeline before each terraform apply

  Incorrect

  A reviewer can stop a change, but people reading plans do not reliably check every resource against every rule.

Testing and validating infrastructure belongs in the pipeline. Policy validation of the plan catches violations before apply, and the same constraints can be enforced elsewhere.

• ACloud Asset Inventory searches across the whole organization's projects

  Incorrect

  Asset Inventory finds existing resources; it does not provide deployable architectures.

• BOrganization policy constraints on each team's folder

  Incorrect

  Constraints block what is not allowed, but they give teams nothing to deploy.

• CApplication Design Center templates shared from a central catalog

  Correct

  Platform teams create and share policy-aligned templates in App Design Center, and developers deploy from that catalog themselves.

• DGemini Cloud Assist chat in each team's console

  Incorrect

  A chat assistant answers each team's questions, but it is not a governed catalog of approved designs to deploy from.

A service catalog turns approved patterns into self-service. App Design Center's shared templates carry the organization's standards into every deployment made from them.

• AFirewall Insights for the firewall rules in the project

  Incorrect

  Firewall Insights reports on rule usage, such as shadowed or unused rules; it does not record who changed a rule.

• BVPC Flow Logs for the subnet where the application's VMs run

  Incorrect

  Flow logs sample network flows to and from VMs; they show traffic, not configuration changes or who made them.

• CAdmin Activity audit logs, searched in the Logs Explorer

  Correct

  Admin Activity audit logs record configuration changes to resources, including the principal and time, and they are always written.

• DLogging turned on for the firewall rule that is under suspicion

  Incorrect

  Rule logging records the connections a rule matches from now on, not past changes to the rule itself.

Root cause analysis of a configuration change starts with the audit trail. Admin Activity audit logs capture who modified which resource and when, and they cannot be disabled, so the record of last night's change already exists.

• AHold the change advisory board twice a week instead of weekly

  Incorrect

  More meetings shorten the queue a little but keep approval with people far from the change.

• BReplace board approval with peer review of each change in the pipeline

  Correct

  DORA's research favors replacing heavyweight change approval with peer review, for a reliable, compliant release process without losing speed.

• CBundle the queued changes into one monthly release for the board

  Incorrect

  Larger batches lengthen lead times and feedback loops, which works against working in small batches.

• DAdd a second board sign-off for changes that touch the database

  Incorrect

  Another external approval adds delay without the context of someone who reviewed the code.

Software delivery improves with small batches and fast feedback. Streamlining change approval, with peer review built into the delivery pipeline instead of a distant board, keeps changes small and still gives a reviewed, auditable record.

• AA nightly Cloud Build run against the main branch of the repository

  Incorrect

  A nightly build finds problems only after they have been merged.

• BA Cloud Build trigger on pull requests that runs the tests and the build

  Correct

  Cloud Build triggers start a build automatically on repository events, such as a pull request, and report the result back to the repository.

• CA Cloud Deploy pipeline that promotes each merged commit to staging

  Incorrect

  Cloud Deploy handles delivery of releases; it does not test pull requests before merge.

• DA checklist that each developer must fill in before opening a pull request

  Incorrect

  A manual checklist is the process that is already failing.

Continuous integration means every change is built and tested automatically before it joins the main line, which is what pull request triggers provide.

• ATurn on VPC Flow Logs for the subnet behind the load balancer's forwarding rule

  Incorrect

  Flow logs record VM network flows; they do not explain HTTP responses from the proxy.

• BAdd Cloud Armor rules to block the clients that receive 502s

  Incorrect

  Blocking clients hides the symptom and does not explain the errors.

• CEnable backend service logging and read the statusDetails field

  Correct

  Load balancer log entries include a statusDetails field that explains why the load balancer returned a given status code, such as a failed backend connection.

• DScale the backend instance group to twice its current size

  Incorrect

  Adding capacity guesses at a cause before the cause is known.

Root cause analysis starts with evidence from the component that produced the error. Here the load balancer generated the 502, so its own logs say why.