Analyzing and optimizing technical and business processes · Topic 2 of 4
Troubleshooting, Service Catalogs and Disaster Recovery
Root cause analysis with Google Cloud tools, self-service provisioning from approved templates, and how to plan and then test disaster recovery.
- 4 min
- Start with what changed; use audit logs for who and when.
- Trace for slow calls, Profiler for CPU, Query insights for database load, Connectivity Tests for reachability.
- Service catalogs give self-service with guardrails.
What it is
Three technical processes keep systems healthy over time: troubleshooting finds why something broke, service catalogs let teams provision approved infrastructure without tickets, and disaster recovery plans and tests how the business recovers from major failures.
How it works
Root cause analysis best practices
- Define the symptom precisely: which users, which requests, since when.
- Look for recent changes: deployments, configuration changes in Admin Activity audit logs.
- Narrow the scope with metrics, logs and traces before guessing.
- Test one hypothesis at a time.
- Fix, verify and record in a blameless postmortem with owned action items.
Matching the tool to the question
| Question | Tool |
|---|---|
| Who changed which resource, when? | Admin Activity audit logs in Logs Explorer |
| Which downstream call got slower? | Cloud Trace (with OpenTelemetry instrumentation) |
| Which function uses the CPU? | Cloud Profiler |
| Which database statements generate load? | Query insights for Cloud SQL (and similar insights for Spanner and AlloyDB) |
| Why can this host not reach that VM? | Connectivity Tests in Network Intelligence Center |
| Which exceptions are new? | Error Reporting |
| Is a Spanner or Bigtable key range hot? | Key Visualizer |
| Load balancer error details | Load balancer logs with status details |
Look at what changed before deep analysis. Many incidents follow a deployment or a configuration change minutes earlier.
Service catalog and provisioning
A service catalog offers teams approved, pre-built solutions (for example Terraform modules, Infrastructure Manager deployments or project templates) that include security, networking and labeling standards. Teams provision on their own, and the platform team keeps control over what "approved" means.
| Benefit | Why it matters |
|---|---|
| Consistency | Every environment uses the same tested building blocks |
| Speed | No ticket queue for standard requests |
| Compliance | Guardrails are built into the templates |
| Cost control | Approved sizes and labels for chargeback |
Combine the catalog with organization policies so that anything built outside it still meets the rules.
Disaster recovery planning
| Step | Content |
|---|---|
| Business impact analysis | Which services matter, their RTO and RPO |
| Choose a pattern per service | Backup and restore, warm standby, or active-active |
| Automate recovery | Infrastructure as code, runbooks as workflows, data replication |
| Test regularly | Planned failovers and restore drills; a plan never tested is not a plan |
| Review after changes | New services or regions need updated plans |
Google Cloud building blocks:
| Need | Building block |
|---|---|
| Restore GKE configuration, Secrets and volumes in another region | Backup for GKE |
| Back up VMs and databases centrally | Backup and DR Service |
| Database recovery in another region | Cross-region replicas, Spanner multi-region |
| Object data across regions | Dual-region or multi-region buckets |
| Recreate infrastructure | Terraform from Git |
Disaster recovery for a regional outage needs resources (or the ability to create them quickly) in another region. Zone-level redundancy alone does not help.
How the exam asks about this
- "Which principal changed which resource in the 30 minutes before errors, using data already recorded?" Admin Activity audit logs.
- "Latency doubled, CPU flat, three downstream calls." Instrument with OpenTelemetry and compare spans in Cloud Trace.
- "Kubernetes configuration, Secrets and volumes recoverable in another region in four hours, no backup software to run." Backup for GKE.
What to remember for the exam
- Start with what changed; use audit logs for who and when.
- Trace for slow calls, Profiler for CPU, Query insights for database load, Connectivity Tests for reachability.
- Service catalogs give self-service with guardrails.
- DR: business impact analysis, a pattern per service, automation and regular tests.
- Backup for GKE and Backup and DR Service are managed options.
Postmortems should be blameless and end with owned, tracked actions, or the same outage returns.
Common mistakes
Resizing first, measuring later. Find the heavy statements before buying a bigger instance.
Untested DR plans. Restores fail in ways nobody predicted.
Asset history to name who made a change. It shows what changed, not who.
Check yourself
Which tool shows the route or firewall rule blocking traffic between two endpoints?
Connectivity Tests in Network Intelligence Center.
What is the first output of disaster recovery planning?
A business impact analysis with RTO and RPO per service.
What does a service catalog give development teams?
Self-service provisioning of approved, pre-built solutions with built-in standards.
Topic 2 of 4 in Analyzing and optimizing technical and business processes
Test yourself on Analyzing and optimizing technical and business processes
The full Google Cloud Professional Cloud Architect question bank has 877 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.