PCCP - Professional Cloud Certified Professional cheat sheet

Google Cloud resource hierarchy is Organization → Folders → Projects → resources; IAM policies inherit downward and a policy set higher in the tree is additive with lower ones, never subtractive.

Choose the compute primitive by control vs. ops burden: Compute Engine for full OS control, GKE for container orchestration, Cloud Run for request-driven stateless containers, App Engine for managed app platforms, Cloud Functions/Eventarc for event handlers.

Storage decision rule: Cloud Storage for object/blob and static assets, Filestore for NFS shared files, Persistent Disk for zonal block storage, local SSD for highest IOPS with ephemeral data, BigQuery for analytical columnar workloads.

Database rule: Cloud SQL for regional relational up to moderate scale, Spanner for horizontally scalable strongly consistent relational with 99.999% multi-region SLA, Firestore for document/mobile sync, Bigtable for wide-column high-throughput time series, Memorystore for sub-millisecond caching.

Multi-region vs. region vs. zone: a zone is a single failure domain, a region is a set of zones, a multi-region location spans regions; a regional service survives a single zone failure and a multi-region design survives a regional failure.

Network topology rule: use a Shared VPC when multiple projects must share one centrally administered network; use VPC Network Peering for independent admin domains; use Private Service Connect for private access to Google APIs and published services.

Load balancer selection: Global external Application Load Balancer for HTTP(S) across regions, regional external proxy Network Load Balancer for TCP with proxy features, passthrough Network Load Balancer for source-IP preservation and non-proxied protocols.

Billing decision rule: committed use discounts (1 or 3 year) suit steady-state baseline, sustained use discounts apply automatically to Compute Engine, Spot VMs and preemptible capacity suit fault-tolerant batch, and per-second billing applies to many IaaS resources.

Design for quota and limit awareness: project-level quotas (e.g., API rate limits, IP space, CPU) must be checked before architecture sign-off; quota increases are not instantaneous, so plan for lead time.

Infrastructure as Code order of operations: enable required APIs, create service accounts and IAM bindings, then create resources that depend on them; Terraform resolves dependencies from references but not from API enablement unless modeled.

Terraform state should live in a Cloud Storage backend with versioning and locking (state locking uses the object generation); never keep state only on a local workstation for shared environments.

Deployment mechanisms by scope: gcloud CLI for imperative one-offs, Deployment Manager or Terraform for declarative IaC, Config Controller/Config Connector for Kubernetes-native resource management, Cloud Build for CI/CD pipelines.

Image strategy: custom images built with Packer or Cloud Build give reproducible VM boot; instance templates and managed instance groups (MIGs) provide autoscaling, autohealing, and rolling updates across zones.

Autoscaling inputs: CPU utilization, load balancing utilization, Cloud Monitoring metrics, or schedules; set min replicas for baseline capacity and use readiness/health checks to gate traffic.

GKE provisioning choices: Autopilot for Google-managed nodes and hardening, Standard for node-level control; use node pools per workload class (e.g., GPU, memory-optimized) and cluster autoscaler for node scaling.

Blue/green and canary releases on GKE use Services plus Deployments with multiple ReplicaSets; traffic splitting can be done by ingress weights or by service mesh (Anthos Service Mesh / Istio) virtual services.

Cloud Storage provisioning decisions: bucket location (region/multi-region/dual-region), storage class, uniform bucket-level access, retention policy, and lifecycle rules should be set at creation because some properties are immutable.

Provisioning network: subnets are regional and can be dual-stack; secondary ranges are needed for GKE VPC-native clusters (pods and services ranges) and must be sized to avoid IP exhaustion.

IAM least privilege model: grant roles to groups rather than individuals, prefer predefined roles over primitive Owner/Editor/Viewer, and use IAM Conditions for attribute-based constraints (time, resource name, request origin).

Service account key hygiene: prefer attached service accounts on GCE/GKE/Cloud Run and Workload Identity Federation for external workloads; user-managed keys are long-lived credentials and should be rotated or eliminated.

Encryption layers: Google-managed keys by default, CMEK via Cloud KMS for customer control, CSEK for customer-supplied keys, and EKM for external key manager; CMEK is available on most storage and database services.

Data protection controls: Cloud DLP for discovery and de-identification (masking, tokenization, format-preserving encryption), VPC Service Controls for perimeter around APIs to reduce data exfiltration risk, and Access Transparency/Access Approval for Google staff access.

Network security layering: firewall rules are stateful and applied at the VPC level with priority and target tags/service accounts; hierarchical firewall policies apply at org/folder level; Cloud Armor provides WAF and DDoS protection at the load balancer.

Private connectivity: Private Google Access lets VMs without external IPs reach Google APIs; Private Service Connect exposes services via private endpoints; Cloud NAT provides egress for private instances without inbound exposure.

Compliance mapping: Assured Workloads enforces regulatory controls (e.g., data residency, personnel access) in a dedicated folder; compliance reports are published per product and per control framework, so verify the specific service and region.

Audit logging: Admin Activity logs are always on and free; Data Access logs are off by default and must be enabled per service; logs can be routed to Cloud Storage/BigQuery/Pub/Sub via log sinks for retention beyond the default 30 days.

Secrets management: Secret Manager stores versioned secrets with IAM and audit logging; avoid embedding secrets in code, instance metadata, or container images.

Cost visibility levers: labels for cost allocation, billing export to BigQuery for analysis, budgets and alerts for threshold notification, and quota limits to cap runaway spend.

Rightsizing rule: compare sustained CPU and memory utilization from Cloud Monitoring over at least a week; recommend machine type changes only when p95 utilization is consistently below the target threshold.

Pricing model selection: committed use discounts for predictable baseline, sustained use discounts automatic for Compute Engine, Spot VMs for interruptible batch, and flat-rate or per-second billing depending on resource type.

Storage cost optimization: lifecycle rules to transition to Nearline/Coldline/Archive, Object Lifecycle Management for deletion, and choosing the right class by access frequency and minimum storage duration charges.

BigQuery cost control: partition and cluster tables to reduce bytes scanned, use SELECT of specific columns instead of SELECT *, set custom quotas, and use flat-rate reservations for predictable heavy workloads.

Process automation: Cloud Scheduler for cron, Eventarc/Cloud Pub/Sub for event-driven triggers, Workflows for multi-step orchestration, and Cloud Build triggers for pipeline automation.

Migration assessment: use the migration pillars (assess, plan, migrate, optimize) and tools such as Migration Center/StratoZone for discovery; choose rehost, replatform, refactor, or rebuild based on business value vs. effort.

SLO-driven operations: define SLIs (latency, error rate, throughput, freshness), set SLO targets below 100% to leave error budget, and use burn-rate alerts rather than raw threshold alerts for reliability decisions.

Observability triad: Cloud Monitoring for metrics and uptime checks, Cloud Logging for logs with log-based metrics, Cloud Trace for distributed latency, and Error Reporting for exception aggregation.

Deployment pipeline stages: source (Cloud Source Repositories or GitHub), build (Cloud Build), artifact storage (Artifact Registry), deploy (GKE/Cloud Run/App Engine), and promotion gates with approval steps.

Cloud Build configuration uses cloudbuild.yaml with steps; substitutions allow environment-specific values; private pools give dedicated networking and larger machine sizes for builds.

Rolling updates on MIGs use maxSurge and maxUnavailable; canary deployments on GKE use multiple Deployments and traffic weighting; Cloud Run revisions support percentage traffic splitting for gradual rollout.

Monitoring setup: uptime checks with alerting policies, log-based metrics for business events, dashboards per service, and notification channels (email, SMS, Pub/Sub, webhook) configured before go-live.

Incident response: use Cloud Monitoring alerts with severity labels, on-call rotation via third-party integrations, and post-incident review; Error Reporting groups similar stack traces to reduce noise.

Backup and DR: snapshot schedules for Persistent Disk, Cloud SQL automated backups and point-in-time recovery, Spanner backups, and Cloud Storage object versioning plus retention policies.

Patch management: OS patch management via VM Manager, container image rebuilds on base image CVEs, and Artifact Registry vulnerability scanning for container images.

Access operations: use gcloud auth login for user identity, service account impersonation for automation, and audit Admin Activity logs for change tracking; break-glass accounts should be monitored and rarely used.

Capacity operations: monitor quota usage, set up quota alerts, and pre-request increases for known peaks such as launches; regional resource availability varies and should be validated per zone.

Reliability hierarchy: single zone → regional (multi-zone) → multi-region; each step increases cost and complexity, so match the redundancy level to the RTO/RPO of the workload.

Health checking rule: use HTTP(S) health checks for load-balanced web services, TCP/SSL for non-HTTP, and gRPC health checks for gRPC services; autohealing MIGs rely on health check results to recreate unhealthy instances.

Load balancing resilience: global external Application Load Balancer routes to the closest healthy backend and fails over across regions; enable connection draining and outlier detection to remove unhealthy backends.

Data durability: Cloud Storage offers 11 nines of durability for standard buckets; use dual-region or multi-region buckets plus versioning for regional failure tolerance; Spanner multi-region gives 99.999% availability.

Graceful degradation: implement retries with exponential backoff and jitter, circuit breakers, and timeouts; Cloud Client Libraries include automatic retry for idempotent operations.

Chaos and validation: use fault injection (e.g., stopping instances, simulating zone failure) in non-production to validate failover; verify that failover is automatic and measured against RTO.

Error budget policy: define what happens when the error budget is exhausted (freeze feature releases, prioritize reliability work); track SLO compliance over rolling windows.

Deployment safety: use progressive rollouts, automated rollback on failed health checks, and immutable image tags/digests to ensure reproducibility; avoid latest tags in production.

Operational readiness: runbooks for common failures, documented on-call escalation, tested restore procedures, and regular DR game days are the evidence that reliability design actually works.