Google Cloud Professional Cloud Architect Analyzing and Optimizing Technical and Business Processes Syllabus

Analyzing and Optimizing Technical and Business Processes syllabus — full chapter and topic list

Expand any chapter to see its topics and sub-topics. This is the whole examinable outline for Analyzing and Optimizing Technical and Business Processes in Google Cloud Professional Cloud Architect, not a summary of it.

1. 1

   Software Development Lifecycle Optimization

   4 topics

   • CI/CD pipeline design
     • Cloud Build and Cloud Deploy
     • Artifact Registry
   • Testing strategies and environments
   • Release management and rollback strategies
     • Blue-green and canary deployments
   • Source control and trunk-based development
2. 2

   Business Continuity and Operations Processes

   4 topics

   • Disaster recovery testing and runbooks
   • Incident response and escalation processes
   • Change management practices
   • Capacity and demand management
3. 3

   Team and Organizational Alignment

   4 topics

   • Roles, responsibilities, and skill mapping
   • Communication and stakeholder management
   • Decision-making and governance models
   • DevOps and SRE cultural adoption
4. 4

   Cost Governance and Process Improvement

   4 topics

   • Billing accounts and budget alerts
     • Billing exports to BigQuery
   • Cost allocation with labels and projects
   • FinOps practices and showback/chargeback
   • Continuous process optimization

Analyzing and Optimizing Technical and Business Processes flashcards for Google Cloud Professional Cloud Architect

20 of 52 cards from the Analyzing and Optimizing Technical and Business Processes deck — real questions with worked answers.

1. What is a CI/CD pipeline, and what do the abbreviations CI and CD stand for?

   An automated workflow that builds, tests, and deploys code changes. CI = Continuous Integration (frequently merging and automatically testing code); CD = Continuous Delivery (always keeping code in a deployable state) or Continuous Deployment (automatically releasing every passing change to production).

2. What is the difference between Continuous Delivery and Continuous Deployment?

   In Continuous Delivery, every change is automatically built and tested and is ready to release, but the final push to production requires a manual approval. In Continuous Deployment, every change that passes the pipeline is automatically released to production with no manual gate.

3. Which Google Cloud managed service provides serverless CI/CD build pipelines?

   Cloud Build — it executes builds as a series of steps in containers, can run tests, and deploy to targets like Cloud Run, GKE, and App Engine, triggered by source repository events.

4. In a CI/CD pipeline, what is an 'artifact' and where are container artifacts stored in Google Cloud?

   An artifact is the deployable output of a build (e.g., a compiled binary or container image). In Google Cloud, container images and language packages are stored in Artifact Registry (the successor to Container Registry).

5. Name the typical ordered stages of a standard CI/CD pipeline.

   Source (commit/trigger) → Build (compile/package) → Test (unit, integration) → Release/Artifact creation → Deploy (to staging/production) → Operate/Monitor.

6. What is the testing pyramid and what does it recommend?

   A model recommending many fast, cheap unit tests at the base, fewer integration/service tests in the middle, and a small number of slow, expensive end-to-end (UI) tests at the top — maximizing coverage while minimizing cost and flakiness.

7. Differentiate unit, integration, and end-to-end (E2E) tests.

   Unit tests verify a single function/component in isolation. Integration tests verify that multiple components work together (e.g., service + database). E2E tests verify the entire system from the user's perspective through the full stack.

8. What is the purpose of a staging environment, and how should it relate to production?

   Staging is a pre-production environment used to validate releases under realistic conditions before going live. It should mirror production as closely as possible (configuration, data shape, infrastructure) to catch issues early.

9. What is smoke testing?

   A shallow, broad set of tests run immediately after a build or deployment to confirm the most critical functions work — a quick 'is it on fire?' check before deeper testing or release.

10. What is canary testing/canary deployment?

    A release strategy that rolls out a new version to a small subset of users or servers first, monitors its health and metrics, and only proceeds to a full rollout if the canary performs well — limiting blast radius.

11. Compare blue-green deployment with a rolling deployment.

    Blue-green keeps two full environments (blue=current, green=new); traffic is switched all at once to green, enabling instant rollback by switching back. A rolling deployment gradually replaces instances of the old version with the new one, using fewer resources but with slower rollback.

12. What is a feature flag (feature toggle) and why is it useful for release management?

    A runtime switch that enables or disables a feature without redeploying code. It decouples deployment from release, supports gradual rollout, A/B testing, and lets you instantly disable a problematic feature (kill switch).

13. What is a rollback strategy and what are two common ways to roll back a release?

    A predefined plan to revert to a known-good state when a release fails. Common methods: (1) redeploy the previous artifact/version, and (2) switch traffic back (e.g., blue-green flip or revert a canary), optionally combined with database migration reversals.

14. What is the difference between a backward-compatible (forward-compatible) schema change and why does it matter for safe rollbacks?

    A backward-compatible change lets both old and new code work with the same database schema (e.g., adding nullable columns rather than dropping them). It matters because it allows you to roll back application code without breaking the database, enabling safe, reversible deployments.

15. What is trunk-based development?

    A source-control practice where all developers commit to a single shared branch ('trunk'/main) frequently (at least daily), using short-lived branches or none, keeping the trunk always releasable and avoiding long-lived divergent branches.

16. Contrast trunk-based development with GitFlow.

    Trunk-based uses one main branch with very short-lived branches and frequent integration, favoring CI/CD. GitFlow uses multiple long-lived branches (develop, release, feature, hotfix, main) with structured merges, which adds isolation but increases merge complexity and slows integration.

17. In source control, what is the difference between merge and rebase?

    Merge combines branches and preserves history by creating a merge commit, keeping the original branch structure. Rebase replays your commits on top of another branch, producing a linear history but rewriting commit hashes.

18. What problem do short-lived feature branches solve compared to long-lived branches?

    They reduce merge conflicts and integration risk ('merge hell') by integrating small changes frequently, keeping the codebase continuously tested and deployable rather than accumulating large, divergent changes.

19. What is a disaster recovery (DR) runbook?

    A documented, step-by-step procedure describing exactly how to detect, respond to, and recover from a specific disaster scenario, including roles, commands, decision points, and validation steps to restore service.

20. Define RTO and RPO.

    RTO (Recovery Time Objective) = the maximum acceptable time to restore service after an outage. RPO (Recovery Point Objective) = the maximum acceptable amount of data loss measured in time (how far back the last usable backup must be).

See more Analyzing and Optimizing Technical and Business Processes flashcards →

Planning Analyzing and Optimizing Technical and Business Processes for Google Cloud Professional Cloud Architect

Analyzing and Optimizing Technical and Business Processes (Google Cloud Professional Cloud Architect) FAQ