Domain 4: Analyzing and Optimizing Technical and Business Processes (~15%)

Domain 4 accounts for approximately 15% of the Professional Cloud Architect exam, translating to roughly 8-9 questions. This domain tests your ability to design CI/CD pipelines, analyze costs, make technology trade-off decisions, and build reliable systems using SRE principles. It bridges the gap between pure technical architecture (Domains 1-3) and real-world operational excellence. Expect scenario questions that require you to choose the right deployment strategy, justify a cost decision, or design a reliability workflow.

4.1 Analyzing and Defining Technical Processes

Software Development Lifecycle (SDLC) on GCP

The exam expects you to understand how development workflows map to GCP services across the full lifecycle. The canonical GCP CI/CD toolchain follows this flow:

Code → Cloud Source Repos / GitHub → Cloud Build (CI) → Artifact Registry → Cloud Deploy (CD) → GKE / Cloud Run

Cloud Build: Continuous Integration

Cloud Build is Google Cloud's fully managed CI/CD platform. It executes builds on Google's infrastructure, imports source code from repositories or Cloud Storage, and produces artifacts like Docker images or compiled binaries. Cloud Build aligns with SLSA level 3 requirements for supply chain security.

Build configuration is defined in cloudbuild.yaml (or JSON). Each build consists of ordered build steps, where each step runs as a Docker container instance. Steps communicate via a local Docker network named cloudbuild and share data through a persistent /workspace volume.

Key concepts:

Builder images: Cloud Build provides pre-built builder images (gcr.io/cloud-builders/*) for common tasks (docker, gcloud, npm, maven, gradle, kubectl). Standard Docker Hub images are also supported.

Exam trap: Cloud Build uses Docker engine to execute builds, but Cloud Build itself is not a Docker registry. Artifacts are pushed to Artifact Registry (not Container Registry, which is deprecated). If an exam question mentions storing container images, the answer is Artifact Registry.

Artifact Registry

Artifact Registry is the universal artifact management service, replacing the legacy Container Registry. It stores:

• Container images (Docker, OCI)
• Language packages (Maven, npm, Python, Go, NuGet)
• OS packages (Debian, RPM)
• Helm charts

Key features for the exam: regional and multi-regional repositories, IAM-based access control, vulnerability scanning via Artifact Analysis, and integration with Binary Authorization for deployment policy enforcement.

Exam trap: Container Registry (gcr.io) is deprecated. Always choose Artifact Registry ({region}-docker.pkg.dev) in exam answers. They are not the same service.

Cloud Deploy: Continuous Delivery

Cloud Deploy is a managed continuous delivery service that automates application delivery through a defined promotion sequence. It is not a CI tool -- it handles the CD side, taking built artifacts and deploying them through environments.

Core terminology:

Deployment flow:

1. CI pipeline (Cloud Build) creates a release referencing built artifacts
2. Cloud Deploy automatically rolls out to the first target (e.g., dev)
3. Operator promotes the release to subsequent targets (staging, production)
4. Each promotion creates a new rollout for that target
5. Targets with requireApproval block until an authorized user approves

Skaffold integration: Cloud Deploy uses Skaffold under the hood for manifest rendering and deployment execution. A skaffold.yaml is required alongside your Kubernetes manifests or Cloud Run service definitions.

Rollback: Revert by creating a new rollout against a previously successful release. Cloud Deploy does not perform in-place rollback -- it deploys the older release as a new rollout.

# Example delivery pipeline configuration
apiVersion: deploy.cloud.google.com/v1
kind: DeliveryPipeline
metadata:
  name: my-app-pipeline
serialPipeline:
  stages:
  - targetId: dev
    profiles: [dev]
  - targetId: staging
    profiles: [staging]
  - targetId: prod
    profiles: [prod]
    strategy:
      canary:
        runtimeConfig:
          kubernetes:
            serviceNetworking:
              service: my-app-svc
        canaryDeployment:
          percentages: [25, 50, 75]

Testing Strategies

The exam tests your understanding of testing types and where they fit in the pipeline:

Exam trap: The exam may present a scenario where a team deploys directly from development to production. The correct recommendation always includes intermediate environments (dev → staging → production) with appropriate testing gates at each stage.

Troubleshooting and Root Cause Analysis

For the exam, know this troubleshooting methodology:

1. Define the problem clearly (what is the expected vs. actual behavior?)
2. Gather data -- Cloud Logging, Cloud Monitoring metrics, Cloud Trace spans, Error Reporting
3. Form hypotheses based on data
4. Test hypotheses systematically (one change at a time)
5. Implement fix and verify
6. Document in a blameless postmortem

Key GCP troubleshooting tools:

4.2 Analyzing and Defining Business Processes

CapEx vs. OpEx in Cloud Migration

This is a fundamental concept the exam tests in migration and cost justification scenarios.

Exam trap: Committed Use Discounts (CUDs) are still OpEx in cloud accounting terms -- you are committing to a spend level, not purchasing hardware. However, the Google Cloud cost optimization framework notes that sole-tenant nodes may be classified as capital expenditure. Know the distinction.

Cost Optimization Strategies

The Google Cloud Architecture Framework cost optimization pillar defines four principles: align spending with business value, foster cost awareness culture, optimize resource usage, and optimize continuously.

Compute Cost Optimization

Key distinctions:

• Spot VMs replace the older preemptible VMs. Spot VMs have no 24-hour maximum lifetime (preemptible VMs did). Both can be reclaimed with 30-second notice.
• SUDs are automatic -- no commitment required. They apply to N1 machines and sole-tenant nodes only. N2, N2D, E2, and newer machine families use CUDs instead.
• CUDs are resource-based (vCPU + memory, applied across projects in a billing account) or spend-based (dollar commitment for specific services). Resource-based CUDs are more common for compute.

Exam trap: E2 machine types do NOT get sustained use discounts. Only N1 and sole-tenant nodes do. For E2, N2, and newer families, the only discount mechanism is CUDs. This is a frequently tested distinction.

Storage Cost Optimization

Lifecycle policies automatically transition objects between storage classes or delete them based on age, creation date, or custom conditions. This is the primary cost optimization tool for Cloud Storage.

Exam trap: All storage classes have the same first-byte latency (milliseconds) and availability SLA for multi-region (99.95%). The cost savings come from lower storage costs in exchange for higher retrieval costs and minimum storage duration charges. If you delete an Archive object after 30 days, you still pay for 365 days.

Network Cost Optimization

• Ingress is free on GCP. Egress is where costs accumulate.
• Cloud CDN reduces egress costs by caching content at edge locations.
• Same-zone traffic is free. Cross-zone traffic within a region incurs charges.
• Private Google Access avoids egress charges for accessing Google APIs from VMs without external IPs.
• Cloud Interconnect provides reduced egress rates compared to public internet egress.

Licensing

Change Management and Decision Frameworks

The exam tests organizational aspects of cloud adoption:

• Stakeholder management: Identify decision-makers, influencers, and affected teams. Cloud migration affects infrastructure, development, security, finance, and operations teams.
• Communication plans: Regular cadence for migration status, cost reporting, and incident updates.
• Technology selection framework: Evaluate based on requirements (scalability, cost, compliance, team expertise, vendor lock-in risk), not technology preference.

4.3 Developing Reliability Procedures

Business Continuity vs. Disaster Recovery

DR is a subset of BCP. The exam tests both, but DR scenarios are more common.

RTO and RPO

These are the two most critical metrics in DR planning, and the exam tests them heavily.

DR pattern selection based on RTO/RPO:

Exam trap: Lower RTO/RPO always costs more. The exam frequently presents scenarios where you must choose the cheapest DR strategy that meets the stated RTO/RPO requirements. Do not over-architect. If the requirement is RTO=24 hours and RPO=4 hours, a cold DR pattern with periodic snapshots is correct -- not an active-active multi-region setup.

SLI / SLO / SLA Workflow

This topic comes directly from Google's SRE Book Chapter 4. Understand the hierarchy:

Key relationships:

• SLIs are measured. SLOs are targets. SLAs are contracts.
• SLOs should always be stricter than SLAs (internal target > external commitment).
• The gap between SLO and SLA is your safety margin.

Error Budgets

The error budget is the inverse of the SLO. If your SLO is 99.9% availability, your error budget is 0.1% downtime per measurement period.

Error budget math (30-day month):

Error budget policy: When the budget is exhausted, slow down deployments and prioritize reliability work. When budget is healthy, deploy faster and take more risks. This is the core SRE mechanism for balancing velocity and reliability.

Exam trap: The exam may present a scenario where a team has consumed its error budget. The correct action is to freeze feature deployments and focus on reliability improvements -- not to relax the SLO or ignore the budget.

Deployment Strategies for Reliability

Cloud Deploy supports canary and blue-green strategies natively for GKE and Cloud Run targets. Rolling updates are the default for GKE Deployments via kubectl.

Exam trap: Blue-green deployments require double the infrastructure during the transition. If cost is a constraint in the scenario, canary is often the better choice because only a small percentage of capacity runs the new version at any time.

Chaos Engineering and Penetration Testing

Chaos engineering deliberately introduces failures to verify system resilience. On GCP:

• Test zone failures by draining instances from one zone
• Test region failures by simulating DNS failover
• Use Fault Injection in Istio/Anthos Service Mesh for HTTP error injection and delay injection
• Automate chaos tests in CI/CD pipelines as part of pre-production validation

Penetration testing on GCP:

• Google's Acceptable Use Policy permits penetration testing of your own resources without prior notification to Google.
• You may test resources you own within your GCP projects.
• You may not test Google's underlying infrastructure or other customers' resources.
• Use Web Security Scanner (part of Security Command Center) for automated web application vulnerability scanning.

Exam trap: Unlike AWS (which used to require pre-approval for pen testing), GCP does not require you to notify Google before conducting penetration tests on your own resources. If the exam asks about pen testing prerequisites, the answer involves scoping to your own resources and following responsible testing practices -- not requesting permission from Google.

Monitoring and Alerting for Reliability

Cloud Monitoring is the observability backbone:

Alerting best practices for the exam:

• Alert on symptoms (user-facing impact), not causes (CPU usage).
• Use burn-rate alerts for SLO monitoring: alert when error budget is being consumed faster than expected.
• Configure multiple notification channels for critical alerts (e.g., PagerDuty + email).
• Set appropriate alignment periods and evaluation windows to reduce alert noise.

Infrastructure as Code for Reliability

Terraform is the primary IaC tool tested on the PCA exam:

Exam trap: Terraform state files contain sensitive data (resource IDs, connection strings). Always store state in a remote backend (Cloud Storage bucket with versioning and encryption) with state locking enabled via Cloud Storage's built-in locking mechanism. Never store state in local files or version control.

Key Exam Patterns for Domain 4

1. Pipeline design questions: Given a development workflow, select the correct combination of Cloud Build, Artifact Registry, and Cloud Deploy services.
2. Cost optimization scenarios: Given a workload profile, select the cheapest viable compute/storage option that meets the requirements.
3. DR strategy selection: Given RTO/RPO requirements, select the appropriate DR pattern (cold/warm/hot/active-active).
4. SLO/error budget decisions: Given an SLO breach or budget exhaustion scenario, select the correct organizational response.
5. Deployment strategy selection: Given reliability requirements and constraints (cost, downtime tolerance), select the appropriate deployment strategy.

References

• Cloud Build Overview
• Cloud Deploy Overview
• Artifact Registry Overview
• Google Cloud Architecture Framework: Reliability
• Google Cloud Architecture Framework: Cost Optimization
• Google SRE Book: Service Level Objectives (Chapter 4)
• Google SRE Book: Embracing Risk (Chapter 3)
• Google SRE Book: Testing for Reliability (Chapter 17)
• Google Cloud Acceptable Use Policy
• Cloud Foundation Toolkit
• Cloud Monitoring Documentation
• Binary Authorization