--- schema_version: "1.0" project_name: "reasons" updated_at: "2026-06-05T02:23:11+00:00" node_count: 863 generator: ftl-reasons/0.43.0 --- # Belief Registry ## Repos - Date: 2026-03-11 - Source: entries/2026/03/11/vpn-overview.md - Source hash: 0f7da5bd938d7e42 ## Claims ### alb-backend-protocol-independent-of-frontend [IN] OBSERVATION The ALB backend protocol (HTTP, HTTPS, HTTP/2, H2C) is independent of the client-facing frontend protocol. - Source: entries/2026/03/10/lb-http.md - Source hash: 311a646a6f3b82b1 - Date: 2026-03-11 ### alb-external-managed-vs-external-scheme [IN] OBSERVATION Global and regional ALBs use load balancing scheme `EXTERNAL_MANAGED`; classic ALBs use `EXTERNAL`. `EXTERNAL_MANAGED` backend services can attach to `EXTERNAL` forwarding rules but not vice versa. - Source: entries/2026/03/10/lb-http.md - Source hash: 311a646a6f3b82b1 - Date: 2026-03-11 ### alb-forwarding-rule-single-port [IN] OBSERVATION Each ALB forwarding rule supports only one port (1–65535); use multiple forwarding rules for multiple ports. - Source: entries/2026/03/10/lb-http.md - Source hash: 311a646a6f3b82b1 - Date: 2026-03-11 ### alb-h2c-not-supported-classic [IN] OBSERVATION H2C (HTTP/2 cleartext) is not supported on classic Application Load Balancers. - Source: entries/2026/03/10/lb-http.md - Source hash: 311a646a6f3b82b1 - Date: 2026-03-11 ### alb-health-check-ip-ranges [IN] OBSERVATION GFE health check probes originate from IP ranges `130.211.0.0/22` and `35.191.0.0/16`. - Source: entries/2026/03/10/lb-http.md - Source hash: 311a646a6f3b82b1 - Date: 2026-03-11 ### alb-proxy-only-subnet-regional-only [IN] OBSERVATION A proxy-only subnet (purpose `REGIONAL_MANAGED_PROXY`) is required only for regional external ALBs, not for global or classic ALBs. - Source: entries/2026/03/10/lb-http.md - Source hash: 311a646a6f3b82b1 - Date: 2026-03-11 ### alb-regional-for-data-residency [IN] OBSERVATION Regional external ALB is the appropriate choice for compliance/data residency requirements (single geolocation). - Source: entries/2026/03/10/lb-http.md - Source hash: 311a646a6f3b82b1 - Date: 2026-03-11 ### alb-three-modes-global-classic-regional [IN] OBSERVATION The external Application Load Balancer operates in three modes: global external ALB, classic ALB, and regional external ALB; mode is immutable after creation. - Source: entries/2026/03/10/lb-http.md - Source hash: 311a646a6f3b82b1 - Date: 2026-03-11 ### ar-access-scopes-can-restrict-beyond-iam [IN] OBSERVATION Compute Engine VM access scopes can further restrict Artifact Registry access beyond IAM roles — the default `read-only` scope blocks writes even if the SA has Writer role; `cloud-platform` scope is needed for push. - Source: entries/2026/03/11/artifactregistry-access-control.md - Source hash: b8ce5667057c1e51 - Date: 2026-03-11 ### ar-auth-configure-docker-per-hostname [IN] OBSERVATION The `gcloud auth configure-docker HOSTNAME` command configures the Docker credential helper for a specific Artifact Registry hostname (e.g., `us-west1-docker.pkg.dev`). - Source: entries/2026/03/11/artifactregistry-docker.md - Source hash: ae89ac0902118df3 - Date: 2026-03-11 ### ar-cleanup-background-job-one-day [IN] OBSERVATION Artifact Registry cleanup policy changes take effect within approximately one day via a background job. - Source: entries/2026/03/11/artifactregistry-cleanup.md - Source hash: eab25020d7acef6c - Date: 2026-03-11 ### ar-cleanup-deletes-count-against-quota [IN] OBSERVATION Artifact Registry cleanup deletions count against the per-project delete request quota. - Source: entries/2026/03/11/artifactregistry-repositories.md - Source hash: 2654f7ba4236d978 - Date: 2026-03-11 ### ar-cleanup-dry-run-requires-data-access-logs [IN] OBSERVATION Artifact Registry cleanup dry run results appear in Data Access audit logs, which must be explicitly enabled with "data write" type to see results. - Source: entries/2026/03/11/artifactregistry-cleanup.md - Source hash: eab25020d7acef6c - Date: 2026-03-11 ### ar-cleanup-keep-overrides-delete [IN] OBSERVATION Artifact Registry cleanup keep policies always override delete policies when an artifact matches both. - Source: entries/2026/03/11/artifactregistry-cleanup.md - Source hash: eab25020d7acef6c - Date: 2026-03-11 ### ar-cleanup-no-tag-support-treated-untagged [IN] OBSERVATION Artifact formats that don't support tags are treated as `untagged` for cleanup policy evaluation. - Source: entries/2026/03/11/artifactregistry-cleanup.md - Source hash: eab25020d7acef6c - Date: 2026-03-11 ### ar-cleanup-requires-admin-role [IN] OBSERVATION Artifact Registry cleanup policies require `roles/artifactregistry.admin` (needs `artifactregistry.repositories.update` and `artifactregistry.versions.delete` permissions). - Source: entries/2026/03/11/artifactregistry-cleanup.md - Source hash: eab25020d7acef6c - Date: 2026-03-11 ### ar-cleanup-standard-repos-only [IN] OBSERVATION Artifact Registry cleanup policies can only be applied to standard repositories, not virtual repositories or at the project level. - Source: entries/2026/03/11/artifactregistry-cleanup.md - Source hash: eab25020d7acef6c - Date: 2026-03-11 ### ar-cleanup-tagstate-tagged-required-for-prefixes [IN] OBSERVATION In Artifact Registry cleanup policies, `tagState` must be `TAGGED` to use `tagPrefixes` in conditions. - Source: entries/2026/03/11/artifactregistry-cleanup.md - Source hash: eab25020d7acef6c - Date: 2026-03-11 ### ar-cloud-build-default-read-write [IN] OBSERVATION Cloud Build's default service account has read/write access to Artifact Registry. - Source: entries/2026/03/11/artifactregistry-access-control.md - Source hash: b8ce5667057c1e51 - Date: 2026-03-11 ### ar-cloudrun-cross-project-service-agent [IN] OBSERVATION Cloud Run cross-project Artifact Registry access requires granting roles to the Cloud Run Service Agent (`service-PROJECT-NUMBER@serverless-robot-prod.iam.gserviceaccount.com`), not just the runtime service account. - Source: entries/2026/03/11/artifactregistry-access-control.md - Source hash: b8ce5667057c1e51 - Date: 2026-03-11 ### ar-cmek-encryption-supported [IN] OBSERVATION Artifact Registry supports CMEK encryption via Cloud KMS (Google-managed encryption by default), and organization policy can enforce CMEK. - Source: entries/2026/03/11/artifactregistry-repositories.md - Source hash: 2654f7ba4236d978 - Date: 2026-03-11 ### ar-createonpush-roles-for-gcr-migration [IN] OBSERVATION The `createOnPush` Artifact Registry roles (`roles/artifactregistry.createOnPushWriter` and `createOnPushRepoAdmin`) are specifically for Container Registry to Artifact Registry migration, allowing gcr.io repo creation on push. - Source: entries/2026/03/11/artifactregistry-access-control.md - Source hash: b8ce5667057c1e51 - Date: 2026-03-11 ### ar-cross-project-requires-explicit-grant [IN] OBSERVATION Artifact Registry cross-project access is not automatic — roles must be explicitly granted in the Artifact Registry project. - Source: entries/2026/03/11/artifactregistry-access-control.md - Source hash: b8ce5667057c1e51 - Date: 2026-03-11 ### ar-default-compute-sa-read-only [IN] OBSERVATION Compute Engine, GKE, and Cloud Run default service accounts get read-only access to Artifact Registry by default. - Source: entries/2026/03/11/artifactregistry-access-control.md - Source hash: b8ce5667057c1e51 - Date: 2026-03-11 ### ar-docker-image-path-format [IN] OBSERVATION Artifact Registry Docker image paths follow the format `LOCATION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE:TAG`. - Source: entries/2026/03/11/artifactregistry-docker.md - Source hash: ae89ac0902118df3 - Date: 2026-03-11 ### ar-iam-roles-project-or-repository-level [IN] OBSERVATION Artifact Registry IAM roles can be granted at two levels: project-wide (applies to all repositories) or repository-specific. - Source: entries/2026/03/11/artifactregistry-access-control.md - Source hash: b8ce5667057c1e51 - Date: 2026-03-11 ### ar-image-streaming-requires-same-region [IN] OBSERVATION Artifact Registry image streaming only works when images are in the same region (or corresponding multi-region) as workloads. - Source: entries/2026/03/11/artifactregistry-repositories.md - Source hash: 2654f7ba4236d978 - Date: 2026-03-11 ### ar-no-egress-charge-same-region [IN] OBSERVATION No egress charge from Artifact Registry to Google Cloud services in the same region. - Source: entries/2026/03/11/artifactregistry-repositories.md - Source hash: 2654f7ba4236d978 - Date: 2026-03-11 ### ar-orgs-after-may-2024-no-auto-editor [IN] OBSERVATION Organizations created after May 3, 2024 enforce `iam.automaticIamGrantsForDefaultServiceAccounts` by default, preventing automatic Editor role grants to default service accounts. - Source: entries/2026/03/11/artifactregistry-access-control.md - Source hash: b8ce5667057c1e51 - Date: 2026-03-11 ### ar-public-repo-allUsers-reader-plus-quota [IN] OBSERVATION Making an Artifact Registry repository public requires granting `roles/artifactregistry.reader` to `allUsers` and capping per-user quotas to prevent abuse. - Source: entries/2026/03/11/artifactregistry-access-control.md - Source hash: b8ce5667057c1e51 - Date: 2026-03-11 ### ar-remote-repos-cache-upstream-dependencies [IN] OBSERVATION Artifact Registry remote repositories are read-only caching proxies for upstream public sources (Docker Hub, Maven Central, PyPI), enabling vulnerability scanning and provenance tracking on third-party dependencies. - Source: entries/2026/03/11/artifactregistry-overview.md - Source hash: b63c1cd8be48752f - Date: 2026-03-11 ### ar-replaces-container-registry [IN] OBSERVATION Artifact Registry is Google Cloud's recommended registry, replacing Container Registry, with support for both container images and language packages (Go, Java, Node.js, Python, Ruby, Helm). - Source: entries/2026/03/11/artifactregistry-overview.md - Source hash: b63c1cd8be48752f - Date: 2026-03-11 ### ar-repo-format-immutable-after-creation [IN] OBSERVATION Artifact Registry repository format (`--repository-format=docker`) is specified at creation and cannot be changed afterward. - Source: entries/2026/03/11/artifactregistry-docker.md - Source hash: ae89ac0902118df3 - Date: 2026-03-11 ### ar-repo-mode-immutable-after-creation [IN] OBSERVATION Artifact Registry repository mode (standard, remote, or virtual) cannot be changed after creation. - Source: entries/2026/03/11/artifactregistry-repositories.md - Source hash: 2654f7ba4236d978 - Date: 2026-03-11 ### ar-repository-configuration-immutable-at-creation [IN] OBSERVATION Artifact Registry repository format and mode are both immutable after creation — a repository's package type (Docker, Maven, npm) and operational mode (standard, remote, virtual) are permanent architectural decisions that cannot be corrected without recreating the repository and migrating all artifacts. ### ar-tags-attach-to-repos-not-artifacts [IN] OBSERVATION Resource Manager tags attach to Artifact Registry repositories only, not individual artifacts, for conditional IAM access control. - Source: entries/2026/03/11/artifactregistry-access-control.md - Source hash: b8ce5667057c1e51 - Date: 2026-03-11 ### ar-virtual-repo-requires-sa-grant-to-upstreams [IN] OBSERVATION Virtual repositories require explicit grants for the Artifact Registry service account to access upstream repositories. - Source: entries/2026/03/11/artifactregistry-repositories.md - Source hash: 2654f7ba4236d978 - Date: 2026-03-11 ### ar-virtual-repo-roles-cascade-all-upstreams [IN] OBSERVATION Virtual repository IAM roles apply to all upstream repositories regardless of individual upstream repo permissions. - Source: entries/2026/03/11/artifactregistry-access-control.md - Source hash: b8ce5667057c1e51 - Date: 2026-03-11 ### ar-virtual-repos-priority-based-resolution [IN] OBSERVATION Artifact Registry virtual repositories aggregate multiple repos behind a single endpoint with priority-based resolution order, mitigating dependency confusion attacks by prioritizing private over public upstream repos. - Source: entries/2026/03/11/artifactregistry-overview.md - Source hash: b63c1cd8be48752f - Date: 2026-03-11 ### auto-mode-vpc-creates-slash-20-subnets [IN] OBSERVATION Auto mode VPC networks automatically create one /20 subnet per region from the 10.128.0.0/9 block. - Source: entries/2026/03/10/vpc-subnets.md - Source hash: 0a93f184ecf6ad03 - Date: 2026-03-11 ### cannot-create-static-route-within-subnet-range [IN] OBSERVATION A static route cannot be created with a destination that matches or fits within an existing subnet route range, and vice versa (unless using hybrid subnets). - Source: entries/2026/03/10/vpc-routes.md - Source hash: 5ea29512bcefff8c - Date: 2026-03-11 ### classic-vpn-no-ipv6-support [IN] OBSERVATION Classic VPN does not support IPv6 — only HA VPN supports dual-stack and IPv6-only configurations. - Source: entries/2026/03/11/vpn-overview.md - Source hash: 0f7da5bd938d7e42 - Date: 2026-03-11 ### cloud-armor-adaptive-protection-requires-enterprise [IN] OBSERVATION Adaptive Protection requires a Cloud Armor Enterprise subscription and is enabled per-security policy. - Source: entries/2026/03/10/armor-overview.md - Source hash: f95a931f1e530184 - Date: 2026-03-11 ### cloud-armor-auto-ddos-global-external-alb [IN] OBSERVATION DDoS protection is automatic (no configuration needed) for global external Application Load Balancers, classic Application Load Balancers, and external proxy Network Load Balancers. - Source: entries/2026/03/10/armor-overview.md - Source hash: f95a931f1e530184 - Date: 2026-03-11 ### cloud-armor-edge-first-layered-defense [IN] OBSERVATION Cloud Armor provides edge-first layered defense with four independent mechanisms: automatic DDoS protection at the Google Cloud edge for global external ALBs, prioritized rule evaluation ensuring highest-priority matches win, OWASP CRS 3.3.2-based WAF rules for application-layer filtering, and Enterprise-tier protection covering HTTP/HTTPS/HTTP2/QUIC protocols. ### cloud-armor-enterprise-ddos-protocols [IN] OBSERVATION Cloud Armor Enterprise DDoS protection supports HTTP, HTTPS, HTTP/2, and QUIC protocols. - Source: entries/2026/03/10/armor-overview.md - Source hash: f95a931f1e530184 - Date: 2026-03-11 ### cloud-armor-operates-at-edge [IN] OBSERVATION Cloud Armor operates at the Google Cloud edge, filtering traffic before it reaches backend resources or enters VPC networks. - Source: entries/2026/03/10/armor-overview.md - Source hash: f95a931f1e530184 - Date: 2026-03-11 ### cloud-armor-prioritized-rules [IN] OBSERVATION Cloud Armor security policies use prioritized rules — the highest-priority matching rule wins. - Source: entries/2026/03/10/armor-overview.md - Source hash: f95a931f1e530184 - Date: 2026-03-11 ### cloud-armor-supports-hybrid-multicloud [IN] OBSERVATION Cloud Armor supports hybrid and multi-cloud deployments — it is not limited to GCP-hosted backends. - Source: entries/2026/03/10/armor-overview.md - Source hash: f95a931f1e530184 - Date: 2026-03-11 ### cloud-armor-waf-owasp-crs-332 [IN] OBSERVATION Cloud Armor preconfigured WAF rules are based on OWASP Core Rule Set 3.3.2 (CRS) and do not support XML body parsing. - Source: entries/2026/03/10/armor-overview.md - Source hash: f95a931f1e530184 - Date: 2026-03-11 ### cloud-dns-admin-cannot-set-iam-policy [IN] OBSERVATION `roles/dns.admin` can manage DNS records but cannot set IAM policies on zones (lacks `setIamPolicy` permission). - Source: entries/2026/03/10/dns-overview.md - Source hash: b89970545523dd0a - Date: 2026-03-11 ### cloud-dns-alias-records-skipped-bind-export [IN] OBSERVATION ALIAS records are skipped when exporting Cloud DNS zones to BIND format. - Source: entries/2026/03/10/dns-records.md - Source hash: 44812c7474b8bff7 - Date: 2026-03-11 ### cloud-dns-at-symbol-literal [IN] OBSERVATION The `@` symbol in Cloud DNS Console is treated literally, not as an apex alias — leave the DNS name field blank for apex records. - Source: entries/2026/03/10/dns-records.md - Source hash: 44812c7474b8bff7 - Date: 2026-03-11 ### cloud-dns-bind-import-trailing-dots [IN] OBSERVATION BIND zone file imports require trailing dots on fully qualified domain names to avoid relative-name interpretation. - Source: entries/2026/03/10/dns-records.md - Source hash: 44812c7474b8bff7 - Date: 2026-03-11 ### cloud-dns-cname-exclusivity [IN] OBSERVATION If a CNAME record exists at a DNS name, no other record type can coexist at that name. - Source: entries/2026/03/10/dns-records.md - Source hash: 44812c7474b8bff7 - Date: 2026-03-11 ### cloud-dns-configuration-cascading-side-effects [IN] OBSERVATION Cloud DNS configuration changes have cascading side effects that extend beyond the modified resource: enabling an outbound server policy silently disables resolution of all private zones, forwarding zones, and peering zones; DNSSEC disabling must follow a registrar-first sequence or cause resolution failures for the entire zone; and CNAME exclusivity silently prevents coexistence with any other record type at the same name — making DNS changes among the highest-blast-radius operations in GCP networking. ### cloud-dns-cross-project-binding-same-org [IN] OBSERVATION Cross-project binding zones work only within the same organization. - Source: entries/2026/03/10/dns-zones.md - Source hash: 0e4bd99fd7e08e48 - Date: 2026-03-11 ### cloud-dns-disable-dnssec-registrar-first [IN] OBSERVATION Before disabling DNSSEC on a Cloud DNS managed zone, DNSSEC must be deactivated at the domain registrar first to avoid resolution failures. - Source: entries/2026/03/10/dns-zones.md - Source hash: 0e4bd99fd7e08e48 - Date: 2026-03-11 ### cloud-dns-dns64-well-known-prefix [IN] OBSERVATION DNS64 synthesizes IPv6 addresses using the Well-Known Prefix `64:ff9b::/96` per RFC 6052 and requires NAT64 via Cloud NAT. - Source: entries/2026/03/10/dns-overview.md - Source hash: b89970545523dd0a - Date: 2026-03-11 ### cloud-dns-dnssec-authentication-not-encryption [IN] OBSERVATION DNSSEC provides authentication against spoofing and cache poisoning, not encryption. - Source: entries/2026/03/10/dns-overview.md - Source hash: b89970545523dd0a - Date: 2026-03-11 ### cloud-dns-must-empty-zone-before-delete [IN] OBSERVATION All records except SOA and NS must be removed before a Cloud DNS zone can be deleted via gcloud. - Source: entries/2026/03/10/dns-zones.md - Source hash: 0e4bd99fd7e08e48 - Date: 2026-03-11 ### cloud-dns-no-forwarding-for-public-zones [IN] OBSERVATION Cloud DNS does not support DNS forwarding for public zones — public zones must be authoritative. - Source: entries/2026/03/10/dns-overview.md - Source hash: b89970545523dd0a - Date: 2026-03-11 ### cloud-dns-ns-soa-auto-created-cannot-delete [IN] OBSERVATION NS and SOA records at the zone apex are auto-created and cannot be deleted via the API; they are removed only when the zone is deleted (per RFC 1034). - Source: entries/2026/03/10/dns-records.md - Source hash: 44812c7474b8bff7 - Date: 2026-03-11 ### cloud-dns-outbound-policy-disables-private-zones [IN] OBSERVATION Using a Cloud DNS outbound server policy disables resolution of all Cloud DNS private zones, forwarding zones, peering zones, and Compute Engine internal DNS zones. - Source: entries/2026/03/10/dns-overview.md - Source hash: b89970545523dd0a - Date: 2026-03-11 ### cloud-dns-reverse-lookup-zones-non-rfc1918 [IN] OBSERVATION Managed reverse lookup zones are needed for non-RFC 1918 PTR records on Compute Engine VMs. - Source: entries/2026/03/10/dns-zones.md - Source hash: 0e4bd99fd7e08e48 - Date: 2026-03-11 ### cloud-dns-security-limited-and-operationally-fragile [IN] OBSERVATION Cloud DNS security is limited in scope (DNSSEC provides authentication against spoofing and cache poisoning only, not encryption) and operationally fragile (configuration changes have cascading side effects where enabling outbound server policies silently disables private zones, CNAME exclusivity creates implicit constraints) — security-relevant DNS changes can silently break zone resolution. ### cloud-dns-service-directory-zones-no-direct-records [IN] OBSERVATION Service Directory zones cannot have records added directly — data comes from the Service Directory namespace. - Source: entries/2026/03/10/dns-zones.md - Source hash: 0e4bd99fd7e08e48 - Date: 2026-03-11 ### cloud-dns-shared-vpc-zones-in-host-project [IN] OBSERVATION Shared VPC private/forwarding/peering zones must be created in the host project (or use cross-project binding in service projects). - Source: entries/2026/03/10/dns-overview.md - Source hash: b89970545523dd0a - Date: 2026-03-11 ### cloud-dns-transactions-atomic [IN] OBSERVATION Cloud DNS transactions group multiple record changes into an atomic unit — the entire transaction succeeds or fails. - Source: entries/2026/03/10/dns-records.md - Source hash: 44812c7474b8bff7 - Date: 2026-03-11 ### cloud-dns-uses-anycast [IN] OBSERVATION Cloud DNS uses anycast to serve zones from multiple global locations for high availability and low latency. - Source: entries/2026/03/10/dns-overview.md - Source hash: b89970545523dd0a - Date: 2026-03-11 ### cloud-hsm-fips-140-2-level-3 [IN] OBSERVATION Cloud HSM keys are certified to FIPS 140-2 Level 3. - Source: entries/2026/03/11/kms-hsm.md - Source hash: 2a1316fe5af2fee3 - Date: 2026-03-11 ### cloud-hsm-quota-charged-to-key-project [IN] OBSERVATION HSM QPM quota is consumed in the project containing the HSM keys, not necessarily the project making the cryptographic request. - Source: entries/2026/03/11/kms-hsm.md - Source hash: 2a1316fe5af2fee3 - Date: 2026-03-11 ### cloud-hsm-single-tenant-same-location-as-keyring [IN] OBSERVATION Single-tenant HSM instances must be in the same location as the key ring that contains the keys. - Source: entries/2026/03/11/kms-hsm.md - Source hash: 2a1316fe5af2fee3 - Date: 2026-03-11 ### cloud-hsm-two-protection-levels [IN] OBSERVATION Cloud HSM offers two protection levels: `hsm` (multi-tenant shared infrastructure) and `hsm-single-tenant` (dedicated HSM instance). - Source: entries/2026/03/11/kms-hsm.md - Source hash: 2a1316fe5af2fee3 - Date: 2026-03-11 ### cloud-hsm-uses-kms-frontend [IN] OBSERVATION Cloud HSM uses Cloud KMS as its frontend — all HSM operations go through the KMS API, not a separate API. - Source: entries/2026/03/11/kms-hsm.md - Source hash: 2a1316fe5af2fee3 - Date: 2026-03-11 ### cloud-nat-gateway-public-or-private-not-both [IN] OBSERVATION A single Cloud NAT gateway can be either Public NAT or Private NAT, never both; two separate gateways can serve the same subnet. - Source: entries/2026/03/10/nat-overview.md - Source hash: 325a510d01e8a216 - Date: 2026-03-11 ### cloud-nat-google-apis-use-pga-not-nat [IN] OBSERVATION Traffic to Google APIs uses Private Google Access, not Public NAT, even when Public NAT is configured. - Source: entries/2026/03/10/nat-overview.md - Source hash: 325a510d01e8a216 - Date: 2026-03-11 ### cloud-nat-not-proxy-vm-based [IN] OBSERVATION Cloud NAT is not based on proxy VMs; it is software-defined via the Andromeda networking stack and does not reduce network bandwidth per VM. - Source: entries/2026/03/10/nat-overview.md - Source hash: 325a510d01e8a216 - Date: 2026-03-11 ### cloud-nat-outbound-only-no-unsolicited-inbound [IN] OBSERVATION Cloud NAT does not allow unsolicited inbound connections; it only handles outbound NAT and established inbound response packets. - Source: entries/2026/03/10/nat-overview.md - Source hash: 325a510d01e8a216 - Date: 2026-03-11 ### cloud-nat-private-nat-overlapping-ip-ranges [IN] OBSERVATION Private NAT addresses the overlapping IP range problem between VPC networks, using NCC spokes for connectivity. - Source: entries/2026/03/10/nat-overview.md - Source hash: 325a510d01e8a216 - Date: 2026-03-11 ### cloud-nat-regional-resource-on-cloud-router [IN] OBSERVATION Cloud NAT gateway is a regional resource configured on a Cloud Router. - Source: entries/2026/03/10/nat-overview.md - Source hash: 325a510d01e8a216 - Date: 2026-03-11 ### cloud-nat-serverless-requires-vpc-egress [IN] OBSERVATION Serverless resources (Cloud Run, Cloud Run functions, App Engine) require Direct VPC egress or Serverless VPC Access to use Cloud NAT. - Source: entries/2026/03/10/nat-overview.md - Source hash: 325a510d01e8a216 - Date: 2026-03-11 ### cloud-nat-software-defined-regional-gateway [IN] OBSERVATION Cloud NAT is a software-defined regional gateway on Cloud Router (not proxy VMs), routing internet egress while directing Google API traffic through Private Google Access instead, and requiring VPC egress configuration for serverless resources. ### cloud-source-repositories-deprecated-june-2024 [IN] OBSERVATION Cloud Source Repositories is unavailable to new customers after June 17, 2024. - Source: entries/2026/03/11/cloudbuild-triggers.md - Source hash: 5a5e64c8ea3403e8 - Date: 2026-03-11 ### cloud-vpn-cannot-route-public-internet [IN] OBSERVATION Cloud VPN cannot be used to route traffic to the public internet — it is designed exclusively for private network communication. - Source: entries/2026/03/11/vpn-overview.md - Source hash: 0f7da5bd938d7e42 - Date: 2026-03-11 ### cloud-vpn-cipher-options-immutable [IN] OBSERVATION Cloud VPN cipher configuration options are set at tunnel creation time and cannot be modified afterward — the tunnel must be deleted and recreated. - Source: entries/2026/03/11/vpn-overview.md - Source hash: 0f7da5bd938d7e42 - Date: 2026-03-11 ### cloud-vpn-ikev2-required-for-ipv6 [IN] OBSERVATION IKEv2 is required for IPv6 traffic over Cloud VPN; IKEv1 does not support IPv6. - Source: entries/2026/03/11/vpn-overview.md - Source hash: 0f7da5bd938d7e42 - Date: 2026-03-11 ### cloud-vpn-regional-resource [IN] OBSERVATION Cloud VPN is a regional resource — you select a region, not a zone, when creating a VPN gateway. - Source: entries/2026/03/11/vpn-overview.md - Source hash: 0f7da5bd938d7e42 - Date: 2026-03-11 ### cloud-vpn-site-to-site-only [IN] OBSERVATION Cloud VPN is site-to-site only — it does not support client-to-gateway (dial-in) VPN connections. - Source: entries/2026/03/11/vpn-overview.md - Source hash: 0f7da5bd938d7e42 - Date: 2026-03-11 ### cloud-vpn-tunnel-250k-pps-max [IN] OBSERVATION Each Cloud VPN tunnel supports up to 250,000 packets per second (combined ingress/egress), equivalent to 1–3 Gbps depending on packet size. - Source: entries/2026/03/11/vpn-overview.md - Source hash: 0f7da5bd938d7e42 - Date: 2026-03-11 ### cloudbuild-allow-exit-codes-precedence-over-allow-failure [IN] OBSERVATION Cloud Build `allowExitCodes` takes precedence over `allowFailure`; if all steps have `allowFailure: true` and all fail, build status is still Successful. - Source: entries/2026/03/11/cloudbuild-build-config.md - Source hash: a29a3814882d14be - Date: 2026-03-11 ### cloudbuild-binary-authorization-integration [IN] OBSERVATION Cloud Build integrates with Binary Authorization to check build attestations and block unauthorized deployments to Cloud Run/GKE. - Source: entries/2026/03/11/cloudbuild-overview.md - Source hash: c95bde686368b0fa - Date: 2026-03-11 ### cloudbuild-both-pool-types-scale-to-zero [IN] OBSERVATION Both Cloud Build default and private pools are fully managed, pay-per-build-minute, and auto-scale to zero. - Source: entries/2026/03/11/cloudbuild-private-pools.md - Source hash: ea3d39d048e78fd8 - Date: 2026-03-11 ### cloudbuild-cmek-automatic-ephemeral [IN] OBSERVATION Cloud Build CMEK compliance is automatic with no user configuration; an ephemeral encryption key is generated per build and destroyed after completion. - Source: entries/2026/03/11/cloudbuild-overview.md - Source hash: c95bde686368b0fa - Date: 2026-03-11 ### cloudbuild-default-machine-e2-standard-2 [IN] OBSERVATION Cloud Build default machine type is `E2_STANDARD_2` (2 CPUs); max disk size is 4000 GB. - Source: entries/2026/03/11/cloudbuild-build-config.md - Source hash: a29a3814882d14be - Date: 2026-03-11 ### cloudbuild-default-pool-max-concurrency-30 [IN] OBSERVATION Cloud Build default pool max concurrency is 30; private pool supports 100+. - Source: entries/2026/03/11/cloudbuild-private-pools.md - Source hash: ea3d39d048e78fd8 - Date: 2026-03-11 ### cloudbuild-default-timeout-60min-max-24h [IN] OBSERVATION Cloud Build default build timeout is 60 minutes; maximum is 24 hours (format: duration with `s` suffix). - Source: entries/2026/03/11/cloudbuild-build-config.md - Source hash: a29a3814882d14be - Date: 2026-03-11 ### cloudbuild-docker-engine-version-20-10-24 [IN] OBSERVATION Cloud Build currently uses Docker engine version 20.10.24. - Source: entries/2026/03/11/cloudbuild-overview.md - Source hash: c95bde686368b0fa - Date: 2026-03-11 ### cloudbuild-ephemeral-build-environment [IN] OBSERVATION Cloud Build provisions a fresh VM per build and destroys it after completion — no residual state persists. - Source: entries/2026/03/11/cloudbuild-overview.md - Source hash: c95bde686368b0fa - Date: 2026-03-11 ### cloudbuild-global-region-default-pool-only [IN] OBSERVATION Cloud Build `global` region uses default pools; specifying a specific region requires a private pool in that region. - Source: entries/2026/03/11/cloudbuild-triggers.md - Source hash: 5a5e64c8ea3403e8 - Date: 2026-03-11 ### cloudbuild-ignored-files-win-over-included [IN] OBSERVATION In Cloud Build triggers, if a file matches both included and ignored file filters, the build is not invoked (ignored wins). - Source: entries/2026/03/11/cloudbuild-triggers.md - Source hash: 5a5e64c8ea3403e8 - Date: 2026-03-11 ### cloudbuild-logs-default-both-logging-and-gcs [IN] OBSERVATION Cloud Build logs go to both Cloud Logging and Cloud Storage by default; `logging: GCS_ONLY` stores only in GCS. - Source: entries/2026/03/11/cloudbuild-build-config.md - Source hash: a29a3814882d14be - Date: 2026-03-11 ### cloudbuild-max-300-steps-100-args [IN] OBSERVATION Cloud Build config supports maximum 300 build steps per config file and up to 100 arguments per step. - Source: entries/2026/03/11/cloudbuild-build-config.md - Source hash: a29a3814882d14be - Date: 2026-03-11 ### cloudbuild-private-pool-64-machine-types [IN] OBSERVATION Cloud Build private pools support 64 machine types compared to 5 for default pools. - Source: entries/2026/03/11/cloudbuild-private-pools.md - Source hash: ea3d39d048e78fd8 - Date: 2026-03-11 ### cloudbuild-private-pool-disable-public-ip [IN] OBSERVATION Private pools can disable public IPs and provide static internal IP ranges; default pools cannot. - Source: entries/2026/03/11/cloudbuild-private-pools.md - Source hash: ea3d39d048e78fd8 - Date: 2026-03-11 ### cloudbuild-private-pool-region-fixed-at-creation [IN] OBSERVATION Private pool builds run in the region where the pool is created, not where the build is submitted. - Source: entries/2026/03/11/cloudbuild-private-pools.md - Source hash: ea3d39d048e78fd8 - Date: 2026-03-11 ### cloudbuild-private-pool-vpc-peering-access [IN] OBSERVATION Cloud Build private pools connect to customer VPC networks via VPC peering (private services access) to reach private resources. - Source: entries/2026/03/11/cloudbuild-private-pools.md - Source hash: ea3d39d048e78fd8 - Date: 2026-03-11 ### cloudbuild-queue-ttl-default-3600s [IN] OBSERVATION Cloud Build `queueTtl` defaults to 3600s (1 hour) and ticks from `createTime`, while `timeout` ticks from `startTime`. - Source: entries/2026/03/11/cloudbuild-build-config.md - Source hash: a29a3814882d14be - Date: 2026-03-11 ### cloudbuild-script-mutually-exclusive-args-entrypoint [IN] OBSERVATION Cloud Build step `script` field is mutually exclusive with `args` and `entrypoint`. - Source: entries/2026/03/11/cloudbuild-build-config.md - Source hash: a29a3814882d14be - Date: 2026-03-11 ### cloudbuild-shallow-clone-by-default [IN] OBSERVATION Cloud Build performs a shallow clone (single commit) by default; must use `git fetch --unshallow` build step for full history. - Source: entries/2026/03/11/cloudbuild-triggers.md - Source hash: 5a5e64c8ea3403e8 - Date: 2026-03-11 ### cloudbuild-skip-ci-commit-message [IN] OBSERVATION Including `[skip ci]` or `[ci skip]` in a commit message prevents Cloud Build trigger invocation. - Source: entries/2026/03/11/cloudbuild-triggers.md - Source hash: 5a5e64c8ea3403e8 - Date: 2026-03-11 ### cloudbuild-slsa-level-3-containers [IN] OBSERVATION Cloud Build meets SLSA level 3 requirements for container images with verifiable build provenance. - Source: entries/2026/03/11/cloudbuild-overview.md - Source hash: c95bde686368b0fa - Date: 2026-03-11 ### cloudbuild-steps-run-on-cloudbuild-network [IN] OBSERVATION Cloud Build steps run in Docker containers connected via the `cloudbuild` local Docker network, enabling inter-step communication. - Source: entries/2026/03/11/cloudbuild-overview.md - Source hash: c95bde686368b0fa - Date: 2026-03-11 ### cloudbuild-steps-serial-by-default [IN] OBSERVATION Cloud Build steps run serially by default; use `id` and `waitFor` fields for parallel execution (`waitFor: ['-']` starts immediately). - Source: entries/2026/03/11/cloudbuild-build-config.md - Source hash: a29a3814882d14be - Date: 2026-03-11 ### cloudbuild-supply-chain-security-ephemeral-attested [IN] OBSERVATION Cloud Build achieves supply chain security through three mechanisms: ephemeral build VMs with no residual state, SLSA level 3 attestation providing verifiable container provenance, and trigger service account precedence preventing config-level privilege escalation. ### cloudbuild-trigger-branch-tag-re2-regex [IN] OBSERVATION Cloud Build trigger branch and tag patterns use RE2 regex syntax; forward slashes cannot be used in tags. - Source: entries/2026/03/11/cloudbuild-triggers.md - Source hash: 5a5e64c8ea3403e8 - Date: 2026-03-11 ### cloudbuild-trigger-sa-overrides-config-sa [IN] OBSERVATION Cloud Build trigger service account overrides any service account specified in the build config file. - Source: entries/2026/03/11/cloudbuild-triggers.md - Source hash: 5a5e64c8ea3403e8 - Date: 2026-03-11 ### cloudbuild-user-substitution-keys-underscore-prefix [IN] OBSERVATION Cloud Build user-defined substitution keys must start with an underscore (`_`); `dynamicSubstitutions` must be `true` for bash parameter expansions with trigger-invoked builds. - Source: entries/2026/03/11/cloudbuild-build-config.md - Source hash: a29a3814882d14be - Date: 2026-03-11 ### cloudbuild-workspace-auto-mounted [IN] OBSERVATION The `/workspace` volume is automatically mounted in all Cloud Build steps; additional volumes must be explicitly declared. - Source: entries/2026/03/11/cloudbuild-build-config.md - Source hash: a29a3814882d14be - Date: 2026-03-11 ### cloudrun-authentication-services-not-jobs [IN] OBSERVATION Cloud Run authentication model applies to services only, not jobs. - Source: entries/2026/03/11/cloudrun-authentication.md - Source hash: 20e0f4c34529fc03 - Date: 2026-03-11 ### cloudrun-autoscaler-targets-60pct [IN] OBSERVATION Cloud Run autoscaler targets 60% CPU utilization and 60% of maximum concurrency, both measured over a one-minute window. - Source: entries/2026/03/11/cloudrun-scaling.md - Source hash: 0d0948f18d7bfc44 - Date: 2026-03-11 ### cloudrun-billing-100ms-granularity [IN] OBSERVATION Cloud Run usage is billed rounded up to the nearest 100 milliseconds; jobs have a minimum billing of 1 minute. - Source: entries/2026/03/11/cloudrun-pricing.md - Source hash: d08e2f3466642007 - Date: 2026-03-11 ### cloudrun-caches-image-at-deploy-time [IN] OBSERVATION Cloud Run imports and caches the container image at deploy time; images are not pulled from the registry when new instances start. - Source: entries/2026/03/11/cloudrun-services.md - Source hash: 50a9096068431906 - Date: 2026-03-11 ### cloudrun-compute-flexible-cuds-shared [IN] OBSERVATION Compute Flexible CUDs apply across Cloud Run, GKE, and Compute Engine; 3-year flexible CUD offers ~46% savings on CPU. - Source: entries/2026/03/11/cloudrun-pricing.md - Source hash: d08e2f3466642007 - Date: 2026-03-11 ### cloudrun-concurrency-1-hurts-spike-scaling [IN] OBSERVATION Setting Cloud Run concurrency to 1 negatively impacts scaling performance during traffic spikes due to cold start overhead per request. - Source: entries/2026/03/11/cloudrun-concurrency.md - Source hash: d70beec123ca2c56 - Date: 2026-03-11 ### cloudrun-concurrency-applies-to-services-only [IN] OBSERVATION The Cloud Run concurrency setting applies only to services (request-driven), not to jobs. - Source: entries/2026/03/11/cloudrun-concurrency.md - Source hash: d70beec123ca2c56 - Date: 2026-03-11 ### cloudrun-concurrency-default-80x-vcpus [IN] OBSERVATION Cloud Run default concurrency is 80× the number of vCPUs when deployed via gcloud/Terraform (new services only); 80 when deployed via Console. - Source: entries/2026/03/11/cloudrun-concurrency.md - Source hash: d70beec123ca2c56 - Date: 2026-03-11 ### cloudrun-concurrency-is-ceiling-not-target [IN] OBSERVATION The Cloud Run concurrency setting is a maximum limit (ceiling), not a guarantee — Cloud Run may send fewer requests if CPU is already highly utilized. - Source: entries/2026/03/11/cloudrun-concurrency.md - Source hash: d70beec123ca2c56 - Date: 2026-03-11 ### cloudrun-concurrency-max-1000 [IN] OBSERVATION Cloud Run maximum configurable concurrent requests per instance is 1000. - Source: entries/2026/03/11/cloudrun-concurrency.md - Source hash: d70beec123ca2c56 - Date: 2026-03-11 ### cloudrun-container-image-deterministic-at-deploy [IN] OBSERVATION Cloud Run achieves deterministic container execution by resolving image tags to digests and caching images at deploy time — revisions always serve the exact image deployed regardless of subsequent tag mutations in the registry or registry outages after deployment. ### cloudrun-cross-project-secret-uses-project-number [IN] OBSERVATION Cross-project secret references in Cloud Run use `projects/PROJECT_NUMBER/secrets/SECRET_NAME` format (project number, not ID, in YAML/gcloud; Terraform uses project ID). - Source: entries/2026/03/11/cloudrun-secrets.md - Source hash: 41bcbf47ce0f03af - Date: 2026-03-11 ### cloudrun-default-invoke-roles [IN] OBSERVATION Only four default roles can invoke a Cloud Run service: Project Owner, Project Editor, Cloud Run Admin, and Cloud Run Invoker (`roles/run.invoker`). - Source: entries/2026/03/11/cloudrun-authentication.md - Source hash: 20e0f4c34529fc03 - Date: 2026-03-11 ### cloudrun-deploy-required-roles [IN] OBSERVATION Deploying to Cloud Run requires `roles/run.developer`, `roles/iam.serviceAccountUser`, and `roles/artifactregistry.reader`; cross-project additionally needs `roles/iam.serviceAccountTokenCreator`. - Source: entries/2026/03/11/cloudrun-services.md - Source hash: 50a9096068431906 - Date: 2026-03-11 ### cloudrun-direct-vpc-egress-more-ip-addresses [IN] OBSERVATION Direct VPC egress uses more IP addresses than Serverless VPC Access connectors in most cases. - Source: entries/2026/03/11/cloudrun-vpc-access.md - Source hash: c993eed3ccfe0f6a - Date: 2026-03-11 ### cloudrun-direct-vpc-egress-network-tags-per-service [IN] OBSERVATION Direct VPC egress supports network tags per service/job revision for fine-grained firewall rules; connectors share tags across all services using the same connector. - Source: entries/2026/03/11/cloudrun-vpc-access.md - Source hash: c993eed3ccfe0f6a - Date: 2026-03-11 ### cloudrun-direct-vpc-egress-recommended [IN] OBSERVATION Direct VPC egress is the recommended method for Cloud Run outbound traffic to a VPC, requiring no connector VMs, with lower latency and scales to zero cost. - Source: entries/2026/03/11/cloudrun-vpc-access.md - Source hash: c993eed3ccfe0f6a - Date: 2026-03-11 ### cloudrun-docker-hub-cached-1-hour [IN] OBSERVATION Docker Hub images used by Cloud Run are cached for up to 1 hour. - Source: entries/2026/03/11/cloudrun-services.md - Source hash: 50a9096068431906 - Date: 2026-03-11 ### cloudrun-filesystem-ephemeral-in-memory [IN] OBSERVATION Cloud Run container instances have an ephemeral in-memory writable file system overlay that does not persist across shutdowns. - Source: entries/2026/03/11/cloudrun-overview.md - Source hash: 10575c9d6041bc4c - Date: 2026-03-11 ### cloudrun-free-tier-per-billing-account [IN] OBSERVATION The Cloud Run free tier is per billing account (not per project), aggregated across projects, and resets monthly. - Source: entries/2026/03/11/cloudrun-pricing.md - Source hash: d08e2f3466642007 - Date: 2026-03-11 ### cloudrun-gpu-no-cud-discounts [IN] OBSERVATION Cloud Run GPU workloads do not qualify for committed use discount (CUD) pricing. - Source: entries/2026/03/11/cloudrun-pricing.md - Source hash: d08e2f3466642007 - Date: 2026-03-11 ### cloudrun-iam-denied-requests-not-billed [IN] OBSERVATION Requests denied by IAM policy are not billed in Cloud Run. - Source: entries/2026/03/11/cloudrun-pricing.md - Source hash: d08e2f3466642007 - Date: 2026-03-11 ### cloudrun-idle-instance-retention-15min [IN] OBSERVATION Cloud Run idle instances may remain up to 15 minutes (10 minutes for GPU-enabled instances) after handling requests to absorb traffic spikes. - Source: entries/2026/03/11/cloudrun-scaling.md - Source hash: 0d0948f18d7bfc44 - Date: 2026-03-11 ### cloudrun-image-layer-size-limit-9-9gb [IN] OBSERVATION Cloud Run has a 9.9 GB max container image layer size when deploying from Docker Hub or Artifact Registry remote repository with an external registry. - Source: entries/2026/03/11/cloudrun-services.md - Source hash: 50a9096068431906 - Date: 2026-03-11 ### cloudrun-internet-egress-requires-vpc-plus-nat-chain [IN] OBSERVATION Cloud Run internet egress for VPC-connected workloads requires chaining two regional constructs: Direct VPC egress (preferred over connector VMs) for outbound-only VPC access, then Cloud NAT on Cloud Router for internet-bound traffic — neither alone is sufficient for serverless-to-internet connectivity. ### cloudrun-jobs-env-vars-task-index-count [IN] OBSERVATION Cloud Run jobs automatically inject `CLOUD_RUN_TASK_INDEX` (0-based) and `CLOUD_RUN_TASK_COUNT` environment variables per task. - Source: entries/2026/03/11/cloudrun-jobs.md - Source hash: c0c3c06ba79348d9 - Date: 2026-03-11 ### cloudrun-jobs-max-10000-tasks [IN] OBSERVATION A Cloud Run job supports 1–10,000 independent tasks that can run in parallel; default is 1 task. - Source: entries/2026/03/11/cloudrun-jobs.md - Source hash: c0c3c06ba79348d9 - Date: 2026-03-11 ### cloudrun-jobs-name-49-chars-immutable [IN] OBSERVATION Cloud Run job names must be 49 characters or less, unique per region and project, and cannot be changed after creation. - Source: entries/2026/03/11/cloudrun-jobs.md - Source hash: c0c3c06ba79348d9 - Date: 2026-03-11 ### cloudrun-jobs-retries-default-3-max-10 [IN] OBSERVATION Cloud Run jobs default to 3 retries per failed task, configurable from 0 to 10. - Source: entries/2026/03/11/cloudrun-jobs.md - Source hash: c0c3c06ba79348d9 - Date: 2026-03-11 ### cloudrun-jobs-second-gen-execution-env [IN] OBSERVATION Cloud Run jobs always use the second generation execution environment. - Source: entries/2026/03/11/cloudrun-jobs.md - Source hash: c0c3c06ba79348d9 - Date: 2026-03-11 ### cloudrun-jobs-task-timeout-default-10m-max-168h [IN] OBSERVATION Cloud Run job default task timeout is 10 minutes; maximum is 168 hours (7 days); GPU tasks have a maximum timeout of 1 hour. - Source: entries/2026/03/11/cloudrun-jobs.md - Source hash: c0c3c06ba79348d9 - Date: 2026-03-11 ### cloudrun-jobs-up-to-10-containers-per-instance [IN] OBSERVATION Cloud Run jobs support up to 10 containers per instance (including main container) as sidecars, sharing network namespace. - Source: entries/2026/03/11/cloudrun-jobs.md - Source hash: c0c3c06ba79348d9 - Date: 2026-03-11 ### cloudrun-max-instances-per-revision [IN] OBSERVATION Cloud Run max instances is a per-revision limit, not per service; traffic splits and deployments can cause total instances to exceed the per-revision limit. - Source: entries/2026/03/11/cloudrun-scaling.md - Source hash: 0d0948f18d7bfc44 - Date: 2026-03-11 ### cloudrun-pending-requests-timeout-429 [IN] OBSERVATION When Cloud Run max instances is reached, requests queue for up to 3.5× average container startup time or 10 seconds (whichever is greater); excess requests return HTTP 429. - Source: entries/2026/03/11/cloudrun-scaling.md - Source hash: 0d0948f18d7bfc44 - Date: 2026-03-11 ### cloudrun-pricing-tier1-vs-tier2-regions [IN] OBSERVATION Cloud Run pricing depends on region tier: Tier 1 (cheaper, includes us-central1, europe-west1) and Tier 2 (more expensive, includes Sydney, London, Frankfurt, São Paulo). - Source: entries/2026/03/11/cloudrun-pricing.md - Source hash: d08e2f3466642007 - Date: 2026-03-11 ### cloudrun-regional-redundant-across-zones [IN] OBSERVATION Cloud Run is regional — infrastructure runs in a specific region, redundantly available across all zones within that region. - Source: entries/2026/03/11/cloudrun-services.md - Source hash: 50a9096068431906 - Date: 2026-03-11 ### cloudrun-request-based-billing-is-default [IN] OBSERVATION Request-based billing is the default for Cloud Run services; instance-based billing must be opted into. - Source: entries/2026/03/11/cloudrun-pricing.md - Source hash: d08e2f3466642007 - Date: 2026-03-11 ### cloudrun-revisions-immutable-tag-resolved-to-digest [IN] OBSERVATION Cloud Run revisions are immutable; image tags are resolved to a digest at deploy time, and the revision always serves that specific digest. - Source: entries/2026/03/11/cloudrun-services.md - Source hash: 50a9096068431906 - Date: 2026-03-11 ### cloudrun-scale-from-zero-requires-request [IN] OBSERVATION Cloud Run scaling from zero can only be triggered by a request, not by CPU; CPU-only workloads with instance-based billing cannot self-wake without min instances > 0 or a wake-up request. - Source: entries/2026/03/11/cloudrun-scaling.md - Source hash: 0d0948f18d7bfc44 - Date: 2026-03-11 ### cloudrun-secret-env-var-failure-blocks-startup [IN] OBSERVATION If a Cloud Run environment variable secret fails to load, the instance will not start; volume mount failures only surface at read time. - Source: entries/2026/03/11/cloudrun-secrets.md - Source hash: 41bcbf47ce0f03af - Date: 2026-03-11 ### cloudrun-secret-env-var-resolved-at-startup [IN] OBSERVATION Cloud Run environment variable secrets are resolved once at instance startup time; Google recommends pinning to a specific version rather than `latest`. - Source: entries/2026/03/11/cloudrun-secrets.md - Source hash: 41bcbf47ce0f03af - Date: 2026-03-11 ### cloudrun-secret-fail-fast-startup [IN] OBSERVATION Cloud Run's Secret Manager integration creates fail-fast startup semantics: the recommended production pattern (API access with pinned versions) defers resolution to runtime, but env-var-bound secrets that fail to load prevent instance startup entirely — forcing a choice between startup reliability and the best-practice access pattern. ### cloudrun-secret-lifecycle-startup-rotation-tension [IN] OBSERVATION Cloud Run services reference Secret Manager secrets at startup, failing fast if secrets are unavailable. When secrets are rotated, running instances retain the old version until new instances are created, creating a window where old and new secret versions coexist across the fleet. ### cloudrun-secret-requires-secret-accessor-role [IN] OBSERVATION The Cloud Run service account needs `roles/secretmanager.secretAccessor` on each referenced secret, verified at deployment time. - Source: entries/2026/03/11/cloudrun-secrets.md - Source hash: 41bcbf47ce0f03af - Date: 2026-03-11 ### cloudrun-secret-volume-mount-fetches-on-read [IN] OBSERVATION Cloud Run volume-mounted secrets fetch the secret value from Secret Manager on every read, making them compatible with secret rotation. - Source: entries/2026/03/11/cloudrun-secrets.md - Source hash: 41bcbf47ce0f03af - Date: 2026-03-11 ### cloudrun-secret-volume-ownership-gen-difference [IN] OBSERVATION In Cloud Run first-gen single-container, the container identity owns the secret volume; in second-gen and first-gen multi-container, root owns the volume. - Source: entries/2026/03/11/cloudrun-secrets.md - Source hash: 41bcbf47ce0f03af - Date: 2026-03-11 ### cloudrun-service-name-49-char-limit-immutable [IN] OBSERVATION Cloud Run service names must be 49 characters or less, unique per region and project, and cannot be changed after creation. - Source: entries/2026/03/11/cloudrun-services.md - Source hash: 50a9096068431906 - Date: 2026-03-11 ### cloudrun-services-private-by-default [IN] OBSERVATION Cloud Run services are deployed as private by default, requiring authentication credentials in requests. - Source: entries/2026/03/11/cloudrun-authentication.md - Source hash: 20e0f4c34529fc03 - Date: 2026-03-11 ### cloudrun-services-replace-overwrites-entire-config [IN] OBSERVATION `gcloud run services replace` overwrites the entire service configuration — changes made via Console or gcloud CLI can be lost. - Source: entries/2026/03/11/cloudrun-services.md - Source hash: 50a9096068431906 - Date: 2026-03-11 ### cloudrun-services-run-app-endpoint [IN] OBSERVATION Cloud Run services provide a unique HTTPS endpoint on `*.run.app` with managed TLS, WebSockets, HTTP/2, and gRPC support. - Source: entries/2026/03/11/cloudrun-overview.md - Source hash: 10575c9d6041bc4c - Date: 2026-03-11 ### cloudrun-sidecar-cpu-summed [IN] OBSERVATION For Cloud Run instances with sidecars (multiple containers), instance CPU allocation is the sum of all container CPU limits. - Source: entries/2026/03/11/cloudrun-scaling.md - Source hash: 0d0948f18d7bfc44 - Date: 2026-03-11 ### cloudrun-source-deploy-uses-buildpacks [IN] OBSERVATION Cloud Run source-based deployment uses Google Cloud buildpacks (open source) and supports Go, Node.js, Python, Java, .NET, and Ruby. - Source: entries/2026/03/11/cloudrun-overview.md - Source hash: 10575c9d6041bc4c - Date: 2026-03-11 ### cloudrun-three-resource-types [IN] OBSERVATION Cloud Run has three resource types: services (HTTP request handling), jobs (batch tasks to completion), and worker pools (pull-based background processing, in Preview). - Source: entries/2026/03/11/cloudrun-overview.md - Source hash: 10575c9d6041bc4c - Date: 2026-03-11 ### cloudrun-two-billing-modes [IN] OBSERVATION Cloud Run services have two billing modes: request-based (charged only during request processing + per-request fee) and instance-based (charged for full instance lifetime, no per-request fee). - Source: entries/2026/03/11/cloudrun-overview.md - Source hash: 10575c9d6041bc4c - Date: 2026-03-11 ### cloudrun-update-vs-set-vs-clear-secrets [IN] OBSERVATION `--update-secrets` adds/updates secrets; `--set-secrets` replaces all secrets; `--clear-secrets` removes all; `--remove-secrets` removes specific ones. - Source: entries/2026/03/11/cloudrun-secrets.md - Source hash: 41bcbf47ce0f03af - Date: 2026-03-11 ### cloudrun-vcpu-hotspot-single-threaded [IN] OBSERVATION Single-threaded apps on multi-vCPU Cloud Run instances cause vCPU hotspots where average CPU looks low but one core is maxed, misleading the CPU autoscaler. - Source: entries/2026/03/11/cloudrun-concurrency.md - Source hash: d70beec123ca2c56 - Date: 2026-03-11 ### cloudrun-vpc-connector-uses-compute-engine-vms [IN] OBSERVATION Serverless VPC Access connectors require provisioned Compute Engine VM instances that add cost and maintenance overhead. - Source: entries/2026/03/11/cloudrun-vpc-access.md - Source hash: c993eed3ccfe0f6a - Date: 2026-03-11 ### cloudrun-vpc-egress-direct-over-connector [IN] OBSERVATION Cloud Run VPC egress should use Direct VPC egress over Serverless VPC Access connectors: direct egress requires no connector VMs (avoiding Compute Engine cost and maintenance), has lower latency, and both methods handle only outbound traffic. ### cloudrun-vpc-egress-outbound-only [IN] OBSERVATION Both Direct VPC egress and Serverless VPC Access connectors handle only outbound traffic from Cloud Run; inbound from VPC routes through a load balancer. - Source: entries/2026/03/11/cloudrun-vpc-access.md - Source hash: c993eed3ccfe0f6a - Date: 2026-03-11 ### cloudrun-worker-pools-no-autoscale-no-url [IN] OBSERVATION Cloud Run worker pools do not autoscale automatically (require manual scaling or custom autoscaler) and have no public HTTP endpoint or URL. - Source: entries/2026/03/11/cloudrun-overview.md - Source hash: 10575c9d6041bc4c - Date: 2026-03-11 ### cloudrun-worker-pools-split-instances-not-traffic [IN] OBSERVATION Cloud Run worker pools manage rollouts by splitting instances between revisions, not by splitting traffic. - Source: entries/2026/03/11/cloudrun-overview.md - Source hash: 10575c9d6041bc4c - Date: 2026-03-11 ### cloudsql-auth-proxy-recommended-connection [IN] OBSERVATION Cloud SQL Auth Proxy is the recommended secure connection method for applications connecting to Cloud SQL instances. - Source: entries/2026/03/10/cloudsql-overview.md - Source hash: 2bd5034f3001ebd1 - Date: 2026-03-11 ### cloudsql-backups-encrypted-by-default [IN] OBSERVATION Cloud SQL backups are encrypted by default using Google-managed or Customer-Managed Encryption Keys (CMEK). - Source: entries/2026/03/10/cloudsql-backups.md - Source hash: 2648ed3e2759e8e0 - Date: 2026-03-11 ### cloudsql-backups-incremental-after-first [IN] OBSERVATION All Cloud SQL backups after the first are incremental; when the oldest backup is deleted, the next oldest expands into a full backup. - Source: entries/2026/03/10/cloudsql-backups.md - Source hash: 2648ed3e2759e8e0 - Date: 2026-03-11 ### cloudsql-cascading-replicas-4-levels-8-siblings [IN] OBSERVATION Cascading replicas support up to 4 levels in the hierarchy (including primary) and up to 8 siblings per parent. - Source: entries/2026/03/10/cloudsql-replicas.md - Source hash: b1d358a760fa4fcc - Date: 2026-03-11 ### cloudsql-deleted-instance-recovery-4-days [IN] OBSERVATION Cloud SQL retains deleted instance backups for 4 days; Customer Care can restore with original IP address. - Source: entries/2026/03/10/cloudsql-backups.md - Source hash: 2648ed3e2759e8e0 - Date: 2026-03-11 ### cloudsql-enhanced-backups-use-backup-dr-service [IN] OBSERVATION Enhanced backups use Backup and DR Service for centralized management; standard backups are stored in the same project as the instance. - Source: entries/2026/03/10/cloudsql-backups.md - Source hash: 2648ed3e2759e8e0 - Date: 2026-03-11 ### cloudsql-enterprise-plus-sub-second-maintenance [IN] OBSERVATION Cloud SQL Enterprise Plus edition supports sub-second downtime during maintenance (for MySQL and PostgreSQL). - Source: entries/2026/03/10/cloudsql-overview.md - Source hash: 2bd5034f3001ebd1 - Date: 2026-03-11 ### cloudsql-final-backup-default-retention-30-days [IN] OBSERVATION Cloud SQL final backup default retention is 30 days; customizable 1–365 days (standard) or 1 day–10 years (enhanced). - Source: entries/2026/03/10/cloudsql-backups.md - Source hash: 2648ed3e2759e8e0 - Date: 2026-03-11 ### cloudsql-ha-costs-double [IN] OBSERVATION Cloud SQL HA instances cost 2x a standalone instance (CPU, RAM, and storage). - Source: entries/2026/03/10/cloudsql-ha.md - Source hash: 256e0a0fff84c083 - Date: 2026-03-11 ### cloudsql-ha-doubles-cost-with-idle-standby [IN] OBSERVATION Cloud SQL HA doubles infrastructure cost for automatic failover but the standby instance is idle — it cannot serve read queries, making read replicas in a third zone necessary for both read scaling and maximum resilience. ### cloudsql-ha-failover-60-seconds [IN] OBSERVATION Cloud SQL HA failover takes approximately 60 seconds of downtime. - Source: entries/2026/03/10/cloudsql-ha.md - Source hash: 256e0a0fff84c083 - Date: 2026-03-11 ### cloudsql-ha-primary-destroyed-on-failover [IN] OBSERVATION After Cloud SQL HA failover, the original primary is destroyed and recreated as the new standby. - Source: entries/2026/03/10/cloudsql-ha.md - Source hash: 256e0a0fff84c083 - Date: 2026-03-11 ### cloudsql-ha-read-replicas-third-zone-best-practice [IN] OBSERVATION Best practice is to place Cloud SQL read replicas in a third zone, different from both the primary and standby zones. - Source: entries/2026/03/10/cloudsql-ha.md - Source hash: 256e0a0fff84c083 - Date: 2026-03-11 ### cloudsql-ha-replicas-complementary-not-alternative [IN] OBSERVATION Cloud SQL HA and read replicas are complementary, not interchangeable: HA doubles cost with an idle standby for automatic failover, while replicas are strictly read-only without failover capability or independent backups — achieving both availability and read scaling requires deploying both patterns, ideally with replicas in a third zone. ### cloudsql-ha-same-ip-after-failover [IN] OBSERVATION Cloud SQL HA uses a shared static IP; applications reconnect using the same IP/connection string after failover. - Source: entries/2026/03/10/cloudsql-ha.md - Source hash: 256e0a0fff84c083 - Date: 2026-03-11 ### cloudsql-ha-standby-different-zone-same-region [IN] OBSERVATION Cloud SQL HA uses a standby VM in a different zone within the same region (not a different region). - Source: entries/2026/03/10/cloudsql-ha.md - Source hash: 256e0a0fff84c083 - Date: 2026-03-11 ### cloudsql-ha-standby-no-read-queries [IN] OBSERVATION The Cloud SQL HA standby instance cannot serve read queries. - Source: entries/2026/03/10/cloudsql-ha.md - Source hash: 256e0a0fff84c083 - Date: 2026-03-11 ### cloudsql-ha-synchronous-replication [IN] OBSERVATION Cloud SQL HA uses synchronous replication to regional persistent disk, not asynchronous replication. - Source: entries/2026/03/10/cloudsql-ha.md - Source hash: 256e0a0fff84c083 - Date: 2026-03-11 ### cloudsql-instance-vm-plus-persistent-disk [IN] OBSERVATION Each Cloud SQL instance runs on a dedicated VM with an attached persistent disk and a static IP address. - Source: entries/2026/03/10/cloudsql-overview.md - Source hash: 2bd5034f3001ebd1 - Date: 2026-03-11 ### cloudsql-legacy-ha-deprecated-jan-2025 [IN] OBSERVATION Cloud SQL legacy HA (failover replica-based) was deprecated January 13, 2025; automatic migration to regional persistent disk HA began May 1, 2025. - Source: entries/2026/03/10/cloudsql-ha.md - Source hash: 256e0a0fff84c083 - Date: 2026-03-11 ### cloudsql-ondemand-backups-retained-indefinitely [IN] OBSERVATION On-demand Cloud SQL backups (standard option) are retained indefinitely until explicitly deleted. - Source: entries/2026/03/10/cloudsql-backups.md - Source hash: 2648ed3e2759e8e0 - Date: 2026-03-11 ### cloudsql-private-ip-cannot-be-removed [IN] OBSERVATION Private IP cannot be removed from a Cloud SQL instance once configured. - Source: entries/2026/03/10/cloudsql-private-ip.md - Source hash: 55ac9f5a5847d9c1 - Date: 2026-03-11 ### cloudsql-private-ip-existing-instance-restart [IN] OBSERVATION Configuring private IP on an existing Cloud SQL instance causes a restart with a few minutes of downtime. - Source: entries/2026/03/10/cloudsql-private-ip.md - Source hash: 55ac9f5a5847d9c1 - Date: 2026-03-11 ### cloudsql-private-ip-inherits-peering-constraints [IN] OBSERVATION Cloud SQL private IP connectivity inherits all VPC peering limitations: non-transitivity restricts multi-network reach, non-RFC1918 ranges need manual authorization, and the required private services access creates an implicit peering dependency. ### cloudsql-private-ip-non-rfc1918-not-auto-authorized [IN] OBSERVATION Non-RFC 1918 address ranges are not automatically authorized for Cloud SQL private IP connections and are not learned via peering by default. - Source: entries/2026/03/10/cloudsql-private-ip.md - Source hash: 55ac9f5a5847d9c1 - Date: 2026-03-11 ### cloudsql-private-ip-replica-inherits-peering [IN] OBSERVATION A Cloud SQL replica inherits its private IP status and VPC peering configuration from the primary instance. - Source: entries/2026/03/10/cloudsql-private-ip.md - Source hash: 55ac9f5a5847d9c1 - Date: 2026-03-11 ### cloudsql-private-ip-requires-compute-network-admin [IN] OBSERVATION Cloud SQL private IP setup requires `roles/compute.networkAdmin` for managing private services access and the Service Networking API must be enabled. - Source: entries/2026/03/10/cloudsql-private-ip.md - Source hash: 55ac9f5a5847d9c1 - Date: 2026-03-11 ### cloudsql-private-ip-requires-vpc [IN] OBSERVATION Cloud SQL private IP connectivity requires a VPC network; public IP is internet-accessible. - Source: entries/2026/03/10/cloudsql-overview.md - Source hash: 2bd5034f3001ebd1 - Date: 2026-03-11 ### cloudsql-private-ip-slash24-per-service [IN] OBSERVATION Each Google Cloud service creates a /24 subnet from the customer's allocated IP range; a /24 supports approximately 50 Cloud SQL instances. - Source: entries/2026/03/10/cloudsql-private-ip.md - Source hash: 55ac9f5a5847d9c1 - Date: 2026-03-11 ### cloudsql-private-ip-uses-private-services-access [IN] OBSERVATION Cloud SQL private IP uses private services access to create private connections between a customer's VPC and Google's service producer VPC. - Source: entries/2026/03/10/cloudsql-private-ip.md - Source hash: 55ac9f5a5847d9c1 - Date: 2026-03-11 ### cloudsql-private-ip-vpc-peering-not-transitive [IN] OBSERVATION VPC Network Peering used by Cloud SQL private IP is not transitive — only directly peered networks can communicate. - Source: entries/2026/03/10/cloudsql-private-ip.md - Source hash: 55ac9f5a5847d9c1 - Date: 2026-03-11 ### cloudsql-private-networking-doubly-constrained-by-peering [IN] OBSERVATION Cloud SQL private IP connectivity inherits VPC peering constraints (non-transitivity, 25 peering limit, non-RFC1918 allocation restrictions) from private services access, adding networking complexity beyond what the database service itself requires. ### cloudsql-production-architecture-requires-triple-investment [IN] OBSERVATION Production Cloud SQL architecture requires concurrent investment across three dimensions: HA doubles cost with an idle standby that cannot serve reads, read replicas add scaling but block backup restores and cannot failover, and private networking inherits VPC peering constraints (non-transitivity, no overlapping subnets) — making the path from standalone instance to production-ready database a multiplicative increase in cost, complexity, and networking constraints. ### cloudsql-production-high-cost-floor-low-scaling-ceiling [IN] OBSERVATION Cloud SQL production architecture has simultaneously high cost floor and low scaling ceiling: the triple investment baseline (2x HA cost with idle standby, read replicas for scaling, private networking with peering constraints) creates a significant minimum infrastructure cost, while read scaling is capped at 10 direct replicas that cannot be independently backed up and provide no failover — bounding both the entry cost and maximum throughput of a production deployment. ### cloudsql-replicas-cannot-delete-primary-with-replicas [IN] OBSERVATION Cannot delete a Cloud SQL primary instance without first promoting or deleting all its replicas. - Source: entries/2026/03/10/cloudsql-replicas.md - Source hash: b1d358a760fa4fcc - Date: 2026-03-11 ### cloudsql-replicas-cannot-restore-backup-with-replicas [IN] OBSERVATION Cannot restore a Cloud SQL primary from backup while replicas exist. - Source: entries/2026/03/10/cloudsql-replicas.md - Source hash: b1d358a760fa4fcc - Date: 2026-03-11 ### cloudsql-replicas-constrained-read-scaling [IN] OBSERVATION Cloud SQL read replicas provide constrained read scaling: maximum 10 direct replicas per primary, replicas cannot be backed up independently, replicas are strictly read-only with no failover capability, and creating replicas requires backups and binary logging enabled on the primary. ### cloudsql-replicas-gtid-mandatory [IN] OBSERVATION Cloud SQL uses GTID-based replication for all replication; it cannot be disabled. - Source: entries/2026/03/10/cloudsql-replicas.md - Source hash: b1d358a760fa4fcc - Date: 2026-03-11 ### cloudsql-replicas-max-10-direct [IN] OBSERVATION Maximum of 10 direct read replicas per Cloud SQL primary instance; cascading replicas allow scaling beyond this limit. - Source: entries/2026/03/10/cloudsql-replicas.md - Source hash: b1d358a760fa4fcc - Date: 2026-03-11 ### cloudsql-replicas-no-backup-support [IN] OBSERVATION Cloud SQL replicas do not support backups; backups are maintained on the primary instance only. Promoted replicas need their own backup configuration. - Source: entries/2026/03/10/cloudsql-backups.md - Source hash: 2648ed3e2759e8e0 - Date: 2026-03-11 ### cloudsql-replicas-no-backups-on-replicas [IN] OBSERVATION Backups cannot be configured on Cloud SQL read replicas. - Source: entries/2026/03/10/cloudsql-replicas.md - Source hash: b1d358a760fa4fcc - Date: 2026-03-11 ### cloudsql-replicas-read-only-no-failover [IN] OBSERVATION Cloud SQL read replicas are read-only and do not provide failover — HA configuration is required for failover. - Source: entries/2026/03/10/cloudsql-replicas.md - Source hash: b1d358a760fa4fcc - Date: 2026-03-11 ### cloudsql-replicas-require-backups-and-binlog [IN] OBSERVATION Creating a read replica requires automated backups enabled, binary logging (PITR) enabled, and at least one backup after binary logging was enabled. - Source: entries/2026/03/10/cloudsql-replicas.md - Source hash: b1d358a760fa4fcc - Date: 2026-03-11 ### cloudsql-restore-requires-same-db-version [IN] OBSERVATION Cloud SQL restores can only target instances with the same database version as when the backup was taken. - Source: entries/2026/03/10/cloudsql-backups.md - Source hash: 2648ed3e2759e8e0 - Date: 2026-03-11 ### cloudsql-supports-three-engines [IN] OBSERVATION Cloud SQL supports exactly three database engines: MySQL, PostgreSQL, and SQL Server. - Source: entries/2026/03/10/cloudsql-overview.md - Source hash: 2bd5034f3001ebd1 - Date: 2026-03-11 ### cloudsql-three-update-types [IN] OBSERVATION Cloud SQL has three system update types: hardware updates (no downtime, live migration), online updates (no downtime), and maintenance updates (require restart, cause downtime). - Source: entries/2026/03/10/cloudsql-overview.md - Source hash: 2bd5034f3001ebd1 - Date: 2026-03-11 ### cmek-autokey-creates-hsm-keys-by-default [IN] OBSERVATION Cloud KMS Autokey automatically creates Cloud HSM keys by default; Autokey keys are functionally identical to manually created Cloud HSM keys. - Source: entries/2026/03/11/kms-cmek.md - Source hash: a934d829cc4a501b - Date: 2026-03-11 ### cmek-crypto-shredding-destroys-data [IN] OBSERVATION Destroying a CMEK makes all data encrypted by it permanently inaccessible, enabling crypto-shredding for off-boarding or security remediation. - Source: entries/2026/03/11/kms-cmek.md - Source hash: a934d829cc4a501b - Date: 2026-03-11 ### cmek-customer-owns-keys-envelope-encryption [IN] OBSERVATION CMEK uses server-side, symmetric, envelope encryption with customer-controlled 256-bit AES-GCM keys; key material never leaves the Cloud KMS system boundary. - Source: entries/2026/03/11/kms-cmek.md - Source hash: a934d829cc4a501b - Date: 2026-03-11 ### cmek-key-ring-location-near-resources-separate-project [IN] OBSERVATION CMEK key ring location should be geographically near protected resources; using a separate project for keys supports separation of duties. - Source: entries/2026/03/11/kms-cmek.md - Source hash: a934d829cc4a501b - Date: 2026-03-11 ### cmek-revoking-access-or-disabling-key-makes-data-inaccessible [IN] OBSERVATION Revoking the service agent's CryptoKey Encrypter/Decrypter role, or disabling/destroying the CMEK key, makes data inaccessible — some services can experience permanent data loss if the key remains inaccessible too long. - Source: entries/2026/03/11/kms-cmek.md - Source hash: a934d829cc4a501b - Date: 2026-03-11 ### cmek-service-agent-encrypts-not-end-user [IN] OBSERVATION Each project's service agent performs CMEK encrypt/decrypt operations; end users do not need the CryptoKey Encrypter/Decrypter role to access CMEK-protected resources. - Source: entries/2026/03/11/kms-cmek.md - Source hash: a934d829cc4a501b - Date: 2026-03-11 ### dedicated-interconnect-99-9-sla-requires-2-connections-same-metro [IN] OBSERVATION Dedicated Interconnect 99.9% SLA requires at least 2 connections in the same metro but in different edge availability domains. - Source: entries/2026/03/11/interconnect-dedicated.md - Source hash: 53d4fb4d154f8172 - Date: 2026-03-11 ### dedicated-interconnect-99-99-sla-requires-4-connections-2-metros [IN] OBSERVATION Dedicated Interconnect 99.99% SLA requires at least 4 connections: 2 in each of 2 different metros, each pair in different edge availability domains. - Source: entries/2026/03/11/interconnect-dedicated.md - Source hash: 53d4fb4d154f8172 - Date: 2026-03-11 ### dedicated-interconnect-circuit-types-10g-100g-400g [IN] OBSERVATION Dedicated Interconnect supports 10-Gbps (10GBASE-LR), 100-Gbps (100GBASE-LR4), and 400-Gbps (400GBASE-LR4) circuits, all single-mode fiber with max 10 km fiber length. - Source: entries/2026/03/11/interconnect-dedicated.md - Source hash: 53d4fb4d154f8172 - Date: 2026-03-11 ### dedicated-interconnect-google-api-traffic-always-1440-mtu [IN] OBSERVATION Google API client library traffic always uses 1440 MTU regardless of the VLAN attachment MTU setting on Dedicated Interconnect. - Source: entries/2026/03/11/interconnect-dedicated.md - Source hash: 53d4fb4d154f8172 - Date: 2026-03-11 ### dedicated-interconnect-jumbo-frames-unencrypted-only [IN] OBSERVATION Jumbo frames (8896 MTU) on Dedicated Interconnect are only supported on unencrypted VLAN attachments. - Source: entries/2026/03/11/interconnect-dedicated.md - Source hash: 53d4fb4d154f8172 - Date: 2026-03-11 ### dedicated-interconnect-lacp-required [IN] OBSERVATION LACP is required for Dedicated Interconnect even for a single circuit. - Source: entries/2026/03/11/interconnect-dedicated.md - Source hash: 53d4fb4d154f8172 - Date: 2026-03-11 ### dedicated-interconnect-link-type-immutable [IN] OBSERVATION Dedicated Interconnect link type (e.g., 10G, 100G, 400G) cannot be changed after connection creation — a new connection must be created. - Source: entries/2026/03/11/interconnect-dedicated.md - Source hash: 53d4fb4d154f8172 - Date: 2026-03-11 ### dedicated-interconnect-max-8-circuits-per-connection [IN] OBSERVATION Dedicated Interconnect supports 1–8 circuits per connection, yielding max 80 Gbps (10G), 800 Gbps (100G), or 3200 Gbps (400G) per connection. - Source: entries/2026/03/11/interconnect-dedicated.md - Source hash: 53d4fb4d154f8172 - Date: 2026-03-11 ### default-route-deletion-does-not-fully-isolate [IN] OBSERVATION Deleting the system-generated default route (0.0.0.0/0) does not fully isolate a VPC from the internet because external passthrough NLB paths are independent of it. - Source: entries/2026/03/10/vpc-routes.md - Source hash: 5ea29512bcefff8c - Date: 2026-03-11 ### dynamic-routing-mode-regional-vs-global [IN] OBSERVATION Dynamic routing mode (regional vs global) determines whether Cloud Router dynamic routes apply in one region or all regions. - Source: entries/2026/03/10/vpc-routes.md - Source hash: 5ea29512bcefff8c - Date: 2026-03-11 ### ekm-coordinated-keys-require-vpc-connection [IN] OBSERVATION Coordinated (Cloud KMS-managed) EKM keys require a VPC connection; manual mode is required for internet connections. - Source: entries/2026/03/11/kms-ekm.md - Source hash: 7d83508956eb12e9 - Date: 2026-03-11 ### ekm-double-encryption-symmetric-keys [IN] OBSERVATION Cloud EKM symmetric encryption uses both internal key material (Cloud KMS) and external key material (EKM) — losing either makes data permanently unrecoverable. - Source: entries/2026/03/11/kms-ekm.md - Source hash: 7d83508956eb12e9 - Date: 2026-03-11 ### ekm-external-key-material-never-leaves-customer [IN] OBSERVATION Cloud EKM external key material never leaves the customer's EKM and is never sent to Google. - Source: entries/2026/03/11/kms-ekm.md - Source hash: 7d83508956eb12e9 - Date: 2026-03-11 ### ekm-key-access-justifications-reason-codes [IN] OBSERVATION Key Access Justifications optionally integrates with Cloud EKM so each request includes a reason code, and the EKM can allow or deny based on justification. - Source: entries/2026/03/11/kms-ekm.md - Source hash: 7d83508956eb12e9 - Date: 2026-03-11 ### ekm-no-auto-rotation-manual-keys [IN] OBSERVATION Automatic rotation is not supported for manually managed external keys; only coordinated EKM keys support automatic rotation. - Source: entries/2026/03/11/kms-ekm.md - Source hash: 7d83508956eb12e9 - Date: 2026-03-11 ### ekm-protection-levels-external-vs-external-vpc [IN] OBSERVATION Cloud EKM has two protection levels: EXTERNAL (internet) and EXTERNAL_VPC (VPC); VPC mode is available in regional locations only, not multi-regional. - Source: entries/2026/03/11/kms-ekm.md - Source hash: 7d83508956eb12e9 - Date: 2026-03-11 ### ext-nlb-backends-same-region-project-different-vpc [IN] OBSERVATION External passthrough NLB backends must be in the same region and project but can be in different VPC networks. - Source: entries/2026/03/10/lb-tcp-udp.md - Source hash: e2b912f095c82ab7 - Date: 2026-03-11 ### ext-nlb-direct-server-return [IN] OBSERVATION External passthrough Network Load Balancers use direct server return (DSR) — responses bypass the load balancer and go directly from backend VMs to clients. - Source: entries/2026/03/10/lb-tcp-udp.md - Source hash: e2b912f095c82ab7 - Date: 2026-03-11 ### ext-nlb-ipv6-requires-premium-tier [IN] OBSERVATION External passthrough NLB IPv6 support requires Premium Tier and uses `/96` ranges from external dual-stack subnets. - Source: entries/2026/03/10/lb-tcp-udp.md - Source hash: e2b912f095c82ab7 - Date: 2026-03-11 ### ext-nlb-l3-default-one-per-ip [IN] OBSERVATION Only one `L3_DEFAULT` forwarding rule is allowed per IP address; it acts as a fallback when more specific forwarding rules exist. - Source: entries/2026/03/10/lb-tcp-udp.md - Source hash: e2b912f095c82ab7 - Date: 2026-03-11 ### ext-nlb-neg-any-nic-ig-nic0-only [IN] OBSERVATION External passthrough NLB instance groups always use `nic0`; zonal NEGs (`GCE_VM_IP`) can target any network interface. - Source: entries/2026/03/10/lb-tcp-udp.md - Source hash: e2b912f095c82ab7 - Date: 2026-03-11 ### ext-nlb-traffic-steering-source-ip-ranges [IN] OBSERVATION External passthrough NLB traffic steering uses `sourceIPRanges` on forwarding rules (up to 64 ranges) with a mandatory parent forwarding rule. - Source: entries/2026/03/10/lb-tcp-udp.md - Source hash: e2b912f095c82ab7 - Date: 2026-03-11 ### external-ipv6-requires-premium-tier [IN] OBSERVATION External IPv6 addresses on VPC subnets require Premium Tier networking. - Source: entries/2026/03/10/vpc-subnets.md - Source hash: 0a93f184ecf6ad03 - Date: 2026-03-11 ### gce-arm-instances-no-smt-vcpu-equals-core [IN] OBSERVATION Arm-based instances (N4A, C4A, T2A) have no SMT — each vCPU equals one physical core. - Source: entries/2026/03/10/gce-machine-types.md - Source hash: 6e997a0fb4698f8c - Date: 2026-03-11 ### gce-autohealing-health-checks-more-conservative [IN] OBSERVATION MIG autohealing health checks should be more conservative than load balancing health checks; autohealing triggers VM recreation while LB health checks only route traffic away. - Source: entries/2026/03/10/gce-instance-groups.md - Source hash: db6e9fd593b64baf - Date: 2026-03-11 ### gce-bare-metal-identified-by-metal-suffix [IN] OBSERVATION Bare metal instances are identified by machine type names ending in `-metal` and run without a hypervisor. - Source: entries/2026/03/10/gce-instances.md - Source hash: 552533b39f99e3b9 - Date: 2026-03-11 ### gce-community-images-no-google-support [IN] OBSERVATION Community-supported OS images (Fedora, FreeBSD, openSUSE) have no licensing charges but no Google support. - Source: entries/2026/03/10/gce-images.md - Source hash: 29bfc170013b9556 - Date: 2026-03-11 ### gce-container-on-mig-uses-cos-with-docker [IN] OBSERVATION Container deployment on MIGs uses Container-Optimized OS with Docker, provisioned automatically when a container image is specified in the instance template. - Source: entries/2026/03/10/gce-instance-groups.md - Source hash: db6e9fd593b64baf - Date: 2026-03-11 ### gce-custom-images-incur-storage-charges [IN] OBSERVATION Custom OS images incur image storage charges in the project that owns them. - Source: entries/2026/03/10/gce-images.md - Source hash: 29bfc170013b9556 - Date: 2026-03-11 ### gce-custom-images-storage-charges-only [IN] OBSERVATION Custom OS images only incur storage charges; premium OS images have additional cost - Source: entries/2026/03/10/gce-overview.md - Source hash: 9c6d0e11aef4dcb1 - Date: 2026-03-11 ### gce-custom-machine-types-n-e-series-only [IN] OBSERVATION Custom machine types are only available for N and E series, with a 5% price premium over predefined types. - Source: entries/2026/03/10/gce-machine-types.md - Source hash: 6e997a0fb4698f8c - Date: 2026-03-11 ### gce-disk-billed-provisioned-capacity-creation-to-deletion [IN] OBSERVATION Block storage is billed for provisioned capacity from creation to deletion, even if the disk is unattached or the VM is stopped. - Source: entries/2026/03/10/gce-disks.md - Source hash: 99390eba1dbdd961 - Date: 2026-03-11 ### gce-durable-disks-attach-detach-no-downtime [IN] OBSERVATION Durable disks can be attached to and detached from running instances without downtime. - Source: entries/2026/03/10/gce-disks.md - Source hash: 99390eba1dbdd961 - Date: 2026-03-11 ### gce-durable-disks-encrypted-at-rest-and-transit [IN] OBSERVATION Durable block storage is encrypted at rest and in transit by default, with support for customer-managed encryption keys. - Source: entries/2026/03/10/gce-disks.md - Source hash: 99390eba1dbdd961 - Date: 2026-03-11 ### gce-durable-disks-network-attached [IN] OBSERVATION Durable block storage (Hyperdisk and Persistent Disk) are network-attached devices transmitting data over Google's networks, not physically attached like Local SSD. - Source: entries/2026/03/10/gce-disks.md - Source hash: 99390eba1dbdd961 - Date: 2026-03-11 ### gce-e2-lowest-cost-auto-selected-processor [IN] OBSERVATION E2 is the lowest-cost machine series; the processor (Intel or AMD) is auto-selected by Google. - Source: entries/2026/03/10/gce-machine-types.md - Source hash: 6e997a0fb4698f8c - Date: 2026-03-11 ### gce-ephemeral-compute-storage-workload-tier [IN] OBSERVATION GCE provides a fully ephemeral high-performance workload tier by combining Spot/preemptible VMs (possible preemption, no live migration, configurable stop-or-delete) with Local SSD (data lost on any VM lifecycle event, cannot be boot volume), creating a distinct operational model suitable only for stateless batch processing, cache warming, or ML training with external checkpointing. ### gce-five-machine-families [IN] OBSERVATION Compute Engine has five machine families: General-purpose, Compute-optimized, Storage-optimized, Memory-optimized, and Accelerator-optimized. - Source: entries/2026/03/10/gce-machine-types.md - Source hash: 6e997a0fb4698f8c - Date: 2026-03-11 ### gce-google-recommends-hyperdisk-over-pd [IN] OBSERVATION Google recommends Hyperdisk over Persistent Disk for new workloads; Persistent Disk is not available with the latest machine series. - Source: entries/2026/03/10/gce-disks.md - Source hash: 99390eba1dbdd961 - Date: 2026-03-11 ### gce-gpu-series-mapping [IN] OBSERVATION GPU mapping: A4/A4X → B200/B300, A3 → H100/H200, A2 → A100, G2 → L4, G4 → RTX PRO 6000. - Source: entries/2026/03/10/gce-machine-types.md - Source hash: 6e997a0fb4698f8c - Date: 2026-03-11 ### gce-hpc-images-in-cloud-hpc-image-public [IN] OBSERVATION HPC-optimized images are located in the `cloud-hpc-image-public` project. - Source: entries/2026/03/10/gce-images.md - Source hash: 29bfc170013b9556 - Date: 2026-03-11 ### gce-hyperdisk-performance-independent-of-size [IN] OBSERVATION Hyperdisk performance (IOPS, throughput) can be configured independently of disk size, unlike Persistent Disk where performance is tied to provisioned capacity. - Source: entries/2026/03/10/gce-disks.md - Source hash: 99390eba1dbdd961 - Date: 2026-03-11 ### gce-hyperdisk-supports-dynamic-resize [IN] OBSERVATION Hyperdisk supports dynamic resize and configurable performance; it is faster than Persistent Disk - Source: entries/2026/03/10/gce-overview.md - Source hash: 9c6d0e11aef4dcb1 - Date: 2026-03-11 ### gce-image-families-point-to-latest-non-deprecated [IN] OBSERVATION Image families always point to the latest non-deprecated image version; rollback works by deprecating the current latest image. - Source: entries/2026/03/10/gce-images.md - Source hash: 29bfc170013b9556 - Date: 2026-03-11 ### gce-instance-default-timezone-utc [IN] OBSERVATION All Compute Engine instances default to UTC time zone regardless of region. - Source: entries/2026/03/10/gce-instances.md - Source hash: 552533b39f99e3b9 - Date: 2026-03-11 ### gce-instance-nic-unique-vpc-constraint [IN] OBSERVATION Each instance network interface must be in a subnet of a unique VPC network — two NICs cannot be in the same VPC. - Source: entries/2026/03/10/gce-instances.md - Source hash: 552533b39f99e3b9 - Date: 2026-03-11 ### gce-instances-are-zonal-resources [IN] OBSERVATION Compute Engine instances are zonal resources — a zone must be specified at creation time. - Source: entries/2026/03/10/gce-instances.md - Source hash: 552533b39f99e3b9 - Date: 2026-03-11 ### gce-local-ssd-cannot-be-boot-volume [IN] OBSERVATION Local SSD cannot be used as a boot volume; boot volumes require durable block storage (Hyperdisk or Persistent Disk). - Source: entries/2026/03/10/gce-disks.md - Source hash: 99390eba1dbdd961 - Date: 2026-03-11 ### gce-local-ssd-data-lost-on-stop [IN] OBSERVATION Local SSD data is lost on VM stop, suspend, restart, crash, or host failure — it is ephemeral storage. - Source: entries/2026/03/10/gce-disks.md - Source hash: 99390eba1dbdd961 - Date: 2026-03-11 ### gce-local-ssd-ephemeral-high-performance-tier [IN] OBSERVATION Local SSDs in GCE are ephemeral storage that cannot serve as boot volumes — data is lost on instance stop, providing a storage tier with strict lifecycle coupling to the instance. ### gce-machine-type-naming-convention [IN] OBSERVATION Machine type naming follows `{series}-{ratio}-{vcpus}` pattern, with optional `-lssd` (local SSD) or `-metal` (bare metal) suffixes. - Source: entries/2026/03/10/gce-machine-types.md - Source hash: 6e997a0fb4698f8c - Date: 2026-03-11 ### gce-metadata-client-cert-valid-7-days [IN] OBSERVATION The HTTPS MDS client identity certificate is valid for 7 days and must be refreshed - Source: entries/2026/03/10/gce-metadata.md - Source hash: 7821f3e42231a230 - Date: 2026-03-11 ### gce-metadata-custom-keys-case-sensitive [IN] OBSERVATION GCE custom metadata keys are case-sensitive - Source: entries/2026/03/10/gce-metadata.md - Source hash: 7821f3e42231a230 - Date: 2026-03-11 ### gce-metadata-host-local-always-accessible-with-rotation [IN] OBSERVATION The GCE metadata server is always accessible regardless of firewall rules, never routes requests off the physical host, but HTTPS access requires client certificate rotation every 7 days — security depends on timely credential refresh, not network controls. ### gce-metadata-https-requires-shielded-vm [IN] OBSERVATION HTTPS metadata server endpoints are only available on Shielded VMs - Source: entries/2026/03/10/gce-metadata.md - Source hash: 7821f3e42231a230 - Date: 2026-03-11 ### gce-metadata-linux-cert-path [IN] OBSERVATION On Linux, GCE HTTPS MDS certificates are stored at /run/google-mds-mtls/ (root.crt and client.key) - Source: entries/2026/03/10/gce-metadata.md - Source hash: 7821f3e42231a230 - Date: 2026-03-11 ### gce-metadata-requests-never-leave-host [IN] OBSERVATION Requests to the GCE metadata server never leave the physical host running the VM - Source: entries/2026/03/10/gce-metadata.md - Source hash: 7821f3e42231a230 - Date: 2026-03-11 ### gce-metadata-root-cert-rotated-on-stop-start [IN] OBSERVATION The HTTPS MDS self-signed root certificate (valid 50 years) is rotated on every instance stop/start cycle - Source: entries/2026/03/10/gce-metadata.md - Source hash: 7821f3e42231a230 - Date: 2026-03-11 ### gce-metadata-server-link-local-ipv4 [IN] OBSERVATION The GCE metadata server is accessible at the link-local IPv4 address 169.254.169.254 - Source: entries/2026/03/10/gce-metadata.md - Source hash: 7821f3e42231a230 - Date: 2026-03-11 ### gce-metadata-zonal-overrides-project [IN] OBSERVATION When the same custom metadata key exists at both project and zonal levels, the zonal value takes precedence for VMs in that zone - Source: entries/2026/03/10/gce-metadata.md - Source hash: 7821f3e42231a230 - Date: 2026-03-11 ### gce-mig-default-limits-1000-zonal-2000-regional [IN] OBSERVATION Default VM limits are 1,000 for zonal MIGs and 2,000 for regional MIGs. - Source: entries/2026/03/10/gce-instance-groups.md - Source hash: db6e9fd593b64baf - Date: 2026-03-11 ### gce-minimum-slo-99-9-percent [IN] OBSERVATION Compute Engine has a minimum uptime SLO of 99.9% - Source: entries/2026/03/10/gce-overview.md - Source hash: 9c6d0e11aef4dcb1 - Date: 2026-03-11 ### gce-no-extra-charge-for-instance-groups [IN] OBSERVATION There is no additional charge for instance groups themselves; billing is only for the underlying resources. - Source: entries/2026/03/10/gce-instance-groups.md - Source hash: db6e9fd593b64baf - Date: 2026-03-11 ### gce-oracle-linux-partner-supported-no-license-charge [IN] OBSERVATION Oracle Linux on GCE is partner-supported (by Oracle, not Google) with no licensing charges. - Source: entries/2026/03/10/gce-images.md - Source hash: 29bfc170013b9556 - Date: 2026-03-11 ### gce-os-login-integrates-ssh-with-iam [IN] OBSERVATION OS Login integrates SSH key management with IAM roles, providing admin vs non-admin access control. - Source: entries/2026/03/10/gce-instances.md - Source hash: 552533b39f99e3b9 - Date: 2026-03-11 ### gce-predefined-memory-ratios [IN] OBSERVATION Predefined machine type memory ratios: highcpu ~2GB/vCPU, standard ~4GB/vCPU, highmem ~8GB/vCPU, megamem ~14GB/vCPU, ultramem 24-31GB/vCPU, hypermem ~16GB/vCPU. - Source: entries/2026/03/10/gce-machine-types.md - Source hash: 6e997a0fb4698f8c - Date: 2026-03-11 ### gce-preemptible-30-second-shutdown-window [IN] OBSERVATION Preemptible VMs receive an ACPI G2 Soft Off signal giving up to 30 seconds (best effort) for shutdown scripts before forced termination - Source: entries/2026/03/10/gce-preemptible.md - Source hash: aca81c29ffc1d1d9 - Date: 2026-03-11 ### gce-preemptible-gpu-no-advance-notice [IN] OBSERVATION Standard GPU instances get 1-hour advance notice before maintenance; preemptible GPU instances do not - Source: entries/2026/03/10/gce-preemptible.md - Source hash: aca81c29ffc1d1d9 - Date: 2026-03-11 ### gce-preemptible-max-24-hours [IN] OBSERVATION Compute Engine always terminates preemptible VMs after 24 hours of continuous running - Source: entries/2026/03/10/gce-preemptible.md - Source hash: aca81c29ffc1d1d9 - Date: 2026-03-11 ### gce-preemptible-no-billing-first-minute [IN] OBSERVATION Preemptible VMs are not billed for instance usage if preempted within 1 minute of creation (premium OS charges still apply) - Source: entries/2026/03/10/gce-preemptible.md - Source hash: aca81c29ffc1d1d9 - Date: 2026-03-11 ### gce-preemptible-no-live-migration [IN] OBSERVATION Preemptible VMs cannot live migrate and cannot be set to automatically restart on maintenance events - Source: entries/2026/03/10/gce-preemptible.md - Source hash: aca81c29ffc1d1d9 - Date: 2026-03-11 ### gce-preemptible-premium-os-not-discounted [IN] OBSERVATION Premium OS image costs are not discounted on preemptible VMs - Source: entries/2026/03/10/gce-preemptible.md - Source hash: aca81c29ffc1d1d9 - Date: 2026-03-11 ### gce-preemptible-stop-resets-timer-reboot-does-not [IN] OBSERVATION Stopping and starting a preemptible VM resets the 24-hour counter; rebooting or resetting does not - Source: entries/2026/03/10/gce-preemptible.md - Source hash: aca81c29ffc1d1d9 - Date: 2026-03-11 ### gce-public-images-available-all-projects [IN] OBSERVATION Public OS images are available to all GCP projects by default with no special configuration needed. - Source: entries/2026/03/10/gce-images.md - Source hash: 29bfc170013b9556 - Date: 2026-03-11 ### gce-queue-based-autoscaling-zonal-mig-only [IN] OBSERVATION Queue-based autoscaling using Pub/Sub is only available for zonal MIGs, not regional MIGs. - Source: entries/2026/03/10/gce-instance-groups.md - Source hash: db6e9fd593b64baf - Date: 2026-03-11 ### gce-regional-mig-protects-against-zonal-failure [IN] OBSERVATION Regional MIGs deploy instances across multiple zones in a region, protecting against zonal failure; zonal MIGs do not. - Source: entries/2026/03/10/gce-instance-groups.md - Source hash: db6e9fd593b64baf - Date: 2026-03-11 ### gce-sole-tenant-billed-for-node-not-vms [IN] OBSERVATION Sole-tenant nodes are billed for node vCPU/memory with no extra charge for VMs on the node; GPUs and Local SSD billed separately - Source: entries/2026/03/10/gce-sole-tenancy.md - Source hash: 7fac723a4bacaa62 - Date: 2026-03-11 ### gce-sole-tenant-cpu-overcommit-n1-n2-n2d-n4-only [IN] OBSERVATION CPU overcommit on sole-tenant nodes is supported only on N1, N2, N2D, and N4 series - Source: entries/2026/03/10/gce-sole-tenancy.md - Source hash: 7fac723a4bacaa62 - Date: 2026-03-11 ### gce-sole-tenant-dedicated-but-constrained [IN] OBSERVATION GCE sole-tenant nodes provide physical server isolation with significant operational constraints: one-to-one physical server mapping ensures no co-tenancy, but nodes are billed at node level regardless of VM utilization, preemptible VMs are not supported, and maintenance windows are immutable 4-hour blocks fixed at creation. ### gce-sole-tenant-holdback-nodes-1-per-20 [IN] OBSERVATION Migrate-within-node-group policy requires 1 holdback node per 20 nodes, with a minimum of 2 nodes in the group - Source: entries/2026/03/10/gce-sole-tenancy.md - Source hash: 7fac723a4bacaa62 - Date: 2026-03-11 ### gce-sole-tenant-maintenance-window-4-hours-immutable [IN] OBSERVATION Sole-tenant maintenance windows are 4-hour blocks set at node group creation and cannot be changed afterward - Source: entries/2026/03/10/gce-sole-tenancy.md - Source hash: 7fac723a4bacaa62 - Date: 2026-03-11 ### gce-sole-tenant-no-preemptible-vms [IN] OBSERVATION Preemptible VMs are not supported on sole-tenant nodes - Source: entries/2026/03/10/gce-sole-tenancy.md - Source hash: 7fac723a4bacaa62 - Date: 2026-03-11 ### gce-sole-tenant-node-one-to-one-physical-server [IN] OBSERVATION Each sole-tenant node maps one-to-one to a physical server dedicated to a single project's VMs - Source: entries/2026/03/10/gce-sole-tenancy.md - Source hash: 7fac723a4bacaa62 - Date: 2026-03-11 ### gce-sole-tenant-three-maintenance-policies [IN] OBSERVATION Sole-tenant nodes support three host maintenance policies: default (migrate to any node), restart in place (same physical server, ~1hr downtime), and migrate within node group - Source: entries/2026/03/10/gce-sole-tenancy.md - Source hash: 7fac723a4bacaa62 - Date: 2026-03-11 ### gce-spot-preemptible-operational-constraints [IN] OBSERVATION Preemptible VMs have strict operational constraints: 24-hour maximum lifetime, no live migration, and no automatic restart on maintenance. Spot VMs offer similar cost savings (up to 91% discount) with flexible termination actions (stop or delete) but no mandatory maximum runtime. ### gce-spot-preemptible-quota-mandatory-once-granted [IN] OBSERVATION Once dedicated preemptible quota is granted in a region, Spot VMs in that region must use it and cannot fall back to standard quota - Source: entries/2026/03/10/gce-spot-vms.md - Source hash: acd691a508a28143 - Date: 2026-03-11 ### gce-spot-vm-no-mandatory-max-runtime [IN] OBSERVATION Unlike preemptible VMs (24-hour limit), Spot VMs have no mandatory maximum runtime - Source: entries/2026/03/10/gce-spot-vms.md - Source hash: acd691a508a28143 - Date: 2026-03-11 ### gce-spot-vm-prices-change-up-to-once-per-day [IN] OBSERVATION Spot VM prices can change up to once per day - Source: entries/2026/03/10/gce-spot-vms.md - Source hash: acd691a508a28143 - Date: 2026-03-11 ### gce-spot-vm-termination-action-stop-or-delete [IN] OBSERVATION Spot VM termination action is configurable: STOP (default, VM goes to TERMINATED) or DELETE (VM is removed) - Source: entries/2026/03/10/gce-spot-vms.md - Source hash: acd691a508a28143 - Date: 2026-03-11 ### gce-spot-vm-unsupported-a4x-bare-metal [IN] OBSERVATION Spot VMs are not supported on A4X machine series or bare metal instances - Source: entries/2026/03/10/gce-spot-vms.md - Source hash: acd691a508a28143 - Date: 2026-03-11 ### gce-spot-vm-up-to-91-percent-discount [IN] OBSERVATION Spot VMs offer up to 91% discount compared to standard VM pricing - Source: entries/2026/03/10/gce-spot-vms.md - Source hash: acd691a508a28143 - Date: 2026-03-11 ### gce-stateful-mig-preserves-name-disks-metadata [IN] OBSERVATION Stateful MIGs preserve instance name, attached persistent disks, and metadata across restart, recreation, and update events. - Source: entries/2026/03/10/gce-instance-groups.md - Source hash: db6e9fd593b64baf - Date: 2026-03-11 ### gce-unmanaged-ig-no-automation [IN] OBSERVATION Unmanaged instance groups do not support autoscaling, autohealing, rolling updates, multi-zone deployment, or instance templates — they only serve as load balancing targets. - Source: entries/2026/03/10/gce-instance-groups.md - Source hash: db6e9fd593b64baf - Date: 2026-03-11 ### gce-uses-kvm-hypervisor [IN] OBSERVATION Compute Engine VMs run on a KVM hypervisor - Source: entries/2026/03/10/gce-overview.md - Source hash: 9c6d0e11aef4dcb1 - Date: 2026-03-11 ### gce-x4-memory-optimized-up-to-32tb [IN] OBSERVATION Memory-optimized X4 machine type scales up to 32 TB of memory and 1,920 vCPUs (bare metal). - Source: entries/2026/03/10/gce-machine-types.md - Source hash: 6e997a0fb4698f8c - Date: 2026-03-11 ### gce-z3-up-to-72tib-titanium-ssd [IN] OBSERVATION Z3 storage-optimized series provides up to 72 TiB Titanium SSD on bare metal. - Source: entries/2026/03/10/gce-machine-types.md - Source hash: 6e997a0fb4698f8c - Date: 2026-03-11 ### gclb-backend-services-over-target-pools [IN] OBSERVATION For new external passthrough NLB deployments, backend services are recommended over target pools. - Source: entries/2026/03/10/lb-overview.md - Source hash: 0ff2d6741e4c818f - Date: 2026-03-11 ### gclb-cloud-armor-advanced-ddos-passthrough-only [IN] OBSERVATION Cloud Armor advanced network DDoS protection is only available for external passthrough Network Load Balancers. - Source: entries/2026/03/10/lb-overview.md - Source hash: 0ff2d6741e4c818f - Date: 2026-03-11 ### gclb-no-prewarming-required [IN] OBSERVATION Google Cloud Load Balancing requires no pre-warming — scales from zero to full traffic in seconds and handles instantaneous traffic spikes. - Source: entries/2026/03/10/lb-overview.md - Source hash: 0ff2d6741e4c818f - Date: 2026-03-11 ### gclb-passthrough-preserves-source-ip [IN] OBSERVATION Passthrough load balancers preserve client source IP; proxy load balancers do not (backends see the proxy's IP). - Source: entries/2026/03/10/lb-overview.md - Source hash: 0ff2d6741e4c818f - Date: 2026-03-11 ### gclb-underlying-technologies [IN] OBSERVATION Google Cloud LBs use: GFE for classic ALB/proxy NLB, Envoy-based GFE for global external ALB/proxy NLB, Envoy for regional/cross-region LBs, Maglev for external passthrough NLB, and Andromeda for internal passthrough NLB. - Source: entries/2026/03/10/lb-overview.md - Source hash: 0ff2d6741e4c818f - Date: 2026-03-11 ### gcp-assured-workloads-compliance [IN] OBSERVATION Assured Workloads is the key GCP product for regulatory and compliance needs. - Source: entries/2026/03/10/arch-security.md - Source hash: 6c536c54a0ff68cb - Date: 2026-03-11 ### gcp-data-services-require-per-service-protection-engineering [IN] OBSERVATION GCP data protection is a per-service engineering effort, not a platform abstraction: Cloud SQL requires triple investment (HA + replicas + private networking) with each dimension independently constrained, while GCS requires defense in depth across three orthogonal dimensions (object immutability with versioned recovery, namespace security with organizational controls, four-tier encryption) — neither service's protection model transfers to the other. ### gcp-immutability-comprehensive-networking-and-services [IN] OBSERVATION GCP immutability is comprehensive across both networking infrastructure (HA VPN stack type, Cloud VPN ciphers, Dedicated Interconnect link type, IPv6 access type) and service infrastructure (Artifact Registry format/mode, KMS key rings, Workload Identity pool format, Cloud SQL private IP), requiring correctness-at-creation across all resource layers since no corrective post-creation path exists for any of these configurations. ### gcp-immutable-infrastructure-decisions-require-upfront-design [IN] OBSERVATION Multiple GCP services enforce immutable-after-creation configuration that cannot be corrected without resource recreation: Artifact Registry locks format and mode, KMS cannot delete key rings or change key type/purpose/protection, GKE Workload Identity pool is not deletable, and Cloud SQL private IP cannot be removed — establishing a cross-service pattern where initial design mistakes are permanently embedded in the resource hierarchy. ### gcp-networking-immutable-after-creation [IN] OBSERVATION GCP networking configuration is broadly immutable after resource creation: HA VPN gateway stack type (IPv4/IPv6), Cloud VPN cipher options, Dedicated Interconnect link type (10G/100G/400G), and subnet IPv6 access type (internal/external) all require resource deletion and recreation to change, making network architecture decisions permanent commitments that cannot be corrected in place. ### gcp-observability-blind-spots-at-security-boundaries [IN] OBSERVATION GCP observability has systematic blind spots at security boundaries despite robust defaults: VPC Flow Logs miss ingress-denied packets while capturing egress-denied ones (creating a firewall visibility gap exactly at the attack surface), AND Cloud Logging export has temporal gaps (sinks not retroactive, Cloud Storage sink latency in hours) — the combination means network-layer security incidents at the ingress boundary may have neither real-time flow data nor timely log exports for forensic reconstruction. ### gcp-observability-default-infrastructure-is-robust [IN] OBSERVATION GCP provides robust default observability without explicit instrumentation: Cloud Monitoring auto-collects metrics for most services without agents, Cloud Logging routes entries through per-resource Log Routers with immutable `_Required` sinks for compliance, and VPC Flow Logs introduce no performance impact — baseline visibility is available out-of-box, and the compliance audit trail cannot be disabled. ### gcp-perf-autoscaling-dual-purpose [IN] OBSERVATION Autoscaling serves dual purposes: performance predictability (prevents overload) and cost reduction (removes idle resources). - Source: entries/2026/03/10/arch-performance.md - Source hash: 5f358286b4fb0f43 - Date: 2026-03-11 ### gcp-perf-optimization-four-stages [IN] OBSERVATION The performance optimization cycle has four stages: define requirements, design and deploy, monitor and analyze, optimize — and it is continuous. - Source: entries/2026/03/10/arch-performance.md - Source hash: 5f358286b4fb0f43 - Date: 2026-03-11 ### gcp-perf-requirements-per-layer [IN] OBSERVATION Performance requirements should be defined per layer of the application stack, not just at the application level. - Source: entries/2026/03/10/arch-performance.md - Source hash: 5f358286b4fb0f43 - Date: 2026-03-11 ### gcp-private-data-services-universal-connectivity-tax [IN] OBSERVATION GCP private data services like Cloud SQL and Memorystore require private IP connectivity that inherits VPC peering constraints (non-transitivity, peering limits), creating a connectivity overhead for each private data service adopted. ### gcp-reliability-four-focus-areas [IN] OBSERVATION The reliability pillar has four focus areas: Scoping, Observation, Response, and Learning. - Source: entries/2026/03/10/arch-reliability.md - Source hash: 253ba0e3c9b4406f - Date: 2026-03-11 ### gcp-reliability-nine-core-principles [IN] OBSERVATION The reliability pillar has nine core principles including: define reliability based on UX goals, set realistic targets, resource redundancy, horizontal scalability, observability, graceful degradation, test recovery from failures, test recovery from data loss, and conduct postmortems. - Source: entries/2026/03/10/arch-reliability.md - Source hash: 253ba0e3c9b4406f - Date: 2026-03-11 ### gcp-reliability-organizational-concern [IN] OBSERVATION Reliability is an organizational concern shared by dev, product, ops, platform eng, SRE, and business teams — not just engineering. - Source: entries/2026/03/10/arch-reliability.md - Source hash: 253ba0e3c9b4406f - Date: 2026-03-11 ### gcp-reliability-vs-resilience-definitions [IN] OBSERVATION Reliability is consistent performance of intended functions plus uninterrupted service; resilience is the ability to withstand and recover from failures (a subset of reliability). - Source: entries/2026/03/10/arch-reliability.md - Source hash: 253ba0e3c9b4406f - Date: 2026-03-11 ### gcp-secret-rotation-achieves-zero-downtime [IN] OBSERVATION KMS key rotation and Secret Manager version pinning together enable zero-downtime secret and key rotation: KMS rotation creates new versions without re-encrypting existing data (ciphertext self-identifies its key version), and the recommended Secret Manager access pattern (API-direct with pinned version numbers) allows applications to transition between secret versions without restart — achieving non-disruptive credential rotation across the platform. ### gcp-security-eight-focus-areas [IN] OBSERVATION The security pillar has eight focus areas: infrastructure security, IAM, data security, AI/ML security, SecOps, application security, governance/risk/compliance, and logging/auditing/monitoring. - Source: entries/2026/03/10/arch-security.md - Source hash: 6c536c54a0ff68cb - Date: 2026-03-11 ### gcp-security-seven-core-principles [IN] OBSERVATION The security pillar has seven core principles: security by design, zero trust, shift-left security, preemptive cyber defense, use AI securely, use AI for security, and regulatory/compliance/privacy. - Source: entries/2026/03/10/arch-security.md - Source hash: 6c536c54a0ff68cb - Date: 2026-03-11 ### gcp-security-shared-responsibility-model [IN] OBSERVATION Cloud security uses a shared responsibility model — Google secures infrastructure; the customer secures workloads, data, and access. - Source: entries/2026/03/10/arch-security.md - Source hash: 6c536c54a0ff68cb - Date: 2026-03-11 ### gcp-shift-left-tools [IN] OBSERVATION Shift-left security tools in GCP include Cloud Build, Binary Authorization, and Artifact Registry. - Source: entries/2026/03/10/arch-security.md - Source hash: 6c536c54a0ff68cb - Date: 2026-03-11 ### gcp-waf-applies-to-hybrid-multicloud [IN] OBSERVATION The Well-Architected Framework applies to cloud-native, migration, hybrid, and multi-cloud scenarios — not just greenfield cloud builds. - Source: entries/2026/03/10/arch-framework.md - Source hash: 9a6a3ab02e0412e6 - Date: 2026-03-11 ### gcp-waf-decoupled-architecture-benefits [IN] OBSERVATION Decoupled architectures enable independent upgrades, security controls, reliability goals, health monitoring, and granular cost/performance control. - Source: entries/2026/03/10/arch-framework.md - Source hash: 9a6a3ab02e0412e6 - Date: 2026-03-11 ### gcp-waf-perspectives-cross-pillar [IN] OBSERVATION Well-Architected Framework Perspectives are cross-pillar views for specific technologies, domains, or sectors — they are not additional pillars. - Source: entries/2026/03/10/arch-framework.md - Source hash: 9a6a3ab02e0412e6 - Date: 2026-03-11 ### gcp-waf-six-pillars [IN] OBSERVATION The Google Cloud Well-Architected Framework has six pillars: Operational Excellence, Security/Privacy/Compliance, Reliability, Cost Optimization, Performance Optimization, and Sustainability. - Source: entries/2026/03/10/arch-framework.md - Source hash: 9a6a3ab02e0412e6 - Date: 2026-03-11 ### gcp-waf-stateless-architecture-benefits [IN] OBSERVATION Stateless architecture enables reliability and scalability by allowing applications to scale quickly with minimum boot dependencies and withstand hard restarts. - Source: entries/2026/03/10/arch-framework.md - Source hash: 9a6a3ab02e0412e6 - Date: 2026-03-11 ### gcp-zero-trust-iap-chrome-enterprise [IN] OBSERVATION Zero trust is implemented via Chrome Enterprise Premium and Identity-Aware Proxy (IAP). - Source: entries/2026/03/10/arch-security.md - Source hash: 6c536c54a0ff68cb - Date: 2026-03-11 ### gcs-all-classes-11-nines-durability [IN] OBSERVATION All Cloud Storage classes share 99.999999999% (eleven 9s) annual durability. - Source: entries/2026/03/10/gcs-storage-classes.md - Source hash: 66b923eff1d7f475 - Date: 2026-03-11 ### gcs-archive-millisecond-access [IN] OBSERVATION Archive storage class provides millisecond-latency access, unlike competing cloud providers' cold tiers which may take hours/days. - Source: entries/2026/03/10/gcs-storage-classes.md - Source hash: 66b923eff1d7f475 - Date: 2026-03-11 ### gcs-bucket-dot-names-require-domain-verification [IN] OBSERVATION Bucket names containing dots require domain ownership verification. - Source: entries/2026/03/10/gcs-buckets.md - Source hash: 90f1e6408c5d452b - Date: 2026-03-11 ### gcs-bucket-name-location-immutable [IN] OBSERVATION Bucket name and location are set at creation and cannot be changed afterward. - Source: entries/2026/03/10/gcs-buckets.md - Source hash: 90f1e6408c5d452b - Date: 2026-03-11 ### gcs-bucket-names-globally-unique-public [IN] OBSERVATION GCS bucket names are in a single global namespace — every name must be globally unique and is publicly visible. - Source: entries/2026/03/10/gcs-buckets.md - Source hash: 90f1e6408c5d452b - Date: 2026-03-11 ### gcs-bucket-naming-rules [IN] OBSERVATION Bucket names must be 3–63 characters, lowercase letters/numbers/dashes/underscores/dots only, cannot begin with `goog`, cannot contain `google`, and cannot be an IP address in dotted-decimal notation. - Source: entries/2026/03/10/gcs-buckets.md - Source hash: 90f1e6408c5d452b - Date: 2026-03-11 ### gcs-buckets-cannot-be-nested [IN] OBSERVATION GCS buckets cannot be nested inside other buckets. - Source: entries/2026/03/10/gcs-buckets.md - Source hash: 90f1e6408c5d452b - Date: 2026-03-11 ### gcs-change-object-class-two-methods [IN] OBSERVATION Two ways to change an object's storage class: rewrite the object or use Object Lifecycle Management. - Source: entries/2026/03/10/gcs-storage-classes.md - Source hash: 66b923eff1d7f475 - Date: 2026-03-11 ### gcs-changing-default-class-not-retroactive [IN] OBSERVATION Changing a bucket's default storage class does not affect existing objects — they retain their original class. - Source: entries/2026/03/10/gcs-storage-classes.md - Source hash: 66b923eff1d7f475 - Date: 2026-03-11 ### gcs-client-side-encryption-double-layer [IN] OBSERVATION Client-side encrypted data is also encrypted server-side, resulting in layered encryption. - Source: entries/2026/03/10/gcs-encryption.md - Source hash: 6f7450ce9bf015e7 - Date: 2026-03-11 ### gcs-cmek-three-backends [IN] OBSERVATION CMEK supports three key storage backends: software, HSM, and external (EKM). - Source: entries/2026/03/10/gcs-encryption.md - Source hash: 6f7450ce9bf015e7 - Date: 2026-03-11 ### gcs-cmek-vs-csek-storage [IN] OBSERVATION CMEK keys are stored in Cloud KMS (Google stores them, customer manages them); CSEK keys are provided per-request and never stored by Google. - Source: entries/2026/03/10/gcs-encryption.md - Source hash: 6f7450ce9bf015e7 - Date: 2026-03-11 ### gcs-credential-access-boundaries-downscope [IN] OBSERVATION Credential Access Boundaries downscope OAuth 2.0 tokens to limit access to specific buckets and permission sets. - Source: entries/2026/03/10/gcs-access-control.md - Source hash: d2f2886b902f4c66 - Date: 2026-03-11 ### gcs-data-protection-requires-defense-in-depth [IN] OBSERVATION GCS data protection requires defense in depth across three independent dimensions: object-level protection (immutable objects with versioned recovery but noncurrent versions readable and bucket deletion unprotected), namespace-level security (globally unique bucket names enabling enumeration with parallel IAM/ACL surfaces), and encryption tiering (four levels from Google-managed to client-side with increasing control and decreasing unconditional durability) — each dimension addresses a different threat model and no single mechanism provides complete protection. ### gcs-default-encryption-always-on [IN] OBSERVATION All GCS data is encrypted at rest by default using Google-managed keys at no additional charge. - Source: entries/2026/03/10/gcs-encryption.md - Source hash: 6f7450ce9bf015e7 - Date: 2026-03-11 ### gcs-default-storage-class-standard [IN] OBSERVATION The default storage class for a bucket is Standard if not specified at creation. - Source: entries/2026/03/10/gcs-storage-classes.md - Source hash: 66b923eff1d7f475 - Date: 2026-03-11 ### gcs-deleted-bucket-name-reuse-risk [IN] OBSERVATION After bucket deletion, anyone can reuse the name (usually within seconds); deleting the project may hold the name for weeks or longer. - Source: entries/2026/03/10/gcs-buckets.md - Source hash: 90f1e6408c5d452b - Date: 2026-03-11 ### gcs-disabling-versioning-keeps-noncurrent [IN] OBSERVATION Disabling Object Versioning stops new noncurrent versions from accumulating but does not delete existing noncurrent versions. - Source: entries/2026/03/10/gcs-versioning.md - Source hash: a183a381e3109985 - Date: 2026-03-11 ### gcs-encryption-control-order [IN] OBSERVATION The four GCS encryption options in order of increasing customer control: Default → CMEK → CSEK → Client-side. - Source: entries/2026/03/10/gcs-encryption.md - Source hash: 6f7450ce9bf015e7 - Date: 2026-03-11 ### gcs-encryption-four-tier-defense [IN] OBSERVATION GCS provides a four-tier encryption model (default, CMEK, CSEK, client-side) with increasing customer control, all built on always-on default encryption — but customer-managed keys (CSEK/client-side) shift the key loss risk entirely to the customer. ### gcs-flat-namespace-no-real-folders [IN] OBSERVATION Flat namespace GCS buckets have no real folders — folders are simulated via `/` delimiters in object names. - Source: entries/2026/03/10/gcs-objects.md - Source hash: ee2898c31828e7e2 - Date: 2026-03-11 ### gcs-fuse-mount-as-filesystem [IN] OBSERVATION Cloud Storage FUSE enables mounting buckets as local file systems for standard file I/O. - Source: entries/2026/03/10/gcs-overview.md - Source hash: dd2c4c31b60dabdb - Date: 2026-03-11 ### gcs-generation-zero-means-latest [IN] OBSERVATION Generation number `#0` in a Cloud Storage resource name refers to the most recent version of an object. - Source: entries/2026/03/10/gcs-overview.md - Source hash: dd2c4c31b60dabdb - Date: 2026-03-11 ### gcs-hns-8x-higher-qps [IN] OBSERVATION Hierarchical namespace (HNS) enabled buckets provide up to 8x higher initial QPS for reads/writes compared to flat-namespace buckets. - Source: entries/2026/03/10/gcs-overview.md - Source hash: dd2c4c31b60dabdb - Date: 2026-03-11 ### gcs-iam-acl-parallel [IN] OBSERVATION IAM and ACLs operate in parallel on GCS — if either system grants access, the user gets access. - Source: entries/2026/03/10/gcs-access-control.md - Source hash: d2f2886b902f4c66 - Date: 2026-03-11 ### gcs-lifecycle-abort-multipart-limited-conditions [IN] OBSERVATION AbortIncompleteMultipartUpload lifecycle action can only use `age`, `matchesPrefix`, and `matchesSuffix` conditions. - Source: entries/2026/03/10/gcs-lifecycle.md - Source hash: 691ae5c09938e24e - Date: 2026-03-11 ### gcs-lifecycle-age-zero-midnight-utc [IN] OBSERVATION Lifecycle condition `age: 0` is satisfied at midnight UTC after object creation, not immediately. - Source: entries/2026/03/10/gcs-lifecycle.md - Source hash: 691ae5c09938e24e - Date: 2026-03-11 ### gcs-lifecycle-config-24h-propagation [IN] OBSERVATION Lifecycle configuration changes can take up to 24 hours to take effect. - Source: entries/2026/03/10/gcs-lifecycle.md - Source hash: 691ae5c09938e24e - Date: 2026-03-11 ### gcs-lifecycle-delete-beats-setstorageclass [IN] OBSERVATION When both Delete and SetStorageClass lifecycle rules match simultaneously, Delete takes precedence. - Source: entries/2026/03/10/gcs-lifecycle.md - Source hash: 691ae5c09938e24e - Date: 2026-03-11 ### gcs-lifecycle-economics-vs-evaluation-complexity [IN] OBSERVATION GCS lifecycle management creates an economics-complexity tension: storage class pricing strongly incentivizes automated transitions (no retrieval fees for Standard/Rapid, no rewrite on SetStorageClass, minimum durations creating cost penalties for wrong placement), but lifecycle rule evaluation has complex precedence (Delete beats SetStorageClass), timing (age 0 means midnight UTC, not creation time), and hold semantics (holds block deletion even when conditions match) that can produce unexpected results. ### gcs-lifecycle-holds-block-delete [IN] OBSERVATION Objects under holds or retention policies are not deleted by lifecycle rules even if conditions are met. - Source: entries/2026/03/10/gcs-lifecycle.md - Source hash: 691ae5c09938e24e - Date: 2026-03-11 ### gcs-lifecycle-precedence-timing-complexity [IN] OBSERVATION GCS lifecycle rules have complex evaluation semantics: Delete takes precedence over SetStorageClass when both match, holds and retention policies block lifecycle deletions, age-0 triggers at midnight UTC (not immediately), and each rule uses multi-condition AND logic. ### gcs-lifecycle-rule-one-action-multiple-conditions [IN] OBSERVATION Each lifecycle rule has exactly one action and one or more conditions; an object must match all conditions in a rule for the action to fire. - Source: entries/2026/03/10/gcs-lifecycle.md - Source hash: 691ae5c09938e24e - Date: 2026-03-11 ### gcs-lifecycle-setstorageclass-no-rewrite [IN] OBSERVATION SetStorageClass lifecycle action does not rewrite the object — no retrieval fees, early deletion fees, or inter-region replication charges. - Source: entries/2026/03/10/gcs-lifecycle.md - Source hash: 691ae5c09938e24e - Date: 2026-03-11 ### gcs-lost-csek-key-permanent-data-loss [IN] OBSERVATION Losing a CSEK or client-side encryption key results in unrecoverable data; objects remain stored and billed until explicitly deleted. - Source: entries/2026/03/10/gcs-encryption.md - Source hash: 6f7450ce9bf015e7 - Date: 2026-03-11 ### gcs-managed-folders-permissions-only [IN] OBSERVATION Managed folders are resource overlays used solely for granting/revoking IAM permissions, not true directory structures. - Source: entries/2026/03/10/gcs-overview.md - Source hash: dd2c4c31b60dabdb - Date: 2026-03-11 ### gcs-namespace-security-requires-organizational-controls [IN] OBSERVATION GCS bucket namespace has a multi-layered security surface beyond IAM: bucket names are globally unique and publicly visible (enabling enumeration), deleted bucket names can be immediately reused by anyone (enabling squatting), and IAM and ACLs operate in parallel where either granting access is sufficient — requiring organizational controls (naming conventions, deletion policies, uniform bucket-level access) to prevent namespace-level exposure. ### gcs-no-retrieval-fees-rapid-standard [IN] OBSERVATION Rapid and Standard storage classes have no retrieval fees; Nearline, Coldline, and Archive have retrieval fees. - Source: entries/2026/03/10/gcs-storage-classes.md - Source hash: 66b923eff1d7f475 - Date: 2026-03-11 ### gcs-noncurrent-objects-readable-soft-deleted-not [IN] OBSERVATION Noncurrent versioned objects are readable; soft-deleted objects are not — this is a key differentiator between the features. - Source: entries/2026/03/10/gcs-versioning.md - Source hash: a183a381e3109985 - Date: 2026-03-11 ### gcs-object-identity-name-plus-generation [IN] OBSERVATION An object is uniquely identified within a bucket by its name combined with a generation number. - Source: entries/2026/03/10/gcs-objects.md - Source hash: ee2898c31828e7e2 - Date: 2026-03-11 ### gcs-object-immutability-with-versioned-recovery [IN] OBSERVATION GCS objects are immutable with atomic replacement; versioning and soft delete (default 7 days) provide recovery, but noncurrent versions are readable while soft-deleted objects are not — and both features require careful timing (30-second wait after config changes). ### gcs-object-name-max-1024-bytes [IN] OBSERVATION Object name maximum size is 1024 bytes in flat namespace, or 512 bytes each for folder name and base name in hierarchical namespace (HNS). - Source: entries/2026/03/10/gcs-objects.md - Source hash: ee2898c31828e7e2 - Date: 2026-03-11 ### gcs-object-one-update-per-second-limit [IN] OBSERVATION GCS enforces a once-per-second rate limit for replacing the same object; exceeding this yields `429 Too Many Requests`. - Source: entries/2026/03/10/gcs-objects.md - Source hash: ee2898c31828e7e2 - Date: 2026-03-11 ### gcs-objects-are-immutable [IN] OBSERVATION Cloud Storage objects are immutable pieces of data stored in buckets. - Source: entries/2026/03/10/gcs-overview.md - Source hash: dd2c4c31b60dabdb - Date: 2026-03-11 ### gcs-objects-immutable [IN] OBSERVATION GCS objects are immutable — they cannot be modified in place; replacement is atomic with the old version served until the new upload completes. - Source: entries/2026/03/10/gcs-objects.md - Source hash: ee2898c31828e7e2 - Date: 2026-03-11 ### gcs-performance-engineering-requires-name-and-class-awareness [IN] OBSERVATION GCS performance engineering requires simultaneous awareness of naming patterns and storage class constraints: sequential object names cause backend hotspotting, hierarchical namespace buckets provide up to 8x higher QPS, individual objects enforce a once-per-second update limit, and Rapid class is restricted to zonal-only buckets with storage size quotas. ### gcs-public-access-prevention-blocks-allusers [IN] OBSERVATION Public access prevention blocks access via `allUsers` and `allAuthenticatedUsers` principals. - Source: entries/2026/03/10/gcs-access-control.md - Source hash: d2f2886b902f4c66 - Date: 2026-03-11 ### gcs-rapid-class-zonal-only [IN] OBSERVATION Rapid storage class is zone-only and requires a Rapid Bucket; has storage size quotas unlike other classes. - Source: entries/2026/03/10/gcs-storage-classes.md - Source hash: 66b923eff1d7f475 - Date: 2026-03-11 ### gcs-resource-name-format [IN] OBSERVATION Cloud Storage resource names use format `projects/_/buckets/BUCKET_NAME/objects/OBJECT_NAME`. - Source: entries/2026/03/10/gcs-overview.md - Source hash: dd2c4c31b60dabdb - Date: 2026-03-11 ### gcs-sequential-names-cause-hotspotting [IN] OBSERVATION Sequential object names during large-scale uploads cause hot-spotting on backend servers. - Source: entries/2026/03/10/gcs-objects.md - Source hash: ee2898c31828e7e2 - Date: 2026-03-11 ### gcs-server-side-encryption-always-on [IN] OBSERVATION Server-side encryption is enabled by default on all Cloud Storage objects; CMEK and CSEK are supplemental options. - Source: entries/2026/03/10/gcs-overview.md - Source hash: dd2c4c31b60dabdb - Date: 2026-03-11 ### gcs-signed-urls-no-account-required [IN] OBSERVATION Signed URLs provide time-limited read/write access to GCS objects without requiring the recipient to have a Google account. - Source: entries/2026/03/10/gcs-access-control.md - Source hash: d2f2886b902f4c66 - Date: 2026-03-11 ### gcs-soft-delete-default-7-days [IN] OBSERVATION Soft delete is enabled by default on all Cloud Storage buckets with a 7-day retention period. - Source: entries/2026/03/10/gcs-overview.md - Source hash: dd2c4c31b60dabdb - Date: 2026-03-11 ### gcs-soft-delete-recommended-over-versioning [IN] OBSERVATION Google recommends soft delete over Object Versioning for protection against accidental/malicious deletions. - Source: entries/2026/03/10/gcs-versioning.md - Source hash: a183a381e3109985 - Date: 2026-03-11 ### gcs-storage-class-economics-favor-lifecycle-automation [IN] OBSERVATION GCS storage class economics create a natural incentive for lifecycle automation: Standard and Rapid classes have no retrieval fees while Nearline/Coldline/Archive impose both retrieval fees and minimum storage durations (30/90/365 days), and the SetStorageClass lifecycle action avoids rewrite costs (no retrieval fees, no early deletion fees, no inter-region replication) — making automated downward class transitions via lifecycle rules strictly cheaper than manual object rewrites or delayed transitions. ### gcs-storage-class-minimum-durations [IN] OBSERVATION Minimum storage durations: none for Rapid and Standard, 30 days for Nearline, 90 days for Coldline, 365 days for Archive. - Source: entries/2026/03/10/gcs-storage-classes.md - Source hash: 66b923eff1d7f475 - Date: 2026-03-11 ### gcs-three-dimensional-operational-complexity [IN] OBSERVATION GCS operational management requires simultaneous engineering across three largely independent dimensions: storage class economics with lifecycle automation (retrieval fee incentives vs minimum duration penalties), defense-in-depth data protection (object immutability, namespace security, four-tier encryption), and lifecycle rule evaluation complexity (Delete-over-SetStorageClass precedence, hold interactions, 24-hour propagation delay) — optimizing one dimension can conflict with another. ### gcs-unconditional-eleven-nines-durability [IN] OBSERVATION GCS provides unconditional eleven-nines durability across all storage classes with millisecond access latency — including Archive class, which unlike competing cloud cold tiers requires no retrieval delay. ### gcs-uniform-access-90-day-revert [IN] OBSERVATION After enabling uniform bucket-level access, there is a 90-day window to revert to fine-grained access; after that, uniform is permanent. - Source: entries/2026/03/10/gcs-access-control.md - Source hash: d2f2886b902f4c66 - Date: 2026-03-11 ### gcs-uniform-access-recommended [IN] OBSERVATION Uniform bucket-level access (IAM-only) is the recommended access model for GCS buckets; it disables ACLs. - Source: entries/2026/03/10/gcs-access-control.md - Source hash: d2f2886b902f4c66 - Date: 2026-03-11 ### gcs-versioning-is-bucket-level [IN] OBSERVATION Object Versioning is enabled per bucket, not per object; it affects all objects in the bucket. - Source: entries/2026/03/10/gcs-versioning.md - Source hash: a183a381e3109985 - Date: 2026-03-11 ### gcs-versioning-no-bucket-deletion-protection [IN] OBSERVATION Object Versioning does not protect against bucket deletion; only soft delete provides that protection. - Source: entries/2026/03/10/gcs-versioning.md - Source hash: a183a381e3109985 - Date: 2026-03-11 ### gcs-versioning-wait-30-seconds [IN] OBSERVATION Wait at least 30 seconds after changing versioning configuration before performing delete/replace operations. - Source: entries/2026/03/10/gcs-versioning.md - Source hash: a183a381e3109985 - Date: 2026-03-11 ### gke-3000-sa-limit-metadata-server-oom [IN] OBSERVATION GKE clusters with more than 3,000 Kubernetes service accounts may cause metadata server pod OOM kills. - Source: entries/2026/03/10/gke-workload-identity.md - Source hash: 2557090fceb5fc9e - Date: 2026-03-11 ### gke-alpha-clusters-standard-only [IN] OBSERVATION GKE alpha clusters for testing unstable Kubernetes features are available in Standard mode only. - Source: entries/2026/03/10/gke-overview.md - Source hash: e09c76d0237d85b6 - Date: 2026-03-11 ### gke-apparmor-default-selinux-not-supported [IN] OBSERVATION AppArmor default Docker profile is applied by the container runtime on all GKE containers; SELinux is not supported on GKE. - Source: entries/2026/03/10/gke-security.md - Source hash: 30cd02f5eaa15016 - Date: 2026-03-11 ### gke-artifact-registry-dependency [IN] OBSERVATION GKE cluster creation and upgrades pull container images from Artifact Registry (`pkg.dev` or `gcr.io`); an outage there can block new cluster creation and upgrades. - Source: entries/2026/03/10/gke-cluster-architecture.md - Source hash: 0cf6db09d85d9d28 - Date: 2026-03-11 ### gke-autopilot-always-cos-and-workload-identity [IN] OBSERVATION GKE Autopilot always uses Container-Optimized OS and always has Workload Identity Federation enabled. - Source: entries/2026/03/10/gke-security.md - Source hash: 30cd02f5eaa15016 - Date: 2026-03-11 ### gke-autopilot-always-cos-containerd [IN] OBSERVATION GKE Autopilot nodes always use `cos_containerd` OS; Standard mode offers multiple OS choices. - Source: entries/2026/03/10/gke-cluster-architecture.md - Source hash: 0cf6db09d85d9d28 - Date: 2026-03-11 ### gke-autopilot-always-regional [IN] OBSERVATION GKE Autopilot clusters are always regional and always enrolled in a release channel (default: Regular). - Source: entries/2026/03/10/gke-autopilot.md - Source hash: 974ed41c69e79d42 - Date: 2026-03-11 ### gke-autopilot-billing-per-pod-request [IN] OBSERVATION GKE Autopilot bills per Pod resource request; Standard mode bills per node regardless of Pod utilization. - Source: entries/2026/03/10/gke-overview.md - Source hash: e09c76d0237d85b6 - Date: 2026-03-11 ### gke-autopilot-builtin-compute-classes [IN] OBSERVATION GKE Autopilot provides built-in ComputeClasses: `Balanced`, `Scale-Out`, and `autopilot-spot`. - Source: entries/2026/03/10/gke-autopilot.md - Source hash: 974ed41c69e79d42 - Date: 2026-03-11 ### gke-autopilot-dataplane-v2-default [IN] OBSERVATION GKE Dataplane V2 is enabled by default in Autopilot clusters, enabling network policy enforcement and observability. - Source: entries/2026/03/10/gke-autopilot.md - Source hash: 974ed41c69e79d42 - Date: 2026-03-11 ### gke-autopilot-extended-duration-7-days [IN] OBSERVATION Extended-duration Pods in Autopilot are protected from eviction for up to 7 days using the annotation `cluster-autoscaler.kubernetes.io/safe-to-evict: "false"`. - Source: entries/2026/03/10/gke-autopilot.md - Source hash: 974ed41c69e79d42 - Date: 2026-03-11 ### gke-autopilot-fully-managed-opinionated-model [IN] OBSERVATION GKE Autopilot provides a fully managed, opinionated operational model: always regional (never zonal), always cos_containerd (no OS choice), Google-managed control plane, with scale-to-zero capability — reducing operational surface area but removing infrastructure customization options available in Standard mode. ### gke-autopilot-nodes-not-visible [IN] OBSERVATION In GKE Autopilot mode, underlying Compute Engine VMs are not visible in gcloud CLI or Cloud console and cannot be accessed via SSH. - Source: entries/2026/03/10/gke-cluster-architecture.md - Source hash: 0cf6db09d85d9d28 - Date: 2026-03-11 ### gke-autopilot-safe-for-multi-team-production [IN] OBSERVATION GKE Autopilot is safe for multi-team production clusters with fully managed infrastructure, pod-level billing granularity, and opinionated security baselines. ### gke-autopilot-sla-covers-control-plane-and-compute [IN] OBSERVATION GKE Autopilot SLA covers both the control plane and Pod compute capacity. - Source: entries/2026/03/10/gke-autopilot.md - Source hash: 974ed41c69e79d42 - Date: 2026-03-11 ### gke-autopilot-two-billing-models [IN] OBSERVATION GKE Autopilot has two billing models: pod-based billing for general-purpose workloads and node-based billing for workloads selecting specific hardware. - Source: entries/2026/03/10/gke-autopilot.md - Source hash: 974ed41c69e79d42 - Date: 2026-03-11 ### gke-autopilot-zero-node-scaling [IN] OBSERVATION GKE Autopilot clusters can scale to zero nodes when no workloads are running. - Source: entries/2026/03/10/gke-autopilot.md - Source hash: 974ed41c69e79d42 - Date: 2026-03-11 ### gke-beta-apis-available-1-24-plus [IN] OBSERVATION GKE beta Kubernetes APIs are available in version 1.24 and later. - Source: entries/2026/03/10/gke-overview.md - Source hash: e09c76d0237d85b6 - Date: 2026-03-11 ### gke-binary-authorization-cv-monitors-running-containers [IN] OBSERVATION Binary Authorization continuous validation (CV) continuously monitors running container images against policies. - Source: entries/2026/03/10/gke-security.md - Source hash: 30cd02f5eaa15016 - Date: 2026-03-11 ### gke-cannot-configure-individual-nodes-in-pool [IN] OBSERVATION All nodes in a GKE node pool are identical; individual nodes cannot be configured independently within a pool. - Source: entries/2026/03/10/gke-node-pools.md - Source hash: ffcc0b7940daaece - Date: 2026-03-11 ### gke-cluster-deletion-no-graceful-drain [IN] OBSERVATION GKE cluster deletion does not drain nodes gracefully; `kubectl drain` must be used manually before deleting. - Source: entries/2026/03/10/gke-node-pools.md - Source hash: ffcc0b7940daaece - Date: 2026-03-11 ### gke-cluster-state-etcd-or-spanner [IN] OBSERVATION GKE cluster state can be stored in etcd or Spanner, but the etcd API is always exposed regardless of backend. - Source: entries/2026/03/10/gke-cluster-architecture.md - Source hash: 0cf6db09d85d9d28 - Date: 2026-03-11 ### gke-clusterip-provides-virtual-ip-and-dns [IN] OBSERVATION ClusterIP Service type provides a stable virtual IP and DNS name for internal Pod-to-Pod communication within a GKE cluster. - Source: entries/2026/03/10/gke-networking.md - Source hash: 134faab4251b747a - Date: 2026-03-11 ### gke-control-plane-always-managed [IN] OBSERVATION The GKE control plane is always managed by Google — customers cannot SSH into or directly access it. - Source: entries/2026/03/10/gke-cluster-architecture.md - Source hash: 0cf6db09d85d9d28 - Date: 2026-03-11 ### gke-control-plane-always-managed-by-google [IN] OBSERVATION The GKE control plane is always fully managed by Google Cloud in both Autopilot and Standard modes. - Source: entries/2026/03/10/gke-overview.md - Source hash: e09c76d0237d85b6 - Date: 2026-03-11 ### gke-credential-rotation-rotates-certs-ca-ip [IN] OBSERVATION GKE credential rotation rotates SSL certificates, cluster CA, and control plane IP address. - Source: entries/2026/03/10/gke-security.md - Source hash: 30cd02f5eaa15016 - Date: 2026-03-11 ### gke-critical-kube-system-pods-need-schedulable-pool [IN] OBSERVATION Critical kube-system Pods (kube-dns, konnectivity-agent) must always have a schedulable node pool; removing all untainted pools causes DNS and control plane failures. - Source: entries/2026/03/10/gke-node-pools.md - Source hash: ffcc0b7940daaece - Date: 2026-03-11 ### gke-dataplane-v2-ebpf-dual-benefit [IN] OBSERVATION GKE Dataplane V2 is eBPF-based and provides both high performance networking and built-in network policy enforcement. - Source: entries/2026/03/10/gke-networking.md - Source hash: 134faab4251b747a - Date: 2026-03-11 ### gke-default-node-pool-3-nodes-per-zone [IN] OBSERVATION The default GKE node pool creates 3 nodes per compute zone using `cos_containerd` image and a general-purpose machine type. - Source: entries/2026/03/10/gke-node-pools.md - Source hash: ffcc0b7940daaece - Date: 2026-03-11 ### gke-federated-token-default-lifetime-1-hour [IN] OBSERVATION Workload Identity Federation federated access tokens have a default lifetime of 1 hour; client libraries refresh within 3 min 45 sec of expiry. - Source: entries/2026/03/10/gke-workload-identity.md - Source hash: 2557090fceb5fc9e - Date: 2026-03-11 ### gke-gateway-api-replaces-ingress [IN] OBSERVATION Gateway API is GKE's recommended approach for advanced L7 traffic management, replacing Ingress for new deployments. - Source: entries/2026/03/10/gke-networking.md - Source hash: 134faab4251b747a - Date: 2026-03-11 ### gke-host-network-pods-bypass-workload-identity [IN] OBSERVATION Pods with `hostNetwork: true` bypass Workload Identity Federation and use the Compute Engine metadata server directly. - Source: entries/2026/03/10/gke-workload-identity.md - Source hash: 2557090fceb5fc9e - Date: 2026-03-11 ### gke-hubble-diagnoses-dropped-packets [IN] OBSERVATION Hubble (via Dataplane V2 observability) is the tool for diagnosing dropped packets and misconfigured network policies; uses `hubble_drop_total` metric. - Source: entries/2026/03/10/gke-networking.md - Source hash: 134faab4251b747a - Date: 2026-03-11 ### gke-identity-sameness-risk-same-ns-sa [IN] OBSERVATION Same namespace + service account name across GKE clusters in the same project results in the same IAM identity; mitigate with separate projects or distinct namespace names. - Source: entries/2026/03/10/gke-workload-identity.md - Source hash: 2557090fceb5fc9e - Date: 2026-03-11 ### gke-legacy-abac-should-be-disabled [IN] OBSERVATION Legacy ABAC should be disabled on GKE clusters; RBAC and IAM should be the only authorization mechanisms. - Source: entries/2026/03/10/gke-security.md - Source hash: 30cd02f5eaa15016 - Date: 2026-03-11 ### gke-loadbalancer-creates-passthrough-nlb [IN] OBSERVATION LoadBalancer Service type provisions a regional external passthrough Network Load Balancer with a public IP. - Source: entries/2026/03/10/gke-networking.md - Source hash: 134faab4251b747a - Date: 2026-03-11 ### gke-mcs-cross-region-failover [IN] OBSERVATION Multi-cluster Services (MCS) enables cross-cluster and cross-region failover with a single global DNS name and health-aware routing. - Source: entries/2026/03/10/gke-networking.md - Source hash: 134faab4251b747a - Date: 2026-03-11 ### gke-metadata-server-500-concurrent-connections [IN] OBSERVATION The GKE metadata server has a limit of 500 concurrent connections per node. - Source: entries/2026/03/10/gke-workload-identity.md - Source hash: 2557090fceb5fc9e - Date: 2026-03-11 ### gke-multi-zonal-replicates-pools-across-zones [IN] OBSERVATION In multi-zonal GKE clusters, node pools are automatically replicated across all zones, which has quota implications. - Source: entries/2026/03/10/gke-node-pools.md - Source hash: ffcc0b7940daaece - Date: 2026-03-11 ### gke-network-policies-default-allow-all [IN] OBSERVATION GKE network policies default to allow-all; once any policy is applied to a namespace, unmatched traffic is denied. - Source: entries/2026/03/10/gke-security.md - Source hash: 30cd02f5eaa15016 - Date: 2026-03-11 ### gke-node-pool-label-cloud-google-com [IN] OBSERVATION Every node in a GKE node pool is labeled with `cloud.google.com/gke-nodepool` set to the pool's name. - Source: entries/2026/03/10/gke-node-pools.md - Source hash: ffcc0b7940daaece - Date: 2026-03-11 ### gke-node-sa-still-used-for-image-pulls [IN] OBSERVATION The node pool's IAM service account is still used for container image pulls even with Workload Identity Federation enabled. - Source: entries/2026/03/10/gke-workload-identity.md - Source hash: 2557090fceb5fc9e - Date: 2026-03-11 ### gke-nodelocal-dnscache-reduces-latency [IN] OBSERVATION NodeLocal DNSCache caches DNS queries on each node to reduce DNS latency at scale in GKE clusters. - Source: entries/2026/03/10/gke-networking.md - Source hash: 134faab4251b747a - Date: 2026-03-11 ### gke-nodes-are-compute-engine-vms [IN] OBSERVATION GKE nodes are Compute Engine virtual machine instances. - Source: entries/2026/03/10/gke-overview.md - Source hash: e09c76d0237d85b6 - Date: 2026-03-11 ### gke-pdb-deletion-cap-one-hour [IN] OBSERVATION GKE PodDisruptionBudget respect during node pool deletion must be explicitly configured and is capped at one hour. - Source: entries/2026/03/10/gke-node-pools.md - Source hash: ffcc0b7940daaece - Date: 2026-03-11 ### gke-principal-vs-principalset-prefix [IN] OBSERVATION `principal://` references a single IAM resource; `principalSet://` references a set of resources (namespace, cluster) in Workload Identity Federation. - Source: entries/2026/03/10/gke-workload-identity.md - Source hash: 2557090fceb5fc9e - Date: 2026-03-11 ### gke-release-channels-govern-auto-upgrades [IN] OBSERVATION GKE release channels govern automatic Kubernetes version upgrades; without a release channel (Standard only), no automatic upgrades occur. - Source: entries/2026/03/10/gke-overview.md - Source hash: e09c76d0237d85b6 - Date: 2026-03-11 ### gke-sandbox-gvisor-incompatible-with-node-sa [IN] OBSERVATION GKE Sandbox (gVisor) is incompatible with node service account authentication but compatible with Workload Identity Federation. - Source: entries/2026/03/10/gke-security.md - Source hash: 30cd02f5eaa15016 - Date: 2026-03-11 ### gke-shared-vpc-host-service-pattern [IN] OBSERVATION Shared VPC is the multi-tenant networking pattern where the host project owns networking resources and service projects run GKE clusters. - Source: entries/2026/03/10/gke-networking.md - Source hash: 134faab4251b747a - Date: 2026-03-11 ### gke-workload-identity-pool-format-not-deletable [IN] OBSERVATION The workload identity pool format is `PROJECT_ID.svc.id.goog` and is not deletable even after all clusters are removed. - Source: entries/2026/03/10/gke-workload-identity.md - Source hash: 2557090fceb5fc9e - Date: 2026-03-11 ### gke-workload-identity-recommended-for-api-access [IN] OBSERVATION Workload Identity Federation for GKE is the recommended method for Pods to access Google Cloud APIs, over node service accounts or JSON keys. - Source: entries/2026/03/10/gke-security.md - Source hash: 30cd02f5eaa15016 - Date: 2026-03-11 ### gke-workload-identity-requires-namespace-discipline [IN] OBSERVATION GKE Workload Identity Federation is the recommended API access pattern but requires namespace and service account naming discipline: same namespace + SA name across clusters creates identity collisions, and the pool format is permanent (not deletable). ### ha-vpn-9999-sla-requires-both-interfaces [IN] OBSERVATION HA VPN 99.99% SLA requires tunnels from both HA VPN interfaces (interface 0 and interface 1) to peer gateway interfaces — a single tunnel on one interface is insufficient. - Source: entries/2026/03/11/vpn-ha.md - Source hash: afddb0ba4842ea1b - Date: 2026-03-11 ### ha-vpn-active-passive-recommended-single-gateway [IN] OBSERVATION Active-passive routing is recommended for a single HA VPN gateway (consistent bandwidth); active-active is recommended for multiple gateways to avoid bandwidth loss from unused passive tunnels. - Source: entries/2026/03/11/vpn-ha.md - Source hash: afddb0ba4842ea1b - Date: 2026-03-11 ### ha-vpn-failover-40-60-seconds [IN] OBSERVATION HA VPN failover takes 40–60 seconds of expected packet loss when a tunnel goes down as Cloud Router withdraws learned routes. - Source: entries/2026/03/11/vpn-ha.md - Source hash: afddb0ba4842ea1b - Date: 2026-03-11 ### ha-vpn-full-mesh-not-required-gcp-side [IN] OBSERVATION Full mesh is not required on the GCP side for 99.99% SLA — only one tunnel per HA VPN interface to the corresponding peer interface; full mesh may only be required by the peer vendor. - Source: entries/2026/03/11/vpn-ha.md - Source hash: afddb0ba4842ea1b - Date: 2026-03-11 ### ha-vpn-over-interconnect-internal-ips [IN] OBSERVATION HA VPN over Cloud Interconnect allows using regional internal IP addresses for both HA VPN and peer gateways. - Source: entries/2026/03/11/vpn-ha.md - Source hash: afddb0ba4842ea1b - Date: 2026-03-11 ### ha-vpn-requires-bgp-no-static [IN] OBSERVATION HA VPN tunnels must use BGP (dynamic routing) — static routing is not supported for HA VPN. - Source: entries/2026/03/11/vpn-ha.md - Source hash: afddb0ba4842ea1b - Date: 2026-03-11 ### ha-vpn-stack-type-immutable-after-creation [IN] OBSERVATION HA VPN gateway stack type (IPV4_ONLY, IPV4_IPV6, IPV6_ONLY) cannot be changed after creation — the gateway must be deleted and recreated. - Source: entries/2026/03/11/vpn-overview.md - Source hash: 0f7da5bd938d7e42 - Date: 2026-03-11 ### ha-vpn-vpc-to-vpc-same-region-9999-cross-region-999 [IN] OBSERVATION VPC-to-VPC HA VPN gateways in the same region achieve 99.99% SLA; gateways in different regions achieve only 99.9% SLA. - Source: entries/2026/03/11/vpn-ha.md - Source hash: afddb0ba4842ea1b - Date: 2026-03-11 ### iam-api-eventually-consistent [IN] OBSERVATION The IAM API is eventually consistent — writes may not be immediately visible to reads or access checks. - Source: entries/2026/03/10/iam-overview.md - Source hash: 3da0e3b2362ff5cb - Date: 2026-03-11 ### iam-basic-roles-not-for-production [IN] OBSERVATION Basic roles (Owner, Editor, Viewer) should not be used in production; they include thousands of permissions across all GCP services. - Source: entries/2026/03/10/iam-best-practices.md - Source hash: 873909ac976c6f0a - Date: 2026-03-11 ### iam-compute-access-scopes-legacy [IN] OBSERVATION Access scopes on Compute Engine are a legacy mechanism — both scopes and IAM roles must allow access for an API call to succeed. - Source: entries/2026/03/10/iam-service-accounts.md - Source hash: 1c861fff003e0a40 - Date: 2026-03-11 ### iam-conditional-binding-no-override-unconditional [IN] OBSERVATION A conditional role binding does NOT override an unconditional binding for the same role — the unconditional binding still grants access. - Source: entries/2026/03/10/iam-conditions.md - Source hash: 6b9403c5d340b631 - Date: 2026-03-11 ### iam-conditions-not-with-basic-roles [IN] OBSERVATION IAM conditions cannot be used with basic roles (Owner/Editor/Viewer) or with allUsers/allAuthenticatedUsers. - Source: entries/2026/03/10/iam-conditions.md - Source hash: 6b9403c5d340b631 - Date: 2026-03-11 ### iam-conditions-use-cel [IN] OBSERVATION IAM Conditions use Common Expression Language (CEL) for attribute-based access control expressions. - Source: entries/2026/03/10/iam-conditions.md - Source hash: 6b9403c5d340b631 - Date: 2026-03-11 ### iam-defense-in-depth-requires-policy-and-sa-hardening [IN] OBSERVATION GCP IAM security requires defense in depth across two independent dimensions: correct policy evaluation understanding (deny-first with fail-closed conditions, inheritance unions, conditional bindings that don't override unconditional) for authoring policies, and active service account hardening (revoking default editor role, controlling impersonation, managing dual principal/resource nature) for closing privilege escalation — neither alone is sufficient. ### iam-deny-conditions-fail-closed [IN] OBSERVATION If a deny policy condition evaluates to true OR cannot be evaluated, the deny rule applies (fail-closed behavior). - Source: entries/2026/03/10/iam-conditions.md - Source hash: 6b9403c5d340b631 - Date: 2026-03-11 ### iam-deny-conditions-only-resource-tags [IN] OBSERVATION Deny policy conditions only support resource tag functions, not the full set of condition attributes available in allow policies. - Source: entries/2026/03/10/iam-conditions.md - Source hash: 6b9403c5d340b631 - Date: 2026-03-11 ### iam-deny-overrides-allow [IN] OBSERVATION Deny policies override allow policies — a principal can be denied access even if allowed by an allow policy. - Source: entries/2026/03/10/iam-overview.md - Source hash: 3da0e3b2362ff5cb - Date: 2026-03-11 ### iam-effective-policy-is-union [IN] OBSERVATION The effective allow policy for a resource is the union of its own policy plus all ancestor policies in the resource hierarchy. - Source: entries/2026/03/10/iam-overview.md - Source hash: 3da0e3b2362ff5cb - Date: 2026-03-11 ### iam-gcs-conditions-require-uniform-access [IN] OBSERVATION Cloud Storage buckets require uniform bucket-level access enabled to use IAM conditions. - Source: entries/2026/03/10/iam-conditions.md - Source hash: 6b9403c5d340b631 - Date: 2026-03-11 ### iam-grant-roles-to-groups [IN] OBSERVATION Best practice is to grant IAM roles to Google Groups rather than individual users for easier management. - Source: entries/2026/03/10/iam-best-practices.md - Source hash: 873909ac976c6f0a - Date: 2026-03-11 ### iam-key-rotation-order [IN] OBSERVATION Service account key rotation follows a strict order: create new key → switch apps → disable old key → delete old key. - Source: entries/2026/03/10/iam-best-practices.md - Source hash: 873909ac976c6f0a - Date: 2026-03-11 ### iam-max-100-conditional-bindings [IN] OBSERVATION Best practice is no more than 100 conditional role bindings per allow policy to avoid size limits. - Source: entries/2026/03/10/iam-conditions.md - Source hash: 6b9403c5d340b631 - Date: 2026-03-11 ### iam-permission-format [IN] OBSERVATION IAM permissions follow the format service.resource.verb (e.g., resourcemanager.projects.list) and cannot be granted directly — only through roles. - Source: entries/2026/03/10/iam-overview.md - Source hash: 3da0e3b2362ff5cb - Date: 2026-03-11 ### iam-policy-evaluation-layered-fail-closed-deny [IN] OBSERVATION IAM policy evaluation is a layered system with fail-closed deny semantics: deny policies trigger on unevaluable conditions, conditional allow bindings never override unconditional bindings for the same role, and all policies inherit top-down through the org/folder/project/resource hierarchy. ### iam-policy-inheritance-top-down [IN] OBSERVATION IAM allow policies on parent resources (org → folder → project → resource) are automatically inherited by all child resources. - Source: entries/2026/03/10/iam-best-practices.md - Source hash: 873909ac976c6f0a - Date: 2026-03-11 ### iam-prefer-alternatives-to-sa-keys [IN] OBSERVATION Service account keys are a security risk; prefer Workload Identity, attached service accounts, or federated identity over key-based authentication. - Source: entries/2026/03/10/iam-best-practices.md - Source hash: 873909ac976c6f0a - Date: 2026-03-11 ### iam-role-naming-convention [IN] OBSERVATION IAM role names follow the convention roles/. (e.g., roles/storage.admin). - Source: entries/2026/03/10/iam-roles.md - Source hash: 4714c3408e4786f1 - Date: 2026-03-11 ### iam-sa-100-per-project-quota [IN] OBSERVATION Default quota is 100 service accounts per project; can request an increase. - Source: entries/2026/03/10/iam-service-accounts.md - Source hash: 1c861fff003e0a40 - Date: 2026-03-11 ### iam-sa-default-gets-editor [IN] OBSERVATION Default service accounts (Compute Engine, App Engine) automatically receive roles/editor — a security anti-pattern that should be disabled via org policy. - Source: entries/2026/03/10/iam-service-accounts.md - Source hash: 1c861fff003e0a40 - Date: 2026-03-11 ### iam-sa-dual-nature [IN] OBSERVATION Service accounts are both principals (can be granted roles on resources) and resources (other principals can be granted roles on them). - Source: entries/2026/03/10/iam-service-accounts.md - Source hash: 1c861fff003e0a40 - Date: 2026-03-11 ### iam-sa-impersonation-requires-token-creator [IN] OBSERVATION Service account impersonation requires roles/iam.serviceAccountTokenCreator on the target service account. - Source: entries/2026/03/10/iam-service-accounts.md - Source hash: 1c861fff003e0a40 - Date: 2026-03-11 ### iam-sa-not-in-workspace-domain [IN] OBSERVATION Service accounts do not belong to Google Workspace domains — Workspace domain-wide shares do not include them. - Source: entries/2026/03/10/iam-service-accounts.md - Source hash: 1c861fff003e0a40 - Date: 2026-03-11 ### iam-sa-recreate-loses-bindings [IN] OBSERVATION Deleting and recreating a service account with the same email does not restore old role bindings because bindings use internal unique IDs, not email addresses. - Source: entries/2026/03/10/iam-service-accounts.md - Source hash: 1c861fff003e0a40 - Date: 2026-03-11 ### iam-service-account-security-requires-hardening [IN] OBSERVATION Service accounts require active security hardening: they have dual nature (principal and resource), default accounts receive overly broad editor role, impersonation needs explicit token creator role, and they are invisible to Workspace domain-wide shares. ### iam-service-account-user-privilege-escalation [IN] OBSERVATION The Service Account User role (roles/iam.serviceAccountUser) is a privilege escalation vector — anyone with this role inherits the service account's full access. - Source: entries/2026/03/10/iam-best-practices.md - Source hash: 873909ac976c6f0a - Date: 2026-03-11 ### interconnect-50-percent-capacity-rule [IN] OBSERVATION Cloud Interconnect protects up to 50% of aggregate capacity; provision 2x required bandwidth across redundant connections for full protection. - Source: entries/2026/03/11/interconnect-best-practices.md - Source hash: 827922399c966c14 - Date: 2026-03-11 ### interconnect-active-active-recommended [IN] OBSERVATION Active-active is the recommended VLAN attachment configuration for Cloud Interconnect; active/passive risks undetected misconfigurations. - Source: entries/2026/03/11/interconnect-best-practices.md - Source hash: 827922399c966c14 - Date: 2026-03-11 ### interconnect-dedicated-up-to-100-gbps [IN] OBSERVATION Dedicated Interconnect supports up to 100 Gbps connections at colocation facilities. - Source: entries/2026/03/11/interconnect-overview.md - Source hash: fd49e3267ebd0b15 - Date: 2026-03-11 ### interconnect-ecmp-requires-flow-based-hashing [IN] OBSERVATION ECMP across active-active Cloud Interconnect VLAN attachments requires flow-based hashing on on-premises devices; per-packet load balancing is unsupported and causes TCP connection closures. - Source: entries/2026/03/11/interconnect-best-practices.md - Source hash: 827922399c966c14 - Date: 2026-03-11 ### interconnect-encryption-requires-overlay-protocol [IN] OBSERVATION Cloud Interconnect does not encrypt traffic by default; achieving confidentiality requires an overlay protocol — either MACsec for link-layer encryption between router and Google edge, or HA VPN tunnels over Interconnect using regional internal IP addresses for end-to-end IPsec encryption. ### interconnect-four-connection-types [IN] OBSERVATION Cloud Interconnect offers four connection types: Dedicated, Partner, Cross-Cloud, and Cross-Site Interconnect. - Source: entries/2026/03/11/interconnect-overview.md - Source hash: fd49e3267ebd0b15 - Date: 2026-03-11 ### interconnect-ha-vpn-gateway-mtu-1440 [IN] OBSERVATION HA VPN over Cloud Interconnect uses a reduced gateway MTU of 1440 bytes. - Source: entries/2026/03/11/interconnect-best-practices.md - Source hash: 827922399c966c14 - Date: 2026-03-11 ### interconnect-ip-spaces-must-not-overlap [IN] OBSERVATION IP address spaces between on-premises and VPC networks must not overlap when using Cloud Interconnect. - Source: entries/2026/03/11/interconnect-overview.md - Source hash: fd49e3267ebd0b15 - Date: 2026-03-11 ### interconnect-no-encryption-by-default [IN] OBSERVATION Cloud Interconnect does not encrypt traffic by default; encryption requires MACsec (router-to-edge) or HA VPN over Cloud Interconnect (IPsec on VLAN attachments). - Source: entries/2026/03/11/interconnect-overview.md - Source hash: fd49e3267ebd0b15 - Date: 2026-03-11 ### interconnect-physical-connections-cannot-move-or-rename [IN] OBSERVATION Physical Cloud Interconnect connections cannot be moved between projects or renamed after creation. - Source: entries/2026/03/11/interconnect-best-practices.md - Source hash: 827922399c966c14 - Date: 2026-03-11 ### interconnect-production-requires-redundancy-and-encryption [IN] OBSERVATION Production-grade Cloud Interconnect requires two independent engineering efforts: 2x bandwidth overprovisioning with global dynamic BGP routing for redundancy, AND an encryption overlay (MACsec or HA VPN over internal IPs) for confidentiality — neither alone is sufficient for production readiness. ### interconnect-reduces-egress-costs [IN] OBSERVATION Cloud Interconnect can reduce egress costs, unlike Cloud VPN alone which does not reduce egress costs. - Source: entries/2026/03/11/interconnect-overview.md - Source hash: fd49e3267ebd0b15 - Date: 2026-03-11 ### interconnect-redundancy-requires-overprovisioning-and-global-routing [IN] OBSERVATION Cloud Interconnect redundancy requires provisioning 2x bandwidth (50% capacity rule), dynamic BGP routing via Cloud Router, and global dynamic routing mode for cross-region failover — creating a three-layer resilience model. ### interconnect-regional-failover-requires-global-dynamic-routing [IN] OBSERVATION Cloud Interconnect traffic prefers the lowest-metric local region; cross-region failover only occurs when all local VLAN attachments are down and requires global dynamic routing. - Source: entries/2026/03/11/interconnect-best-practices.md - Source hash: 827922399c966c14 - Date: 2026-03-11 ### interconnect-sla-tiers-99-99-99-9-none [IN] OBSERVATION Cloud Interconnect offers three SLA tiers: 99.99% (critical production), 99.9% (non-critical production), and no SLA. - Source: entries/2026/03/11/interconnect-overview.md - Source hash: fd49e3267ebd0b15 - Date: 2026-03-11 ### interconnect-uses-cloud-router-bgp [IN] OBSERVATION Cloud Interconnect uses Cloud Router for dynamic (BGP) routing between on-premises and VPC networks. - Source: entries/2026/03/11/interconnect-overview.md - Source hash: fd49e3267ebd0b15 - Date: 2026-03-11 ### interconnect-vlan-custom-ip-prefix-lengths [IN] OBSERVATION Custom IP ranges on VLAN attachments require /29 or /30 for IPv4 and /125 or /126 for IPv6; private IPv4 addresses cannot be used with custom IP range flags. - Source: entries/2026/03/11/interconnect-overview.md - Source hash: fd49e3267ebd0b15 - Date: 2026-03-11 ### interconnect-vlan-mtu-must-match-vpc-mtu [IN] OBSERVATION Cloud Interconnect VLAN attachment MTU should match VPC network MTU; mismatches drop non-TCP packets regardless of DF bit setting. - Source: entries/2026/03/11/interconnect-best-practices.md - Source hash: 827922399c966c14 - Date: 2026-03-11 ### internal-nlb-backend-must-bind-forwarding-rule-ip [IN] OBSERVATION Internal passthrough NLB backend VMs must bind to the forwarding rule IP or `0.0.0.0`/`::` because the destination IP on received packets is the forwarding rule's IP, not the backend's own IP. - Source: entries/2026/03/10/lb-internal.md - Source hash: 049335b111c1b129 - Date: 2026-03-11 ### internal-nlb-cannot-mix-ig-and-neg [IN] OBSERVATION Internal passthrough NLB cannot mix instance group and zonal NEG (`GCE_VM_IP`) backends on the same backend service. - Source: entries/2026/03/10/lb-internal.md - Source hash: 049335b111c1b129 - Date: 2026-03-11 ### internal-nlb-forwarding-rules-immutable [IN] OBSERVATION Internal passthrough NLB forwarding rules are immutable after creation — must delete and recreate to change ports or IP. - Source: entries/2026/03/10/lb-internal.md - Source hash: 049335b111c1b129 - Date: 2026-03-11 ### internal-nlb-global-access-disabled-by-default [IN] OBSERVATION Internal passthrough NLB global access is disabled by default; without it, only same-region clients can connect. On-prem clients via VPN/Interconnect must match the LB region unless global access is enabled. - Source: entries/2026/03/10/lb-internal.md - Source hash: 049335b111c1b129 - Date: 2026-03-11 ### internal-nlb-l3-default-requires-ports-all [IN] OBSERVATION Internal passthrough NLB `L3_DEFAULT` forwarding rule protocol enables non-TCP/UDP protocols (ICMP, SCTP, ESP, AH, GRE) and requires `--ports=ALL`. - Source: entries/2026/03/10/lb-internal.md - Source hash: 049335b111c1b129 - Date: 2026-03-11 ### internal-nlb-neg-ipv4-only [IN] OBSERVATION Internal passthrough NLB zonal NEGs (`GCE_VM_IP`) only support IPv4; instance groups support both IPv4 and IPv6. - Source: entries/2026/03/10/lb-internal.md - Source hash: 049335b111c1b129 - Date: 2026-03-11 ### internal-nlb-regional-passthrough [IN] OBSERVATION The internal passthrough Network Load Balancer is regional, Layer 4, built on Andromeda, preserves client source IP, and does not terminate SSL/TLS. - Source: entries/2026/03/10/lb-internal.md - Source hash: 049335b111c1b129 - Date: 2026-03-11 ### internal-nlb-scheme-internal [IN] OBSERVATION Internal passthrough NLB uses load balancing scheme `INTERNAL`, distinguishing it from external passthrough NLB which uses `EXTERNAL`. - Source: entries/2026/03/10/lb-internal.md - Source hash: 049335b111c1b129 - Date: 2026-03-11 ### ipv6-access-type-cannot-change-after-creation [IN] OBSERVATION A subnet's IPv6 access type (internal or external) cannot be changed after subnet creation. - Source: entries/2026/03/10/vpc-subnets.md - Source hash: 0a93f184ecf6ad03 - Date: 2026-03-11 ### ipv6-subnets-require-custom-mode [IN] OBSERVATION IPv6 subnets are only supported on custom mode VPC networks, not auto mode or legacy networks. - Source: entries/2026/03/10/vpc-subnets.md - Source hash: 0a93f184ecf6ad03 - Date: 2026-03-11 ### keyless-identity-eliminates-credential-overhead [IN] OBSERVATION Keyless identity patterns (WIF for external workloads + GKE Workload Identity for pods) fully eliminate credential management overhead by replacing service account keys with federated token exchange across all workload types. ### kms-admin-role-no-encrypt-decrypt [IN] OBSERVATION The `roles/cloudkms.admin` role does NOT grant encrypt or decrypt permissions; separate granular roles exist for encrypt-only, decrypt-only, and combined encrypter-decrypter. - Source: entries/2026/03/11/kms-encryption.md - Source hash: 86869bc11edc7284 - Date: 2026-03-11 ### kms-all-states-except-destroyed-incur-costs [IN] OBSERVATION All Cloud KMS key version states except Destroyed incur costs, including Disabled and Scheduled for destruction. - Source: entries/2026/03/11/kms-key-hierarchy.md - Source hash: fcff61df71684df8 - Date: 2026-03-11 ### kms-auto-rotation-symmetric-only [IN] OBSERVATION Cloud KMS automatic key rotation is supported for symmetric keys only; asymmetric keys must be rotated manually. - Source: entries/2026/03/11/kms-key-rotation.md - Source hash: 0ca406d246ac04f0 - Date: 2026-03-11 ### kms-autokey-provisions-on-demand [IN] OBSERVATION Cloud KMS Autokey automates provisioning of key rings, keys, and service accounts on demand during resource creation, requiring no pre-provisioning. - Source: entries/2026/03/11/kms-overview.md - Source hash: 721fe59712822959 - Date: 2026-03-11 ### kms-cmek-40-plus-services [IN] OBSERVATION Over 40 GCP services support Customer-Managed Encryption Keys (CMEK) with software and HSM keys; over 30 services support EKM keys. - Source: entries/2026/03/11/kms-overview.md - Source hash: 721fe59712822959 - Date: 2026-03-11 ### kms-crc32c-integrity-verification-recommended [IN] OBSERVATION CRC32C integrity verification is recommended (not mandatory) for Cloud KMS encrypt and decrypt operations to detect in-transit data corruption. - Source: entries/2026/03/11/kms-encryption.md - Source hash: 86869bc11edc7284 - Date: 2026-03-11 ### kms-crypto-shredding-destroy-cmek [IN] OBSERVATION Crypto-shredding in GCP works by destroying the CMEK that protects data, rendering the data selectively unreadable. - Source: entries/2026/03/11/kms-overview.md - Source hash: 721fe59712822959 - Date: 2026-03-11 ### kms-csek-not-a-kms-feature [IN] OBSERVATION Customer-Supplied Encryption Keys (CSEK) are not a Cloud KMS feature — they are supported only by Cloud Storage and Compute Engine, where the customer provides key material at use time. - Source: entries/2026/03/11/kms-overview.md - Source hash: 721fe59712822959 - Date: 2026-03-11 ### kms-destroy-duration-only-at-creation [IN] OBSERVATION The `destroy_scheduled_duration` for a Cloud KMS key is only configurable at key creation time and cannot be changed afterward. - Source: entries/2026/03/11/kms-key-versions.md - Source hash: 837eb3046c40f6f2 - Date: 2026-03-11 ### kms-destroy-scheduled-default-30-days [IN] OBSERVATION Default scheduled-for-destruction duration for Cloud KMS key versions is 30 days; minimum is 24 hours (0 for import-only keys); maximum is 120 days. - Source: entries/2026/03/11/kms-key-versions.md - Source hash: 837eb3046c40f6f2 - Date: 2026-03-11 ### kms-destroying-active-version-permanent-data-loss [IN] OBSERVATION Destroying a Cloud KMS key version that is still in use causes permanent, irrecoverable data loss. - Source: entries/2026/03/11/kms-key-rotation.md - Source hash: 0ca406d246ac04f0 - Date: 2026-03-11 ### kms-ekm-keys-never-sent-to-google [IN] OBSERVATION Cloud EKM keys reside in an external key manager and are never sent to Google. - Source: entries/2026/03/11/kms-overview.md - Source hash: 721fe59712822959 - Date: 2026-03-11 ### kms-encrypt-uses-primary-version-automatically [IN] OBSERVATION Encrypt requests target the crypto key (not a specific version) — Cloud KMS uses the primary version automatically; decrypt also targets the key and determines the version from ciphertext metadata. - Source: entries/2026/03/11/kms-encryption.md - Source hash: 86869bc11edc7284 - Date: 2026-03-11 ### kms-governance-couples-duty-separation-with-safe-rotation [IN] OBSERVATION Cloud KMS governance provides complementary safety guarantees: strict separation of duties ensures administrators cannot perform cryptographic operations (and vice versa) while key rotation is operationally safe because it creates new versions without re-encrypting existing data and the version is embedded in ciphertext for transparent decryption — together enabling key governance where operational mistakes in rotation cannot cause data loss and administrative access cannot enable data exfiltration. ### kms-iam-at-key-level-not-version [IN] OBSERVATION IAM access control operates at the key level, not the key version level — you cannot control access to individual key versions. - Source: entries/2026/03/11/kms-key-hierarchy.md - Source hash: fcff61df71684df8 - Date: 2026-03-11 ### kms-key-material-purge-45-days-after-destroy [IN] OBSERVATION After a Cloud KMS key version is destroyed, it takes 45 days for key material to be purged from all Google active and backup systems. - Source: entries/2026/03/11/kms-key-versions.md - Source hash: 837eb3046c40f6f2 - Date: 2026-03-11 ### kms-key-rings-cannot-be-deleted [IN] OBSERVATION Cloud KMS key rings and EKM connections cannot be deleted, and deleted key names cannot be reused. - Source: entries/2026/03/11/kms-key-hierarchy.md - Source hash: fcff61df71684df8 - Date: 2026-03-11 ### kms-key-rings-location-bound-immovable [IN] OBSERVATION Cloud KMS key rings are bound to a specific location and cannot be moved after creation. - Source: entries/2026/03/11/kms-hsm.md - Source hash: 2a1316fe5af2fee3 - Date: 2026-03-11 ### kms-key-type-purpose-protection-immutable [IN] OBSERVATION Cloud KMS key type, purpose, and protection level are all immutable after creation. - Source: entries/2026/03/11/kms-key-hierarchy.md - Source hash: fcff61df71684df8 - Date: 2026-03-11 ### kms-manual-rotation-preserves-auto-schedule [IN] OBSERVATION Manual key rotation does not pause or modify an existing automatic rotation schedule. - Source: entries/2026/03/11/kms-key-rotation.md - Source hash: 0ca406d246ac04f0 - Date: 2026-03-11 ### kms-only-primary-version-encrypts [IN] OBSERVATION For symmetric encryption keys, only the primary version can encrypt data; any enabled version can decrypt, but non-primary enabled versions cannot encrypt. - Source: entries/2026/03/11/kms-key-versions.md - Source hash: 837eb3046c40f6f2 - Date: 2026-03-11 ### kms-only-symmetric-has-primary-version [IN] OBSERVATION Only symmetric encryption keys have a primary version; asymmetric keys require specifying the version explicitly. - Source: entries/2026/03/11/kms-key-hierarchy.md - Source hash: fcff61df71684df8 - Date: 2026-03-11 ### kms-probabilistic-encryption [IN] OBSERVATION Cloud KMS uses probabilistic encryption — identical plaintext encrypted with the same key version produces different ciphertext each time. - Source: entries/2026/03/11/kms-key-hierarchy.md - Source hash: fcff61df71684df8 - Date: 2026-03-11 ### kms-raw-key-material-never-exportable [IN] OBSERVATION Cloud KMS raw symmetric key material can never be viewed or exported; encrypt/decrypt operations happen within the service. - Source: entries/2026/03/11/kms-encryption.md - Source hash: 86869bc11edc7284 - Date: 2026-03-11 ### kms-raw-key-material-never-viewable [IN] OBSERVATION Cloud KMS raw key material is never viewable or exportable by any Google Cloud principal. - Source: entries/2026/03/11/kms-key-hierarchy.md - Source hash: fcff61df71684df8 - Date: 2026-03-11 ### kms-rest-api-requires-base64-encoding [IN] OBSERVATION Cloud KMS REST API requires plaintext to be base64-encoded before calling encrypt, and decrypt responses are also base64-encoded. - Source: entries/2026/03/11/kms-encryption.md - Source hash: 86869bc11edc7284 - Date: 2026-03-11 ### kms-rotation-decoupled-from-reencryption [IN] OBSERVATION KMS key rotation creates new versions without re-encrypting existing data; the version is embedded in ciphertext for symmetric keys, automatic rotation only works for symmetric keys, and manual rotation preserves auto schedules — making re-encryption a separate operational responsibility. ### kms-rotation-does-not-reencrypt-data [IN] OBSERVATION Rotating a Cloud KMS key creates a new key version but does not re-encrypt previously encrypted data — re-encryption must be done explicitly. - Source: entries/2026/03/11/kms-key-rotation.md - Source hash: 0ca406d246ac04f0 - Date: 2026-03-11 ### kms-separation-of-duties-admin-vs-crypto [IN] OBSERVATION Cloud KMS enforces strict separation of duties between administration and cryptographic operations: the admin role cannot encrypt or decrypt, IAM access control operates at the key level (not individual versions), and raw key material is never viewable or exportable — no single role or access path can both manage keys and use them, and the key material itself is inaccessible regardless of permissions. ### kms-software-fips-140-2-level-1 [IN] OBSERVATION Cloud KMS software protection level keys are FIPS 140-2 Level 1 certified. - Source: entries/2026/03/11/kms-overview.md - Source hash: 721fe59712822959 - Date: 2026-03-11 ### kms-symmetric-version-embedded-in-ciphertext [IN] OBSERVATION For symmetric Cloud KMS keys, the version used for encryption is embedded in the ciphertext, so decryption automatically selects the correct version. - Source: entries/2026/03/11/kms-key-versions.md - Source hash: 837eb3046c40f6f2 - Date: 2026-03-11 ### logging-alerting-vs-metrics-usage [IN] OBSERVATION Log-based alerting policies are for rare important events (pattern matching), while log-based metrics combined with alerting policies are for monitoring trends and thresholds. - Source: entries/2026/03/10/logging-overview.md - Source hash: 1e1bd1b762bff702 - Date: 2026-03-11 ### logging-auto-collection-no-setup [IN] OBSERVATION Cloud Logging automatically collects logs from Google Cloud resources without requiring manual setup for default collection. - Source: entries/2026/03/10/logging-overview.md - Source hash: 1e1bd1b762bff702 - Date: 2026-03-11 ### logging-cloud-storage-sink-latency-hours [IN] OBSERVATION New Cloud Storage log sinks can take several hours to begin routing because log entries to Cloud Storage are processed hourly. - Source: entries/2026/03/10/logging-exports.md - Source hash: a3ba07d98be6ea71 - Date: 2026-03-11 ### logging-default-routing-two-tier-architecture [IN] OBSERVATION Cloud Logging's two default sinks implement a deliberate two-tier routing architecture: `_Required` is completely immutable and always routes compliance-critical audit logs (Admin Activity, System Events), while `_Default` can be modified, disabled, or redirected — guaranteeing compliance log capture at the infrastructure level while giving operators full control over operational log routing and cost. ### logging-default-sink-modifiable [IN] OBSERVATION The `_Default` sink is system-created but can be modified, disabled, or have its destination changed and exclusion filters added. - Source: entries/2026/03/10/logging-exports.md - Source hash: a3ba07d98be6ea71 - Date: 2026-03-11 ### logging-error-reporting-same-project-only [IN] OBSERVATION Error Reporting only analyzes log entries stored in log buckets within the same project where Error Reporting runs. - Source: entries/2026/03/10/logging-routing.md - Source hash: d13d78598a5b63b1 - Date: 2026-03-11 ### logging-exclusion-filters-post-ingestion [IN] OBSERVATION Exclusion filters do not reduce `entries.write` API quota consumption because they are applied after the Logging API has already received the entries. - Source: entries/2026/03/10/logging-exports.md - Source hash: a3ba07d98be6ea71 - Date: 2026-03-11 ### logging-export-has-temporal-reliability-gaps [IN] OBSERVATION Cloud Logging export has temporal reliability gaps despite the robust two-tier default architecture: sinks are not retroactive (entries received before sink creation or during misconfiguration are permanently lost), Cloud Storage sink destinations can delay initial routing by several hours, and only the immutable `_Required` sink guarantees uninterrupted routing — making log completeness in custom destinations a best-effort property, not a guarantee. ### logging-five-sink-destinations [IN] OBSERVATION Log sink supported destinations are: log bucket, BigQuery dataset, Cloud Storage bucket, Pub/Sub topic, and Google Cloud project. - Source: entries/2026/03/10/logging-overview.md - Source hash: 1e1bd1b762bff702 - Date: 2026-03-11 ### logging-intercepting-aggregated-sink-blocks-child [IN] OBSERVATION Intercepting aggregated sinks prevent child resource sinks from processing matched entries, except the child's `_Required` sink which always processes originating entries. - Source: entries/2026/03/10/logging-exports.md - Source hash: a3ba07d98be6ea71 - Date: 2026-03-11 ### logging-linked-bigquery-datasets-read-only [IN] OBSERVATION Linked BigQuery datasets created from log buckets are read-only and must never be set as a sink destination. - Source: entries/2026/03/10/logging-exports.md - Source hash: a3ba07d98be6ea71 - Date: 2026-03-11 ### logging-log-router-per-resource [IN] OBSERVATION Each Google Cloud project, billing account, folder, and organization has its own Log Router that temporarily buffers and routes log entries through sinks. - Source: entries/2026/03/10/logging-exports.md - Source hash: a3ba07d98be6ea71 - Date: 2026-03-11 ### logging-ops-agent-recommended-for-vms [IN] OBSERVATION The Ops Agent is the recommended agent for collecting application and third-party logs on Compute Engine VMs. - Source: entries/2026/03/10/logging-overview.md - Source hash: 1e1bd1b762bff702 - Date: 2026-03-11 ### logging-required-sink-immutable [IN] OBSERVATION The `_Required` sink is system-created and immutable — it cannot be modified or deleted — and routes Admin Activity, System Event, and Access Transparency audit logs to the `_Required` log bucket. - Source: entries/2026/03/10/logging-exports.md - Source hash: a3ba07d98be6ea71 - Date: 2026-03-11 ### logging-sink-one-hop-limit [IN] OBSERVATION When a sink routes log entries to a Google Cloud project as destination, sinks in that destination project cannot reroute the entries to another project (one-hop limit). - Source: entries/2026/03/10/logging-exports.md - Source hash: a3ba07d98be6ea71 - Date: 2026-03-11 ### logging-sinks-not-retroactive [IN] OBSERVATION Log sinks cannot retroactively route entries received before creation or during misconfiguration; the "Copy logs" feature can retroactively copy from a log bucket to Cloud Storage. - Source: entries/2026/03/10/logging-routing.md - Source hash: d13d78598a5b63b1 - Date: 2026-03-11 ### logging-timestamp-discard-rules [IN] OBSERVATION Log entries with timestamps older than the retention period or more than 24 hours in the future are discarded by the Log Router. - Source: entries/2026/03/10/logging-exports.md - Source hash: a3ba07d98be6ea71 - Date: 2026-03-11 ### logging-two-query-interfaces [IN] OBSERVATION Cloud Logging provides two query interfaces: Logs Explorer for troubleshooting individual entries, and Log Analytics for SQL-based trend analysis. - Source: entries/2026/03/10/logging-overview.md - Source hash: 1e1bd1b762bff702 - Date: 2026-03-11 ### memorystore-cluster-instance-hierarchy [IN] OBSERVATION Memorystore for Redis Cluster has a hierarchical resource structure: Instance → Shards → Nodes (primary + replicas), where "instance" and "cluster" are interchangeable terms. - Source: entries/2026/03/10/memorystore-cluster.md - Source hash: ebfc180b23f0845b - Date: 2026-03-11 ### memorystore-cluster-redis-7x [IN] OBSERVATION Memorystore for Redis Cluster is based on open-source Redis 7.x and supports a subset of the total Redis command library (not all commands available). - Source: entries/2026/03/10/memorystore-cluster.md - Source hash: ebfc180b23f0845b - Date: 2026-03-11 ### memorystore-cluster-shard-replicas [IN] OBSERVATION Each Memorystore for Redis Cluster shard has exactly 1 primary node and up to 5 replica nodes, with replicas automatically distributed across zones for HA. - Source: entries/2026/03/10/memorystore-cluster.md - Source hash: ebfc180b23f0845b - Date: 2026-03-11 ### memorystore-cluster-vpc-prerequisite [IN] OBSERVATION VPC networking must be configured before creating a Memorystore for Redis Cluster instance. - Source: entries/2026/03/10/memorystore-cluster.md - Source hash: ebfc180b23f0845b - Date: 2026-03-11 ### memorystore-redis-async-replication [IN] OBSERVATION Memorystore for Redis uses asynchronous replication — acknowledged writes may be lost during failover because replicas can lag behind the primary. - Source: entries/2026/03/10/memorystore-redis-ha.md - Source hash: f6f70dc1e185d7a3 - Date: 2026-03-11 ### memorystore-redis-basic-tier-no-replication [IN] OBSERVATION Memorystore for Redis Basic Tier has no replication, no automatic failover, and is a standalone cache instance. - Source: entries/2026/03/10/memorystore-redis-overview.md - Source hash: aa6873d2f73f4a1b - Date: 2026-03-11 ### memorystore-redis-constrained-operational-model [IN] OBSERVATION Memorystore for Redis operates under a constrained model compared to self-managed Redis: private IP only (requiring VPC connectors for serverless access), RDB-only persistence (no AOF, creating a data loss window between snapshots), 300 GB maximum instance size, and Basic Tier entirely lacking replication — workloads requiring AOF durability, public access, or instances larger than 300 GB cannot use the managed service. ### memorystore-redis-failover-least-lag [IN] OBSERVATION During automatic failover, Memorystore for Redis promotes the replica with the least replication lag. - Source: entries/2026/03/10/memorystore-redis-ha.md - Source hash: f6f70dc1e185d7a3 - Date: 2026-03-11 ### memorystore-redis-failover-same-ip [IN] OBSERVATION The connection string and IP address remain the same after a Memorystore for Redis failover — no application changes are needed. - Source: entries/2026/03/10/memorystore-redis-ha.md - Source hash: f6f70dc1e185d7a3 - Date: 2026-03-11 ### memorystore-redis-ha-requires-standard-tier [IN] OBSERVATION Memorystore for Redis Standard Tier (not Basic) is required for high availability and data replication. - Source: entries/2026/03/10/memorystore-redis-ha.md - Source hash: f6f70dc1e185d7a3 - Date: 2026-03-11 ### memorystore-redis-io-threads-m3-plus-redis6 [IN] OBSERVATION Memorystore for Redis I/O threads require M3 or higher capacity tier and Redis 6.x or later. - Source: entries/2026/03/10/memorystore-redis-overview.md - Source hash: aa6873d2f73f4a1b - Date: 2026-03-11 ### memorystore-redis-manual-failover-no-read-replicas [IN] OBSERVATION Manual failover via API is not supported for Memorystore for Redis instances with read replicas enabled. - Source: entries/2026/03/10/memorystore-redis-ha.md - Source hash: f6f70dc1e185d7a3 - Date: 2026-03-11 ### memorystore-redis-max-instance-size-300gb [IN] OBSERVATION Memorystore for Redis maximum instance size is 300 GB for both Basic and Standard tiers. - Source: entries/2026/03/10/memorystore-redis-overview.md - Source hash: aa6873d2f73f4a1b - Date: 2026-03-11 ### memorystore-redis-max-read-replicas-5 [IN] OBSERVATION Memorystore for Redis supports up to 5 read replicas on Standard Tier only, each adding 16 Gbps read throughput. - Source: entries/2026/03/10/memorystore-redis-overview.md - Source hash: aa6873d2f73f4a1b - Date: 2026-03-11 ### memorystore-redis-no-aof-persistence [IN] OBSERVATION Memorystore for Redis does not support AOF persistence; only RDB snapshots are available for data persistence. - Source: entries/2026/03/10/memorystore-redis-overview.md - Source hash: aa6873d2f73f4a1b - Date: 2026-03-11 ### memorystore-redis-private-ip-only [IN] OBSERVATION Memorystore for Redis instances use private IPs only and are not exposed to the public internet; clients must connect via the same VPC network. - Source: entries/2026/03/10/memorystore-redis-overview.md - Source hash: aa6873d2f73f4a1b - Date: 2026-03-11 ### memorystore-redis-read-replicas-1-to-5 [IN] OBSERVATION Memorystore for Redis supports 1 to 5 read replicas when readReplicaMode is enabled, providing both read distribution and HA failover targets. - Source: entries/2026/03/10/memorystore-redis-ha.md - Source hash: f6f70dc1e185d7a3 - Date: 2026-03-11 ### memorystore-redis-serverless-vpc-connector-required [IN] OBSERVATION Serverless environments (App Engine, Cloud Run, Cloud Run functions) require a Serverless VPC Access connector to reach Memorystore for Redis. - Source: entries/2026/03/10/memorystore-redis-overview.md - Source hash: aa6873d2f73f4a1b - Date: 2026-03-11 ### memorystore-redis-standard-tier-sla-99-9 [IN] OBSERVATION Memorystore for Redis Standard Tier provides a 99.9% availability SLA with cross-zone replication and automatic failover. - Source: entries/2026/03/10/memorystore-redis-overview.md - Source hash: aa6873d2f73f4a1b - Date: 2026-03-11 ### monitoring-auto-collects-gcp-metrics-no-agent [IN] OBSERVATION Cloud Monitoring automatically collects metrics for most GCP services without requiring an agent. - Source: entries/2026/03/10/monitoring-overview.md - Source hash: 2bc52d66d74dda79 - Date: 2026-03-11 ### monitoring-cloud-endpoints-serviceruntime-api [IN] OBSERVATION Cloud Endpoints metrics use the `serviceruntime` metric type and write against the `api` monitored-resource type. - Source: entries/2026/03/10/monitoring-metrics.md - Source hash: ef67604b9351afe9 - Date: 2026-03-11 ### monitoring-forecast-window-1h-to-7d [IN] OBSERVATION Cloud Monitoring forecasted metric-value condition has a forecast window ranging from 1 hour to 7 days. - Source: entries/2026/03/10/monitoring-alerting.md - Source hash: c1d7f0d1bdf93949 - Date: 2026-03-11 ### monitoring-gke-legacy-vs-new-metric-prefix [IN] OBSERVATION Legacy GKE metrics use the `container.googleapis.com` prefix; newer GKE metrics use the `kubernetes.io` prefix. - Source: entries/2026/03/10/monitoring-metrics.md - Source hash: ef67604b9351afe9 - Date: 2026-03-11 ### monitoring-log-vs-sql-alerts-scope [IN] OBSERVATION Log-based alerts monitor individual log entries; SQL-based alerts monitor aggregations across multiple log entries. - Source: entries/2026/03/10/monitoring-alerting.md - Source hash: c1d7f0d1bdf93949 - Date: 2026-03-11 ### monitoring-metric-absence-max-retest-23-5-hours [IN] OBSERVATION Cloud Monitoring metric-absence condition has a maximum retest window of 23.5 hours. - Source: entries/2026/03/10/monitoring-alerting.md - Source hash: c1d7f0d1bdf93949 - Date: 2026-03-11 ### monitoring-metric-incidents-auto-close [IN] OBSERVATION Cloud Monitoring automatically closes incidents and sends closure notifications when metric-based policy conditions are no longer met. - Source: entries/2026/03/10/monitoring-alerting.md - Source hash: c1d7f0d1bdf93949 - Date: 2026-03-11 ### monitoring-metric-type-naming-convention [IN] OBSERVATION Cloud Monitoring metric type names are prefixed by service name (e.g., `compute.googleapis.com/instance/cpu/utilization`). - Source: entries/2026/03/10/monitoring-metrics.md - Source hash: ef67604b9351afe9 - Date: 2026-03-11 ### monitoring-metrics-scope-multi-project-aws [IN] OBSERVATION A Cloud Monitoring metrics scope allows monitoring multiple GCP projects and AWS accounts from a single scoping project. - Source: entries/2026/03/10/monitoring-overview.md - Source hash: 2bc52d66d74dda79 - Date: 2026-03-11 ### monitoring-one-time-series-per-label-combination [IN] OBSERVATION Cloud Monitoring writes one time series per unique combination of resource labels and metric labels. - Source: entries/2026/03/10/monitoring-overview.md - Source hash: 2bc52d66d74dda79 - Date: 2026-03-11 ### monitoring-ops-agent-for-app-metrics-on-gce [IN] OBSERVATION The Ops Agent must be installed on Compute Engine VMs to collect application and third-party metrics (Apache, Nginx, MongoDB, PostgreSQL). - Source: entries/2026/03/10/monitoring-overview.md - Source hash: 2bc52d66d74dda79 - Date: 2026-03-11 ### monitoring-promql-supported-in-alerting [IN] OBSERVATION PromQL can be used in Cloud Monitoring alerting policy conditions for complex expressions and dynamic thresholds. - Source: entries/2026/03/10/monitoring-alerting.md - Source hash: c1d7f0d1bdf93949 - Date: 2026-03-11 ### monitoring-snooze-temporarily-disables-policy [IN] OBSERVATION Cloud Monitoring alerting policies monitor continuously; a snooze temporarily disables a policy for a defined period. - Source: entries/2026/03/10/monitoring-alerting.md - Source hash: c1d7f0d1bdf93949 - Date: 2026-03-11 ### monitoring-three-alerting-policy-types [IN] OBSERVATION Cloud Monitoring supports three alerting policy types: metric-based, log-based, and SQL-based (SQL-based is Public Preview). - Source: entries/2026/03/10/monitoring-alerting.md - Source hash: c1d7f0d1bdf93949 - Date: 2026-03-11 ### monitoring-three-metric-kinds [IN] OBSERVATION Cloud Monitoring has three metric kinds: GAUGE (value at a point in time), CUMULATIVE (accumulated over time), and DELTA (change over a period). - Source: entries/2026/03/10/monitoring-overview.md - Source hash: 2bc52d66d74dda79 - Date: 2026-03-11 ### monitoring-vm-manager-osconfig-prefix [IN] OBSERVATION VM Manager metrics use the `osconfig.googleapis.com` prefix, not `compute.googleapis.com`. - Source: entries/2026/03/10/monitoring-metrics.md - Source hash: ef67604b9351afe9 - Date: 2026-03-11 ### multi-network-connectivity-constrained-both-models [IN] OBSERVATION GCP multi-network connectivity is fundamentally constrained regardless of model: Shared VPC requires same-organization hierarchy with single-host attachment and doesn't migrate existing resources, while VPC peering is non-transitive, prohibits subnet overlap, and never exchanges IAM or dynamic routes — forcing an architecture-level choice between organizational coupling (Shared VPC) and connectivity limitations (peering) with no unconstrained option. ### partner-interconnect-50mbps-to-50gbps [IN] OBSERVATION Partner Interconnect supports VLAN attachment capacities from 50 Mbps to 50 Gbps. - Source: entries/2026/03/11/interconnect-partner.md - Source hash: c5b50694633e9ab7 - Date: 2026-03-11 ### partner-interconnect-99-99-sla-requirements [IN] OBSERVATION Partner Interconnect 99.99% SLA requires 4 VLAN attachments across 2 metros, one per edge availability domain, with 2 Cloud Routers (one per region) and global routing enabled on the VPC. - Source: entries/2026/03/11/interconnect-partner.md - Source hash: c5b50694633e9ab7 - Date: 2026-03-11 ### partner-interconnect-layer2-vs-layer3 [IN] OBSERVATION Partner Interconnect Layer 2 requires customer-configured BGP; Layer 3 has fully automated BGP handled by the service provider and supports pre-activation. - Source: entries/2026/03/11/interconnect-partner.md - Source hash: c5b50694633e9ab7 - Date: 2026-03-11 ### partner-interconnect-med-values-layer3-limitation [IN] OBSERVATION MED values cannot be sent or learned over Layer 3 Partner Interconnect connections because MED values cannot pass through autonomous systems. - Source: entries/2026/03/11/interconnect-partner.md - Source hash: c5b50694633e9ab7 - Date: 2026-03-11 ### partner-interconnect-sla-covers-vpc-to-provider-only [IN] OBSERVATION Google's SLA for Partner Interconnect covers only connectivity between VPC and the service provider's network, not the service-provider-to-customer leg. - Source: entries/2026/03/11/interconnect-partner.md - Source hash: c5b50694633e9ab7 - Date: 2026-03-11 ### partner-interconnect-via-service-provider [IN] OBSERVATION Partner Interconnect uses a third-party service provider as an intermediary, suited for when a data center cannot reach a Dedicated Interconnect colocation facility or bandwidth needs are below 10 Gbps. - Source: entries/2026/03/11/interconnect-partner.md - Source hash: c5b50694633e9ab7 - Date: 2026-03-11 ### peering-dynamic-routes-use-exporting-vpc-mode [IN] OBSERVATION Peering dynamic routes apply based on the dynamic routing mode of the exporting VPC network, not the importing one. - Source: entries/2026/03/10/vpc-routes.md - Source hash: 5ea29512bcefff8c - Date: 2026-03-11 ### pga-disabled-blocks-api-access [IN] OBSERVATION When PGA is disabled on a subnet, internal-only VMs on that subnet cannot reach Google APIs or services. - Source: entries/2026/03/10/vpc-private-google-access.md - Source hash: 641df6ffbfb6ff1b - Date: 2026-03-11 ### pga-enabled-per-subnet [IN] OBSERVATION Private Google Access (PGA) is enabled per subnet, not per VM or per VPC. - Source: entries/2026/03/10/vpc-private-google-access.md - Source hash: 641df6ffbfb6ff1b - Date: 2026-03-11 ### pga-only-affects-internal-only-vms [IN] OBSERVATION Private Google Access only affects VMs without external IP addresses; VMs with external IPs can already reach Google APIs normally and are unaffected by PGA. - Source: entries/2026/03/10/vpc-private-google-access.md - Source hash: 641df6ffbfb6ff1b - Date: 2026-03-11 ### pga-requires-dns-routing-firewall [IN] OBSERVATION Private Google Access requires correct DNS, routing, and firewall configuration in the VPC network to function. - Source: entries/2026/03/10/vpc-private-google-access.md - Source hash: 641df6ffbfb6ff1b - Date: 2026-03-11 ### pga-source-ip-primary-or-alias [IN] OBSERVATION PGA traffic can use the VM's primary internal IP or an alias IP range as the source IP. - Source: entries/2026/03/10/vpc-private-google-access.md - Source hash: 641df6ffbfb6ff1b - Date: 2026-03-11 ### pga-vs-psa-vs-psc-distinction [IN] OBSERVATION Private Google Access reaches Google APIs, Private Services Access connects to services via Service Networking API/peering (e.g., Cloud SQL private IP), and Private Service Connect provides endpoint-based managed service access. - Source: entries/2026/03/10/vpc-private-google-access.md - Source hash: 641df6ffbfb6ff1b - Date: 2026-03-11 ### policy-based-routes-never-exchanged-via-peering [IN] OBSERVATION Policy-based routes are never exchanged via VPC Network Peering. - Source: entries/2026/03/10/vpc-routes.md - Source hash: 5ea29512bcefff8c - Date: 2026-03-11 ### prohibited-subnet-ranges [IN] OBSERVATION Prohibited VPC subnet ranges include: Google public IPs, 0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16, 224.0.0.0/4, 255.255.255.255/32, and Private Google Access VIPs (199.36.153.4/30, 199.36.153.8/30). - Source: entries/2026/03/10/vpc-subnets.md - Source hash: 0a93f184ecf6ad03 - Date: 2026-03-11 ### pubsub-at-least-once-delivery [IN] OBSERVATION Pub/Sub guarantees at-least-once delivery — duplicates are possible, and publish-side duplicates can have different `publishTime` values with the same `messageId`. - Source: entries/2026/03/10/pubsub-publisher.md - Source hash: a526c8035db6642f - Date: 2026-03-11 ### pubsub-attribute-key-no-goog-prefix [IN] OBSERVATION Pub/Sub message attribute keys must not start with `goog` (reserved prefix). - Source: entries/2026/03/10/pubsub-publisher.md - Source hash: a526c8035db6642f - Date: 2026-03-11 ### pubsub-bigquery-export-uses-topic-schema [IN] OBSERVATION BigQuery export subscriptions can leverage the topic's schema, which is not available with the basic Dataflow template. - Source: entries/2026/03/10/pubsub-subscriber.md - Source hash: 43ff471ae30663f0 - Date: 2026-03-11 ### pubsub-dead-letter-attempt-count-approximate [IN] OBSERVATION Delivery attempt counting for dead-letter topics is best-effort and approximate — messages may be forwarded after fewer or more attempts than configured. - Source: entries/2026/03/10/pubsub-dead-letter.md - Source hash: 71cd69ef68a6632a - Date: 2026-03-11 ### pubsub-dead-letter-cross-project-supported [IN] OBSERVATION Dead-letter topics can reside in a different project from the subscription using `--dead-letter-topic-project`. - Source: entries/2026/03/10/pubsub-dead-letter.md - Source hash: 71cd69ef68a6632a - Date: 2026-03-11 ### pubsub-dead-letter-iam-requirements [IN] OBSERVATION The Pub/Sub service account needs `roles/pubsub.publisher` on the dead-letter topic and `roles/pubsub.subscriber` on the source subscription, granted after creating the dead-letter topic. - Source: entries/2026/03/10/pubsub-dead-letter.md - Source hash: 71cd69ef68a6632a - Date: 2026-03-11 ### pubsub-dead-letter-is-subscription-property [IN] OBSERVATION Dead lettering is configured as a subscription property, not on the source topic. - Source: entries/2026/03/10/pubsub-dead-letter.md - Source hash: 71cd69ef68a6632a - Date: 2026-03-11 ### pubsub-dead-letter-max-delivery-attempts-range [IN] OBSERVATION The `max-delivery-attempts` parameter ranges from 5 (default) to 100. - Source: entries/2026/03/10/pubsub-dead-letter.md - Source hash: 71cd69ef68a6632a - Date: 2026-03-11 ### pubsub-dead-letter-must-have-subscription [IN] OBSERVATION The dead-letter topic must have its own subscription to consume forwarded messages; otherwise forwarded messages are lost. - Source: entries/2026/03/10/pubsub-dead-letter.md - Source hash: 71cd69ef68a6632a - Date: 2026-03-11 ### pubsub-dead-letter-pull-inactive-counter-reset [IN] OBSERVATION For pull subscriptions with inactive subscribers, the tracked delivery attempt count may reset to zero, causing more deliveries than the configured maximum. - Source: entries/2026/03/10/pubsub-dead-letter.md - Source hash: 71cd69ef68a6632a - Date: 2026-03-11 ### pubsub-exactly-once-default-ack-deadline-60s [IN] OBSERVATION The default ack deadline for exactly-once subscriptions is 60 seconds (vs. the normal default). - Source: entries/2026/03/10/pubsub-exactly-once.md - Source hash: 3c5f94941b0ef9cb - Date: 2026-03-11 ### pubsub-exactly-once-expired-ack-returns-invalid-argument [IN] OBSERVATION Expired ack IDs return INVALID_ARGUMENT for exactly-once subscriptions (unlike regular subscriptions which return OK). - Source: entries/2026/03/10/pubsub-exactly-once.md - Source hash: 3c5f94941b0ef9cb - Date: 2026-03-11 ### pubsub-exactly-once-ordering-throughput-limit [IN] OBSERVATION When combining ordering keys with exactly-once delivery, acks must be in-order and throughput drops to approximately thousands of messages per second. - Source: entries/2026/03/10/pubsub-exactly-once.md - Source hash: 3c5f94941b0ef9cb - Date: 2026-03-11 ### pubsub-exactly-once-publish-duplicates-still-possible [IN] OBSERVATION Publish-side duplicates can still occur even with exactly-once delivery enabled (publisher retries can cause duplicate messages). - Source: entries/2026/03/10/pubsub-exactly-once.md - Source hash: 3c5f94941b0ef9cb - Date: 2026-03-11 ### pubsub-exactly-once-pull-only [IN] OBSERVATION Exactly-once delivery is only supported on pull subscriptions (including StreamingPull), not push or export subscriptions. - Source: entries/2026/03/10/pubsub-exactly-once.md - Source hash: 3c5f94941b0ef9cb - Date: 2026-03-11 ### pubsub-exactly-once-regional-scope [IN] OBSERVATION The exactly-once delivery guarantee only applies when subscribers connect to the service in the same region; multi-region subscribers may still receive duplicates. - Source: entries/2026/03/10/pubsub-exactly-once.md - Source hash: 3c5f94941b0ef9cb - Date: 2026-03-11 ### pubsub-export-replaces-dataflow-no-transform [IN] OBSERVATION Export subscriptions replace Dataflow pipelines when no transformation is needed before writing to BigQuery or Cloud Storage. - Source: entries/2026/03/10/pubsub-subscriber.md - Source hash: 43ff471ae30663f0 - Date: 2026-03-11 ### pubsub-max-100-attributes-per-message [IN] OBSERVATION A Pub/Sub message supports a maximum of 100 attributes, with keys ≤256 bytes and values ≤1024 bytes. - Source: entries/2026/03/10/pubsub-publisher.md - Source hash: a526c8035db6642f - Date: 2026-03-11 ### pubsub-message-requires-data-or-attribute [IN] OBSERVATION A Pub/Sub message must contain at least one of: non-empty data, ordering key, or attributes — all are not required simultaneously. - Source: entries/2026/03/10/pubsub-publisher.md - Source hash: a526c8035db6642f - Date: 2026-03-11 ### pubsub-ordering-constrains-throughput-and-recovery [IN] OBSERVATION Pub/Sub message ordering imposes cascading operational constraints: it is immutable after subscription creation, caps throughput at 1 MBps per key, and redelivery of one message forces redelivery of all subsequent messages for that key. ### pubsub-ordering-immutable-at-creation [IN] OBSERVATION Message ordering is set at subscription creation and cannot be changed afterward. - Source: entries/2026/03/10/pubsub-ordering.md - Source hash: dd00ca544b665fcb - Date: 2026-03-11 ### pubsub-ordering-key-fail-requires-resume-publish [IN] OBSERVATION If a message with an ordering key fails to publish, subsequent messages with that same key fail until `resumePublish()` is called in the client library. - Source: entries/2026/03/10/pubsub-publisher.md - Source hash: a526c8035db6642f - Date: 2026-03-11 ### pubsub-ordering-key-throughput-limit-1mbps [IN] OBSERVATION Publish throughput per ordering key is limited to 1 MBps. - Source: entries/2026/03/10/pubsub-ordering.md - Source hash: dd00ca544b665fcb - Date: 2026-03-11 ### pubsub-ordering-keys-not-partitions [IN] OBSERVATION Ordering keys are not equivalent to partitions; they are expected to have much higher cardinality than partitions in partition-based systems. - Source: entries/2026/03/10/pubsub-ordering.md - Source hash: dd00ca544b665fcb - Date: 2026-03-11 ### pubsub-ordering-not-for-dataflow [IN] OBSERVATION Message ordering should not be enabled for Dataflow subscriptions — Dataflow has its own ordering mechanism via windowing and ordering keys can reduce pipeline performance. - Source: entries/2026/03/10/pubsub-ordering.md - Source hash: dd00ca544b665fcb - Date: 2026-03-11 ### pubsub-ordering-push-one-outstanding-per-key [IN] OBSERVATION Push subscriptions allow only one outstanding message per ordering key, resulting in the worst throughput for ordered workloads. - Source: entries/2026/03/10/pubsub-ordering.md - Source hash: dd00ca544b665fcb - Date: 2026-03-11 ### pubsub-ordering-redelivery-cascades-subsequent [IN] OBSERVATION Redelivery of one message causes all subsequent messages for that ordering key to be redelivered, even previously acknowledged ones. - Source: entries/2026/03/10/pubsub-ordering.md - Source hash: dd00ca544b665fcb - Date: 2026-03-11 ### pubsub-per-message-parallelism [IN] OBSERVATION Pub/Sub uses per-message parallelism (leasing individual messages), not partition-based parallelism like Kafka/Pulsar. - Source: entries/2026/03/10/pubsub-overview.md - Source hash: 4dbb99ab7b8e0975 - Date: 2026-03-11 ### pubsub-publisher-iam-role [IN] OBSERVATION `roles/pubsub.publisher` is the minimum IAM role needed to publish messages to a topic. - Source: entries/2026/03/10/pubsub-publisher.md - Source hash: a526c8035db6642f - Date: 2026-03-11 ### pubsub-pull-load-balances-across-subscribers [IN] OBSERVATION Multiple pull subscribers on the same subscription each receive a subset of messages (load balancing behavior). - Source: entries/2026/03/10/pubsub-subscriber.md - Source hash: 43ff471ae30663f0 - Date: 2026-03-11 ### pubsub-pull-supports-dynamic-ack-deadline [IN] OBSERVATION Pull subscriptions support dynamic acknowledgment deadline extension, allowing arbitrarily long processing times. - Source: entries/2026/03/10/pubsub-subscriber.md - Source hash: 43ff471ae30663f0 - Date: 2026-03-11 ### pubsub-push-delivers-http-post [IN] OBSERVATION Pub/Sub push delivery sends messages as HTTP POST requests to webhooks. - Source: entries/2026/03/10/pubsub-overview.md - Source hash: 4dbb99ab7b8e0975 - Date: 2026-03-11 ### pubsub-push-one-message-per-request [IN] OBSERVATION Push subscriptions deliver one message per request and cap outstanding messages; flow control is server-managed. - Source: entries/2026/03/10/pubsub-subscriber.md - Source hash: 43ff471ae30663f0 - Date: 2026-03-11 ### pubsub-push-requires-valid-ssl-cert [IN] OBSERVATION Push endpoints must have DNS-resolvable names and valid SSL certificates (non-self-signed). - Source: entries/2026/03/10/pubsub-subscriber.md - Source hash: 43ff471ae30663f0 - Date: 2026-03-11 ### pubsub-rest-api-data-base64-encoded [IN] OBSERVATION Pub/Sub REST API message data must be base64-encoded. - Source: entries/2026/03/10/pubsub-publisher.md - Source hash: a526c8035db6642f - Date: 2026-03-11 ### pubsub-service-to-service-not-client [IN] OBSERVATION Pub/Sub is designed for service-to-service communication; use Firebase for client-to-server and Cloud Tasks for async service calls. - Source: entries/2026/03/10/pubsub-overview.md - Source hash: 4dbb99ab7b8e0975 - Date: 2026-03-11 ### pubsub-three-subscription-types [IN] OBSERVATION Pub/Sub offers three subscription types: Pull, Push, and Export (BigQuery and Cloud Storage). - Source: entries/2026/03/10/pubsub-subscriber.md - Source hash: 43ff471ae30663f0 - Date: 2026-03-11 ### pubsub-typical-latency-100ms [IN] OBSERVATION Pub/Sub typical latency is approximately 100 milliseconds. - Source: entries/2026/03/10/pubsub-overview.md - Source hash: 4dbb99ab7b8e0975 - Date: 2026-03-11 ### secretmanager-accessor-only-grants-versions-access [IN] OBSERVATION The `roles/secretmanager.secretAccessor` role grants only `secretmanager.versions.access` — it cannot list secrets or view metadata. - Source: entries/2026/03/11/secretmanager-access-control.md - Source hash: 615e97142262b712 - Date: 2026-03-11 ### secretmanager-avoid-env-vars-and-files [IN] OBSERVATION Best practice is to avoid passing secrets via environment variables or filesystem and instead use the Secret Manager API directly via client libraries. - Source: entries/2026/03/11/secretmanager-best-practices.md - Source hash: 08524a165dc98d34 - Date: 2026-03-11 ### secretmanager-billing-enabled-disabled-not-destroyed [IN] OBSERVATION Billing applies to Enabled and Disabled secret versions; Destroyed versions are free. - Source: entries/2026/03/11/secretmanager-versions.md - Source hash: 07bc6f1865583b39 - Date: 2026-03-11 ### secretmanager-compute-gke-cloud-platform-scope [IN] OBSERVATION Workloads on Compute Engine or GKE require the `cloud-platform` OAuth scope to use Secret Manager. - Source: entries/2026/03/11/secretmanager-versions.md - Source hash: 07bc6f1865583b39 - Date: 2026-03-11 ### secretmanager-create-requires-admin-role [IN] OBSERVATION Creating secrets requires the `roles/secretmanager.admin` (Secret Manager Admin) IAM role. - Source: entries/2026/03/11/secretmanager-creating-secrets.md - Source hash: 1a9b8f2a55d337e9 - Date: 2026-03-11 ### secretmanager-creating-secret-no-auto-version [IN] OBSERVATION Creating a secret via CLI/API does not automatically create a version; the Console creates a first version only if a value is provided during creation. - Source: entries/2026/03/11/secretmanager-creating-secrets.md - Source hash: 1a9b8f2a55d337e9 - Date: 2026-03-11 ### secretmanager-default-encryption-aes256-tls [IN] OBSERVATION Secret Manager encrypts all secrets with AES-256 at rest and TLS in transit by default with no configuration required; CMEK is available for customer-controlled keys. - Source: entries/2026/03/11/secretmanager-overview.md - Source hash: e2d124d0ca7fd01a - Date: 2026-03-11 ### secretmanager-destroyed-version-irreversible [IN] OBSERVATION The Destroyed state for a secret version is irreversible — contents are permanently discarded and the version cannot transition to another state. - Source: entries/2026/03/11/secretmanager-versions.md - Source hash: 07bc6f1865583b39 - Date: 2026-03-11 ### secretmanager-disable-before-destroy [IN] OBSERVATION Best practice is to disable secret versions before destroying them; disabling is reversible, destroying is not. - Source: entries/2026/03/11/secretmanager-best-practices.md - Source hash: 08524a165dc98d34 - Date: 2026-03-11 ### secretmanager-editor-no-secret-access [IN] OBSERVATION The basic `roles/editor` role does not include `secretmanager.versions.access`; only `roles/owner` among basic roles grants secret access. - Source: entries/2026/03/11/secretmanager-access-control.md - Source hash: 615e97142262b712 - Date: 2026-03-11 ### secretmanager-five-predefined-iam-roles [IN] OBSERVATION Secret Manager has five predefined IAM roles: Admin, Secret Accessor, Secret Version Adder, Secret Version Manager, and Viewer. - Source: entries/2026/03/11/secretmanager-access-control.md - Source hash: 615e97142262b712 - Date: 2026-03-11 ### secretmanager-gce-gke-cloud-platform-scope-required [IN] OBSERVATION Workloads on Compute Engine or GKE require the `cloud-platform` OAuth scope to use Secret Manager. - Source: entries/2026/03/11/secretmanager-access-control.md - Source hash: 615e97142262b712 - Date: 2026-03-11 ### secretmanager-iam-conditions-date-and-resource [IN] OBSERVATION Secret Manager supports IAM Conditions for date/time-based expirable access and resource-attribute filtering (e.g., secret name prefix, specific version). - Source: entries/2026/03/11/secretmanager-access-control.md - Source hash: 615e97142262b712 - Date: 2026-03-11 ### secretmanager-iam-granularity-mismatch [IN] OBSERVATION Secret Manager IAM has a granularity mismatch between role scope and resource structure: roles are granted at the secret level (not per-version), but secrets have three version states (Enabled/Disabled/Destroyed) with distinct access semantics — and the accessor role grants only `versions.access` (no list or metadata), while the viewer role sees metadata but not payloads, forcing dual-role grants for full operational visibility without violating least privilege. ### secretmanager-iam-roles-secret-level-not-version [IN] OBSERVATION IAM roles cannot be granted on a secret version — only on the secret itself. - Source: entries/2026/03/11/secretmanager-versions.md - Source hash: 07bc6f1865583b39 - Date: 2026-03-11 ### secretmanager-lowest-iam-resource-is-secret [IN] OBSERVATION The lowest-level resource for granting Secret Manager IAM roles is the individual secret. - Source: entries/2026/03/11/secretmanager-access-control.md - Source hash: 615e97142262b712 - Date: 2026-03-11 ### secretmanager-no-expiration-production [IN] OBSERVATION Expiration on production secrets should be avoided because it causes irreversible deletion; use time-based IAM conditions instead. - Source: entries/2026/03/11/secretmanager-best-practices.md - Source hash: 08524a165dc98d34 - Date: 2026-03-11 ### secretmanager-pin-version-not-latest [IN] OBSERVATION Best practice is to reference secrets by specific version number in production, not the `latest` alias, to enable validation and rollback. - Source: entries/2026/03/11/secretmanager-best-practices.md - Source hash: 08524a165dc98d34 - Date: 2026-03-11 ### secretmanager-production-access-pattern [IN] OBSERVATION Production secret access should use the Secret Manager API directly (not env vars/files), pin to specific version numbers (not latest), and account for the fact that Cloud Run env var secrets resolve only at startup — creating a specific operational model. ### secretmanager-production-integration-requires-application-awareness [IN] OBSERVATION Secret Manager production integration requires application-level awareness across three dimensions: the access pattern (API-direct with pinned versions, avoiding env var indirection), the rotation model (notification-only, requiring application code to handle credential refresh), and the IAM granularity (per-secret not per-version, meaning version-level access control must be enforced by application logic) — the service stores secrets but delegates lifecycle management to the consuming application. ### secretmanager-regional-not-replicated [IN] OBSERVATION Regional secrets are not automatically replicated across locations, unlike global secrets. - Source: entries/2026/03/11/secretmanager-regional-secrets.md - Source hash: 9e7b98127b1163cd - Date: 2026-03-11 ### secretmanager-regional-requires-regional-service [IN] OBSERVATION Regional secrets require using the regional service endpoint, not the default global service. - Source: entries/2026/03/11/secretmanager-regional-secrets.md - Source hash: 9e7b98127b1163cd - Date: 2026-03-11 ### secretmanager-regional-residency-rest-use-transit [IN] OBSERVATION Regional secrets ensure data stays within the chosen location at rest, in use, and in transit. - Source: entries/2026/03/11/secretmanager-regional-secrets.md - Source hash: 9e7b98127b1163cd - Date: 2026-03-11 ### secretmanager-regional-same-region-access-only [IN] OBSERVATION Access to regional secrets is limited to applications and services running within the same location. - Source: entries/2026/03/11/secretmanager-regional-secrets.md - Source hash: 9e7b98127b1163cd - Date: 2026-03-11 ### secretmanager-remove-rotation-schedule-removes-both [IN] OBSERVATION The `--remove-rotation-schedule` flag removes both `next_rotation_time` and `rotation_period`, while `--remove-next-rotation-time` removes only the timestamp. - Source: entries/2026/03/11/secretmanager-rotation.md - Source hash: b451d652275fa20d - Date: 2026-03-11 ### secretmanager-replication-automatic-or-user-managed [IN] OBSERVATION Every secret requires a replication policy: `automatic` (Google chooses regions, charged for one location) or `user-managed` (customer selects regions, charged per location). - Source: entries/2026/03/11/secretmanager-creating-secrets.md - Source hash: 1a9b8f2a55d337e9 - Date: 2026-03-11 ### secretmanager-rest-api-base64-payload [IN] OBSERVATION The Secret Manager REST API requires base64-encoded payload data when adding a secret version. - Source: entries/2026/03/11/secretmanager-versions.md - Source hash: 07bc6f1865583b39 - Date: 2026-03-11 ### secretmanager-rotation-next-time-min-5-minutes [IN] OBSERVATION The `next_rotation_time` for a Secret Manager rotation schedule cannot be less than 5 minutes in the future. - Source: entries/2026/03/11/secretmanager-rotation.md - Source hash: b451d652275fa20d - Date: 2026-03-11 ### secretmanager-rotation-notification-only [IN] OBSERVATION Secret Manager rotation is notification-only: it sends a Pub/Sub message rather than rotating the value, has a 5-minute minimum scheduling window, and removing the schedule clears both period and next-time — actual rotation logic must be implemented externally via subscriber code. ### secretmanager-rotation-period-min-1-hour [IN] OBSERVATION The `rotation_period` for a Secret Manager rotation schedule cannot be less than 1 hour. - Source: entries/2026/03/11/secretmanager-rotation.md - Source hash: b451d652275fa20d - Date: 2026-03-11 ### secretmanager-rotation-retry-7-days [IN] OBSERVATION Secret Manager retries failed rotation message delivery for up to 7 days, after which the rotation is canceled. - Source: entries/2026/03/11/secretmanager-rotation.md - Source hash: b451d652275fa20d - Date: 2026-03-11 ### secretmanager-rotation-sends-pubsub-not-rotates [IN] OBSERVATION Secret Manager rotation does not rotate the secret value itself — it only sends a `SECRET_ROTATE` notification to configured Pub/Sub topics; the actual rotation logic must be implemented by a subscriber. - Source: entries/2026/03/11/secretmanager-rotation.md - Source hash: b451d652275fa20d - Date: 2026-03-11 ### secretmanager-rotation-skips-if-inflight [IN] OBSERVATION Secret Manager skips scheduled rotations if an in-flight rotation already exists; concurrent rotations are prevented. - Source: entries/2026/03/11/secretmanager-rotation.md - Source hash: b451d652275fa20d - Date: 2026-03-11 ### secretmanager-secret-name-max-255-chars [IN] OBSERVATION Secret names allow uppercase/lowercase letters, numerals, hyphens, and underscores with a maximum length of 255 characters. - Source: entries/2026/03/11/secretmanager-creating-secrets.md - Source hash: 1a9b8f2a55d337e9 - Date: 2026-03-11 ### secretmanager-secret-value-max-64kib [IN] OBSERVATION Secret version values must not exceed 64 KiB in size. - Source: entries/2026/03/11/secretmanager-creating-secrets.md - Source hash: 1a9b8f2a55d337e9 - Date: 2026-03-11 ### secretmanager-secrets-global-by-default [IN] OBSERVATION Secrets are global resources by default; regional secrets exist for data residency compliance. - Source: entries/2026/03/11/secretmanager-overview.md - Source hash: e2d124d0ca7fd01a - Date: 2026-03-11 ### secretmanager-stores-values-kms-stores-keys [IN] OBSERVATION Secret Manager stores actual secret values (viewable with permissions); Cloud KMS stores cryptographic keys (never viewable/extractable). - Source: entries/2026/03/11/secretmanager-overview.md - Source hash: e2d124d0ca7fd01a - Date: 2026-03-11 ### secretmanager-version-data-immutable [IN] OBSERVATION Secret Manager secret data is immutable — modifications require adding a new version rather than changing existing ones. - Source: entries/2026/03/11/secretmanager-versions.md - Source hash: 07bc6f1865583b39 - Date: 2026-03-11 ### secretmanager-version-three-states [IN] OBSERVATION Secret versions have three states: Enabled (accessible), Disabled (exists but not accessible, re-enableable), and Destroyed (permanently discarded, irreversible). - Source: entries/2026/03/11/secretmanager-versions.md - Source hash: 07bc6f1865583b39 - Date: 2026-03-11 ### secretmanager-viewer-no-payload-access [IN] OBSERVATION The `roles/secretmanager.viewer` role can read secret and version metadata but cannot access secret payloads. - Source: entries/2026/03/11/secretmanager-access-control.md - Source hash: 615e97142262b712 - Date: 2026-03-11 ### secretmanager-vpc-service-controls-network-protection [IN] OBSERVATION VPC Service Controls can add network-level perimeter protection to Secret Manager API access in addition to IAM. - Source: entries/2026/03/11/secretmanager-best-practices.md - Source hash: 08524a165dc98d34 - Date: 2026-03-11 ### serverless-cloudsql-private-access-triple-constrained [IN] OBSERVATION Accessing Cloud SQL privately from serverless compute (Cloud Run) requires navigating three networking layers: (1) explicit VPC bridging for serverless egress, (2) private services access VPC peering for Cloud SQL, and (3) peering's inherent constraints (non-transitivity, no overlapping subnets, no IAM exchange) — each layer adds configuration surface and distinct failure modes. ### serverless-memorystore-doubly-constrained-private-access [IN] OBSERVATION Serverless access to Memorystore for Redis is doubly constrained: Memorystore enforces private-IP-only connectivity (no public exposure, 300GB cap, no AOF persistence, basic tier lacks replication) AND serverless workloads require explicit VPC bridging (Direct VPC egress or connector VMs) to reach any VPC-private resource, creating a two-layer networking dependency chain where either layer's failure blocks connectivity entirely. ### serverless-multi-tenant-compounds-bridging-and-connectivity [IN] OBSERVATION Serverless workloads in multi-tenant GCP environments face compounding network constraints from two independent layers: multi-network connectivity is fundamentally limited regardless of model (Shared VPC requires same-org hierarchy, peering is non-transitive with no IAM exchange), AND serverless resources require explicit VPC bridging just to reach any VPC network — meaning serverless in a shared network must solve both the bridging gap and the connectivity model constraints simultaneously. ### serverless-multi-tenant-worst-case-networking [IN] OBSERVATION Multi-tenant serverless architectures requiring private data access must configure the full VPC connectivity stack (VPC, NAT, connectors/direct VPC egress, private services access) for each tenant's isolation boundary, multiplying the networking complexity per tenant. ### serverless-private-data-access-five-layer-stack [IN] OBSERVATION Serverless workloads accessing private data must navigate five dependency layers: (1) VPC bridging for network egress, (2) peering non-transitivity for database reach, (3) private services access for Cloud SQL IP allocation, (4) Secret Manager API integration with fail-fast startup semantics, and (5) rotation notification gaps requiring application-level credential refresh — each layer adds a failure mode invisible from the serverless abstraction. ### serverless-production-networking-contradicts-serverless-promise [IN] OBSERVATION Production serverless workloads requiring private data access need VPC configuration, NAT gateways, and private connectivity — networking infrastructure that adds significant complexity to otherwise simple serverless deployments. ### serverless-vpc-connectivity-requires-explicit-bridging [IN] OBSERVATION Serverless resources (Cloud Run, Cloud Run functions, App Engine) cannot natively reach VPC networks — they require explicit VPC bridging via Direct VPC egress or Serverless VPC Access connectors, connectivity is egress-only from serverless to VPC, and services like Memorystore mandate this bridging for access. ### shared-vpc-billing-to-service-project [IN] OBSERVATION Shared VPC resource costs are billed to the service project, except VPN gateway egress (billed to host project) and VLAN attachment traffic (billed to attachment owner). - Source: entries/2026/03/10/vpc-shared.md - Source hash: 470ba709f9d2f58e - Date: 2026-03-11 ### shared-vpc-cannot-be-host-and-service [IN] OBSERVATION A project cannot be both a Shared VPC host project and a service project simultaneously. - Source: entries/2026/03/10/vpc-shared.md - Source hash: 470ba709f9d2f58e - Date: 2026-03-11 ### shared-vpc-existing-resources-not-migrated [IN] OBSERVATION Existing resources in a newly attached service project do not automatically use the shared network; new resources must be created to use shared subnets. - Source: entries/2026/03/10/vpc-shared.md - Source hash: 470ba709f9d2f58e - Date: 2026-03-11 ### shared-vpc-internal-dns-uses-service-project-id [IN] OBSERVATION Internal DNS names for VMs in Shared VPC use the service project's project ID, not the host project ID. - Source: entries/2026/03/10/vpc-shared.md - Source hash: 470ba709f9d2f58e - Date: 2026-03-11 ### shared-vpc-legacy-networks-not-supported [IN] OBSERVATION Legacy networks are not supported for Shared VPC. - Source: entries/2026/03/10/vpc-shared.md - Source hash: 470ba709f9d2f58e - Date: 2026-03-11 ### shared-vpc-network-user-role-grants-subnet-access [IN] OBSERVATION The compute.networkUser role grants subnet access — at project level (all subnets including future) or at subnet level (specific subnets only). - Source: entries/2026/03/10/vpc-shared.md - Source hash: 470ba709f9d2f58e - Date: 2026-03-11 ### shared-vpc-same-organization-required [IN] OBSERVATION Host and service projects must be in the same Google Cloud organization for Shared VPC. - Source: entries/2026/03/10/vpc-shared.md - Source hash: 470ba709f9d2f58e - Date: 2026-03-11 ### shared-vpc-service-project-one-host-only [IN] OBSERVATION A service project can attach to only one host project; multiple host projects are allowed per organization. - Source: entries/2026/03/10/vpc-shared.md - Source hash: 470ba709f9d2f58e - Date: 2026-03-11 ### shared-vpc-strict-organizational-hierarchy [IN] OBSERVATION Shared VPC enforces a strict organizational hierarchy for multi-tenant networking: host and service projects must share an organization, each service project attaches to exactly one host project, DNS uses service project IDs, and GKE follows the same host-service pattern for cluster networking. ### spanner-deletes-database-cmek-unavailable-30-days [IN] OBSERVATION Spanner automatically deletes a database if its CMEK key is unavailable for more than 30 consecutive days. - Source: entries/2026/03/11/kms-ekm.md - Source hash: 7d83508956eb12e9 - Date: 2026-03-11 ### special-ip-ranges-health-checks [IN] OBSERVATION Google health check probe IP ranges include 35.191.0.0/16 and 130.211.0.0/22; IAP uses 35.235.240.0/20; Cloud DNS uses 35.199.192.0/19; Serverless VPC Access uses 35.199.224.0/19. - Source: entries/2026/03/10/vpc-routes.md - Source hash: 5ea29512bcefff8c - Date: 2026-03-11 ### special-routing-paths-non-removable [IN] OBSERVATION Special routing paths (health checks, IAP, DNS, etc.) are non-removable and do not appear in the route table. - Source: entries/2026/03/10/vpc-routes.md - Source hash: 5ea29512bcefff8c - Date: 2026-03-11 ### subnet-four-reserved-ips-primary-range [IN] OBSERVATION Each primary IPv4 subnet range has 4 unusable addresses: network (first), default gateway (second), second-to-last (reserved), and broadcast (last). Secondary ranges have no reserved addresses. - Source: entries/2026/03/10/vpc-subnets.md - Source hash: 0a93f184ecf6ad03 - Date: 2026-03-11 ### subnet-minimum-size-slash-29 [IN] OBSERVATION Minimum VPC subnet size is /29 (8 addresses). Recommended maximum is /8. - Source: entries/2026/03/10/vpc-subnets.md - Source hash: 0a93f184ecf6ad03 - Date: 2026-03-11 ### subnet-primary-range-expand-not-shrink [IN] OBSERVATION Primary IPv4 subnet ranges can be expanded but never shrunk after creation. - Source: entries/2026/03/10/vpc-subnets.md - Source hash: 0a93f184ecf6ad03 - Date: 2026-03-11 ### subnet-routes-always-win-over-custom [IN] OBSERVATION Subnet routes always take precedence over static and dynamic routes for overlapping destinations, unless using hybrid subnets. - Source: entries/2026/03/10/vpc-routes.md - Source hash: 5ea29512bcefff8c - Date: 2026-03-11 ### subnets-are-regional-vpcs-are-global [IN] OBSERVATION VPC subnets are regional resources while VPC networks are global resources. - Source: entries/2026/03/10/vpc-subnets.md - Source hash: 0a93f184ecf6ad03 - Date: 2026-03-11 ### vpc-firewall-asymmetric-stateful-evaluation [IN] OBSERVATION VPC firewalls implement an asymmetric, stateful security posture: default rules deny all ingress but allow all egress (asymmetric baseline), connection tracking expires after 10 minutes of idle (stateful with silent timeout), and source port filtering is unsupported (coarse-grained matching) — the net effect is that outbound-initiated connections are permissive by default but their return path depends on connection tracking state that silently expires. ### vpc-firewall-connection-tracking-10min-idle [IN] OBSERVATION VPC firewall connection tracking expires after 10 minutes of inactivity. - Source: entries/2026/03/10/vpc-firewall-rules.md - Source hash: e3fdb9ffe90c4da8 - Date: 2026-03-11 ### vpc-firewall-default-priority-1000 [IN] OBSERVATION The default priority for VPC firewall rules is 1000; priority range is 0–65535 (lower = higher priority). - Source: entries/2026/03/10/vpc-firewall-rules.md - Source hash: e3fdb9ffe90c4da8 - Date: 2026-03-11 ### vpc-firewall-deny-beats-allow-same-priority [IN] OBSERVATION At equal priority, deny rules override allow rules in VPC firewall evaluation. - Source: entries/2026/03/10/vpc-firewall-rules.md - Source hash: e3fdb9ffe90c4da8 - Date: 2026-03-11 ### vpc-firewall-no-source-port-filtering [IN] OBSERVATION VPC firewall rules support destination port specification only; source port filtering is not supported. - Source: entries/2026/03/10/vpc-firewall-rules.md - Source hash: e3fdb9ffe90c4da8 - Date: 2026-03-11 ### vpc-firewall-per-network-no-sharing [IN] OBSERVATION VPC firewall rules are scoped to a single VPC network and cannot be shared across networks, including peered networks. - Source: entries/2026/03/10/vpc-firewall-rules.md - Source hash: e3fdb9ffe90c4da8 - Date: 2026-03-11 ### vpc-firewall-rules-stateful [IN] OBSERVATION VPC firewall rules are stateful — return traffic for allowed connections is automatically permitted. - Source: entries/2026/03/10/vpc-firewall-rules.md - Source hash: e3fdb9ffe90c4da8 - Date: 2026-03-11 ### vpc-flow-logs-asymmetric-firewall-visibility [IN] OBSERVATION VPC Flow Logs provide asymmetric visibility into firewall-blocked traffic: egress denied packets are captured (sampled before egress firewall evaluation) but ingress denied packets are not captured — creating a systematic blind spot for inbound attack detection that must be supplemented with firewall rule logging or other network security tooling. ### vpc-flow-logs-default-aggregation-5s [IN] OBSERVATION The default VPC Flow Logs aggregation interval is 5 seconds. - Source: entries/2026/03/10/vpc-flow-logs.md - Source hash: 4f05cb7629e65ef1 - Date: 2026-03-11 ### vpc-flow-logs-egress-denied-are-captured [IN] OBSERVATION Egress packets blocked by firewall rules are captured by VPC Flow Logs (sampled before egress firewall evaluation). - Source: entries/2026/03/10/vpc-flow-logs.md - Source hash: 4f05cb7629e65ef1 - Date: 2026-03-11 ### vpc-flow-logs-gke-intranode-visibility-required [IN] OBSERVATION GKE intra-node pod-to-pod traffic requires intranode visibility to be enabled for VPC Flow Logs capture. - Source: entries/2026/03/10/vpc-flow-logs.md - Source hash: 4f05cb7629e65ef1 - Date: 2026-03-11 ### vpc-flow-logs-ingress-denied-not-captured [IN] OBSERVATION Ingress packets blocked by firewall rules are not captured by VPC Flow Logs. - Source: entries/2026/03/10/vpc-flow-logs.md - Source hash: 4f05cb7629e65ef1 - Date: 2026-03-11 ### vpc-flow-logs-no-performance-impact [IN] OBSERVATION Enabling VPC Flow Logs introduces no delay or performance impact. - Source: entries/2026/03/10/vpc-flow-logs.md - Source hash: 4f05cb7629e65ef1 - Date: 2026-03-11 ### vpc-flow-logs-secondary-sampling-defaults-differ [IN] OBSERVATION Default secondary sampling rate for VPC Flow Logs is 50% via Compute Engine API and 100% via Network Management API. - Source: entries/2026/03/10/vpc-flow-logs.md - Source hash: 4f05cb7629e65ef1 - Date: 2026-03-11 ### vpc-flow-logs-shared-vpc-host-project [IN] OBSERVATION VPC Flow Logs for Shared VPC are written to the host project, not service projects. - Source: entries/2026/03/10/vpc-flow-logs.md - Source hash: 4f05cb7629e65ef1 - Date: 2026-03-11 ### vpc-implied-firewall-rules-deny-ingress-allow-egress [IN] OBSERVATION Every VPC has two implied firewall rules: deny all ingress and allow all egress. - Source: entries/2026/03/10/vpc-overview.md - Source hash: 76b51dd2828258b3 - Date: 2026-03-11 ### vpc-metadata-server-always-accessible [IN] OBSERVATION The metadata server at 169.254.169.254 is always accessible regardless of firewall rules and cannot be blocked. - Source: entries/2026/03/10/vpc-firewall-rules.md - Source hash: e3fdb9ffe90c4da8 - Date: 2026-03-11 ### vpc-network-global-subnets-regional [IN] OBSERVATION VPC networks are global resources; subnets are regional. - Source: entries/2026/03/10/vpc-overview.md - Source hash: 76b51dd2828258b3 - Date: 2026-03-11 ### vpc-peering-cloud-router-no-auto-advertise-peered-subnets [IN] OBSERVATION Cloud Router does not auto-advertise received peering subnet routes; custom advertisement mode with explicit ranges is required. - Source: entries/2026/03/10/vpc-peering.md - Source hash: a7bc9e8045f996ba - Date: 2026-03-11 ### vpc-peering-custom-routes-not-exchanged-by-default [IN] OBSERVATION Static and dynamic routes are not exchanged by default in VPC Peering; must enable --export-custom-routes and --import-custom-routes. - Source: entries/2026/03/10/vpc-peering.md - Source hash: a7bc9e8045f996ba - Date: 2026-03-11 ### vpc-peering-dns-does-not-resolve-across-peers [IN] OBSERVATION Internal DNS names do not resolve across peered VPC networks; Cloud DNS peering zones are required. - Source: entries/2026/03/10/vpc-peering.md - Source hash: a7bc9e8045f996ba - Date: 2026-03-11 ### vpc-peering-exporting-network-dynamic-routing-mode-controls [IN] OBSERVATION The dynamic routing mode of the exporting network determines regional vs global availability of peering dynamic routes; the importing network's mode is irrelevant. - Source: entries/2026/03/10/vpc-peering.md - Source hash: a7bc9e8045f996ba - Date: 2026-03-11 ### vpc-peering-firewall-rules-not-exchanged [IN] OBSERVATION Firewall rules are not exchanged via VPC Peering; each VPC must independently create ingress allow rules. - Source: entries/2026/03/10/vpc-peering.md - Source hash: a7bc9e8045f996ba - Date: 2026-03-11 ### vpc-peering-limited-connectivity-model [IN] OBSERVATION VPC peering provides constrained connectivity: it is non-transitive, never exchanges IAM policies, prohibits overlapping subnets, and does not auto-advertise peered routes via Cloud Router. ### vpc-peering-never-exchanges-iam [IN] OBSERVATION VPC Network Peering exchanges subnet routes automatically but never exchanges IAM policies. - Source: entries/2026/03/10/vpc-overview.md - Source hash: 76b51dd2828258b3 - Date: 2026-03-11 ### vpc-peering-no-overlapping-subnets [IN] OBSERVATION Subnet IP ranges cannot overlap across peered VPC networks; peering will fail if they do. - Source: entries/2026/03/10/vpc-peering.md - Source hash: a7bc9e8045f996ba - Date: 2026-03-11 ### vpc-peering-non-transitive [IN] OBSERVATION VPC Peering is non-transitive — if A peers with B and B peers with C, A cannot reach C through B. - Source: entries/2026/03/10/vpc-peering.md - Source hash: a7bc9e8045f996ba - Date: 2026-03-11 ### vpc-peering-two-auto-mode-cannot-peer [IN] OBSERVATION Two auto mode VPC networks cannot be peered because both use ranges within 10.128.0.0/9. - Source: entries/2026/03/10/vpc-peering.md - Source hash: a7bc9e8045f996ba - Date: 2026-03-11 ### vpc-route-evaluation-order [IN] OBSERVATION VPC route evaluation order: Special routing paths → Policy-based routes → Subnet routes → Custom routes (static/dynamic) → System-generated default routes. - Source: entries/2026/03/10/vpc-routes.md - Source hash: 5ea29512bcefff8c - Date: 2026-03-11 ### vpc-security-dual-asymmetry-enforcement-and-visibility [IN] OBSERVATION VPC security has dual asymmetry in enforcement and observability that creates a blind spot at the ingress boundary: firewall rules default to deny-all-ingress/allow-all-egress (asymmetric enforcement), while flow logs capture denied-egress but miss denied-ingress (asymmetric visibility) — the traffic most aggressively blocked by default is precisely the traffic invisible to forensic analysis. ### vpc-shared-requires-same-org [IN] OBSERVATION Shared VPC uses a host project model and requires all projects to be in the same organization. - Source: entries/2026/03/10/vpc-overview.md - Source hash: 76b51dd2828258b3 - Date: 2026-03-11 ### vpc-smtp-port25-egress-blocked-by-default [IN] OBSERVATION Port 25 (SMTP) egress to external IPs is blocked by default by Google Cloud (not via a firewall rule). - Source: entries/2026/03/10/vpc-firewall-rules.md - Source hash: e3fdb9ffe90c4da8 - Date: 2026-03-11 ### vpc-ula-ipv6-slash-48-permanent [IN] OBSERVATION A VPC network's /48 ULA IPv6 range (from fd20::/20) is globally unique within Google Cloud and cannot be removed or changed once assigned. - Source: entries/2026/03/10/vpc-subnets.md - Source hash: 0a93f184ecf6ad03 - Date: 2026-03-11 ### vpc-vms-multiple-nics-different-networks [IN] OBSERVATION VMs can have multiple network interfaces attached to different VPC networks. - Source: entries/2026/03/10/vpc-overview.md - Source hash: 76b51dd2828258b3 - Date: 2026-03-11 ### wif-direct-access-preferred-over-impersonation [IN] OBSERVATION Direct resource access (granting IAM roles directly to federated identities) is preferred over service account impersonation; impersonation requires `roles/iam.workloadIdentityUser`. - Source: entries/2026/03/10/iam-workload-identity.md - Source hash: 382498753f9993ff - Date: 2026-03-11 ### wif-eliminates-service-account-keys [IN] OBSERVATION Workload Identity Federation is the recommended alternative to service account keys for external workloads accessing Google Cloud resources. - Source: entries/2026/03/10/iam-workload-identity.md - Source hash: 382498753f9993ff - Date: 2026-03-11 ### wif-google-subject-required-127-chars [IN] OBSERVATION The `google.subject` attribute mapping is required for all workload identity pool providers and has a maximum length of 127 characters. - Source: entries/2026/03/10/iam-workload-identity.md - Source hash: 382498753f9993ff - Date: 2026-03-11 ### wif-one-pool-per-environment [IN] OBSERVATION Best practice is one workload identity pool per non-Google Cloud environment (dev, staging, prod). - Source: entries/2026/03/10/iam-workload-identity.md - Source hash: 382498753f9993ff - Date: 2026-03-11 ### wif-principal-uses-project-number [IN] OBSERVATION Workload Identity Federation principal identifiers use project number (not project ID) in fully qualified resource names. - Source: entries/2026/03/10/iam-workload-identity.md - Source hash: 382498753f9993ff - Date: 2026-03-11 ### wif-supported-idp-protocols [IN] OBSERVATION Workload Identity Federation supports identity providers using OIDC, SAML V2.0, X.509 certificates, AWS, Azure, Active Directory, GitHub, and GitLab. - Source: entries/2026/03/10/iam-workload-identity.md - Source hash: 382498753f9993ff - Date: 2026-03-11 ### wif-token-exchange-rfc8693 [IN] OBSERVATION Workload Identity Federation token exchange follows the OAuth 2.0 token exchange spec (RFC 8693) via the Security Token Service (STS). - Source: entries/2026/03/10/iam-workload-identity.md - Source hash: 382498753f9993ff - Date: 2026-03-11 ### wif-unified-keyless-auth-across-workload-types [IN] OBSERVATION Workload Identity Federation provides keyless authentication for GKE workloads and external identities, serving as the recommended alternative to service account keys and reducing credential management overhead. ### wif-up-to-50-custom-attributes [IN] OBSERVATION Workload identity pool providers support up to 50 custom attributes for `principalSet://` bindings. - Source: entries/2026/03/10/iam-workload-identity.md - Source hash: 382498753f9993ff - Date: 2026-03-11 ### binary-authorization-build-to-runtime-security-chain [OUT] OBSERVATION Binary Authorization forms a continuous supply chain security chain: Cloud Build creates attestations at build time and can block unauthorized deployments, while GKE continuous validation (CV) monitors running containers against policies — covering both deployment-time gating and runtime drift detection. ### cloud-armor-compensates-vpc-ingress-visibility-gap [OUT] OBSERVATION Cloud Armor's edge-first defense compensates for VPC-level ingress visibility gaps by filtering and logging malicious traffic at the Google Cloud edge before it reaches the VPC boundary where flow logs have systematic blind spots for denied ingress packets. ### cloudrun-autoscaling-handles-all-traffic-patterns [OUT] OBSERVATION Cloud Run autoscaling reliably handles all traffic patterns including sudden spikes via the 60% utilization/concurrency target. ### cloudrun-billing-fully-optimizable [OUT] OBSERVATION Cloud Run billing is fully optimizable through request-based pay-per-use default, CUD discounts shared across Cloud Run, GKE, and Compute Engine, and zero-cost for IAM-denied requests. ### cloudrun-concurrency-scales-with-resources [OUT] OBSERVATION Cloud Run concurrency scales naturally with vCPU allocation (default 80x vCPUs, max 1000 per instance), providing predictable request distribution across instances. ### cloudrun-resource-types-divergent-operational-models [OUT] OBSERVATION Cloud Run's three resource types (services, jobs, worker pools) have fundamentally divergent operational characteristics rather than being variations of a single model: services get authentication and autoscaling, jobs always use the second-generation execution environment, and worker pools have neither autoscaling nor public URLs — requiring type-specific operational expertise rather than a single Cloud Run mental model. ### cloudrun-zero-ops-for-simple-stateless-workloads [OUT] OBSERVATION Cloud Run achieves zero-ops deployment for simple stateless workloads with deterministic container execution (tag-to-digest resolution, image caching at deploy) and managed HTTPS endpoints with TLS, WebSockets, and gRPC support. ### cloudsql-backup-restore-operationally-seamless [OUT] OBSERVATION Cloud SQL backups provide seamless disaster recovery with indefinite retention for on-demand backups and consistent connection strings after failover. ### cloudsql-disaster-recovery-complete [OUT] OBSERVATION Cloud SQL provides complete disaster recovery coverage with incremental backups, indefinite on-demand backup retention, 4-day deleted instance recovery by Customer Care, and same-IP failover for HA instances. ### cloudsql-private-access-simple-for-serverless [OUT] OBSERVATION Cloud SQL private IP access is operationally simple for serverless workloads: stable connection strings survive failover, and private networking avoids public internet exposure. ### cmek-governance-sufficient-for-data-lifecycle-control [OUT] OBSERVATION CMEK governance provides sufficient control over data lifecycle across GCP services through duty-separated KMS administration, non-disruptive rotation, and unified key lifecycle management. ### cmek-key-lifecycle-controls-data-lifecycle [OUT] OBSERVATION CMEK key availability directly controls data lifecycle across GCP services: revoking access, disabling, or destroying a key makes all encrypted data permanently inaccessible, enabling crypto-shredding as a data governance tool. ### cmek-lifecycle-rotation-safe-destruction-catastrophic [OUT] OBSERVATION CMEK key lifecycle has asymmetric risk: rotation is non-disruptive (creates new version without re-encrypting, ciphertext self-identifies its key version), but key destruction or access revocation permanently destroys all encrypted data across 40+ services — making rotation a safe operational practice but destruction an irreversible data lifecycle event. ### cmek-single-control-plane-for-data-governance [OUT] OBSERVATION CMEK key lifecycle serves as the single control plane for data governance across GCP: rotation is operationally safe (ciphertext self-identifies its key version), but destruction permanently shreds all encrypted data across every service — and GCS's tiered encryption model means choosing CMEK explicitly opts into this asymmetric risk, trading storage durability for cryptographic access control at the KMS layer. ### container-security-lifecycle-build-to-runtime-identity [OUT] OBSERVATION Container security in GCP spans the full lifecycle from build provenance to runtime identity: Cloud Build attestations with Binary Authorization enforce supply chain integrity through deployment, while Workload Identity Federation provides keyless runtime credentials — but the end-to-end chain depends on Kubernetes namespace naming conventions for identity isolation, making organizational discipline the binding constraint on what is otherwise a technical guarantee. ### dedicated-interconnect-sla-proportional-to-geographic-redundancy [OUT] OBSERVATION Dedicated Interconnect SLA tiers are strictly proportional to geographic redundancy: no SLA for single connections, 99.9% requires 2 connections in the same metro (different edge domains), 99.99% requires 4 connections across 2 metros — each tier doubles the connection count and expands geographic distribution. ### event-driven-secret-rotation-fragile-chain [OUT] OBSERVATION Secret Manager's Pub/Sub-based rotation notification creates a fragile end-to-end chain: rotation triggers are notification-only (no actual value change), delivery to Cloud Run depends on push subscriptions (one message per request, SSL required), and Pub/Sub's exactly-once guarantee is pull-only — meaning rotation events to serverless consumers may duplicate or be lost, undermining the rotation lifecycle that Secret Manager delegates entirely to application code. ### gce-mig-complete-fleet-management [OUT] OBSERVATION Managed Instance Groups provide complete VM fleet management with autoscaling, autohealing (using conservative health checks separate from load balancing), and regional distribution protecting against zonal failure. ### gce-preemptible-cost-savings-fully-realized [OUT] OBSERVATION Preemptible VMs deliver full cost savings compared to on-demand instances across all billing dimensions. ### gcp-abstraction-inversion-drives-multiplicative-expertise-cost [OUT] OBSERVATION GCP's abstraction inversion drives multiplicative expertise cost: managed services that appear operationally simple demand deeper technical expertise than self-managed alternatives (application-level semantics for Pub/Sub delivery guarantees, Secret Manager rotation, plus comprehensive immutability requiring upfront design), while production costs compound multiplicatively across per-service dimensions — requiring teams to maintain simultaneous deep expertise across every service rather than broad shallow knowledge of any single layer. ### gcp-abstraction-inversion-simplicity-demands-deeper-expertise [OUT] OBSERVATION GCP managed services create an abstraction inversion where operational simplicity demands deeper technical expertise than self-managed alternatives: services require application-level awareness of delivery semantics, rotation patterns, and IAM granularity, AND infrastructure decisions are comprehensively immutable across networking and service configuration — so mistakes require both deep domain knowledge to avoid and full resource recreation to correct. ### gcp-data-access-cost-matrix-connectivity-plus-protection [OUT] OBSERVATION Production-grade private data access in GCP requires navigating a cost matrix across two independent dimensions: a universal connectivity tax from VPC peering constraints (non-transitivity, overlapping IP prohibition, DNS non-resolution) affects every data service identically, while production protection investment (HA, replicas, backups, encryption) compounds independently within each service — making total data infrastructure cost the product of service count times the sum of connectivity overhead and per-service protection engineering. ### gcp-data-domain-deepest-expertise-behind-simplest-interface [OUT] OBSERVATION GCP data services demand the deepest expertise behind the simplest interfaces: data management is the highest-complexity operational domain (four-dimensional GCS engineering, per-service protection investment, CMEK cross-service blast radius) while the abstraction inversion ensures this complexity is hidden behind managed interfaces that make cost and risk appear simpler than they are. ### gcp-data-durability-requires-dual-scale-governance [OUT] OBSERVATION GCP data durability requires governance at two independent scales: per-service protection engineering (Cloud SQL triple investment in HA/replicas/private networking, GCS defense-in-depth across immutability/namespace/encryption tiers) AND cross-service CMEK blast radius management (a single key destruction cascades data loss across every service using that key, voiding per-service durability guarantees regardless of investment). ### gcp-data-governance-requires-upfront-commitment-and-ongoing-engineering [OUT] OBSERVATION GCP data governance demands simultaneous mastery of two orthogonal time horizons: upfront architectural commitment (immutable infrastructure decisions, dual IAM/CMEK control planes compounding with cross-layer irrecoverability) AND ongoing per-service protection engineering (Cloud SQL triple investment, GCS defense-in-depth, CMEK blast radius management) — neither dimension compensates for deficiency in the other. ### gcp-data-management-highest-complexity-domain [OUT] OBSERVATION GCP data management is the highest-complexity operational domain: GCS alone requires four-dimensional engineering (storage class economics, defense-in-depth protection, namespace security, CMEK governance with cross-service blast radius), and this per-service engineering pattern repeats independently across Cloud SQL (triple investment: HA + replicas + private networking), Memorystore (constrained operational model), and Secret Manager (application-level awareness) — with no shared platform abstraction to amortize the complexity. ### gcp-dual-governance-effective-defense-in-depth [OUT] OBSERVATION GCP's dual security governance (IAM access control + CMEK data control) combined with KMS operational safety (duty-separated, non-disruptive rotation) achieves effective layered defense where compromise of one governance surface does not compromise the other and routine operations cannot accidentally breach either. ### gcp-expertise-paradox-managed-demands-more-than-self-managed [OUT] OBSERVATION GCP creates an expertise paradox: managed service adoption intended to reduce operational burden demands deeper expertise than self-managed alternatives across networking, identity, and data governance — while costs compound multiplicatively, meaning organizations pay more for services that require more skill to operate correctly than the infrastructure they replaced. ### gcp-failure-cost-peaks-at-invisible-irrecoverable-boundaries [OUT] OBSERVATION GCP failure cost peaks at invisible irrecoverable boundaries: multiplicative cost compounding across infrastructure dimensions (HA, networking, identity) intersects governance detection gaps at security boundaries (missing ingress flow logs, temporal logging gaps), meaning the most expensive operational failures occur precisely where observability is weakest and mistakes cannot be reversed. ### gcp-governance-detection-gap-at-irrecoverable-boundaries [OUT] OBSERVATION GCP governance has a fundamental detection gap at irrecoverable boundaries: the most dangerous failure mode is irrecoverable mistakes where observability is weakest (immutability at security boundaries with blind flow logs and temporal logging gaps), while the governance model demands simultaneous mastery of upfront architectural commitment and ongoing operational engineering — creating a window where irrecoverable decisions are made with the least available information and detected only after correction is impossible. ### gcp-immutability-prevents-configuration-drift [OUT] OBSERVATION GCP's comprehensive infrastructure immutability combined with managed services' requirement for deep application-level understanding prevents configuration drift in production: resources remain as designed throughout their lifecycle and operators who understand delivery semantics, rotation patterns, and IAM granularity configure them correctly from the start. ### gcp-irrecoverability-invisible-at-security-boundaries [OUT] OBSERVATION GCP's most dangerous operational failure mode is irrecoverable mistakes at boundaries where observability is weakest: infrastructure immutability permanently locks configuration errors (KMS key rings, AR repo format, VPC stack type), while VPC Flow Logs miss ingress-denied traffic and log export has temporal gaps — creating a systematic pattern where the hardest-to-detect errors are also the hardest to fix. ### gcp-managed-service-risk-concentrates-in-naming-and-identity [OUT] OBSERVATION GCP managed service risk concentrates in naming and identity dimensions: GKE naming collisions cascade through the managed service chain granting unintended IAM identity across Cloud Run, Pub/Sub, and Secret Manager integrations, while every managed service independently demands mastery of both application semantics and identity lifecycle — making naming conventions the single highest-leverage security control across the platform. ### gcp-managed-services-demand-application-level-awareness [OUT] OBSERVATION GCP managed services (Pub/Sub, Secret Manager) require application-level production awareness that cannot be abstracted away by platform configuration: Pub/Sub demands explicit throughput-correctness decisions (ordering caps at 1 MBps/key, exactly-once is pull-only and regional, dead-letter counting approximate) while Secret Manager demands version pinning, API-direct access patterns, and rotation event handling — contradicting the "fully managed = no application changes" assumption. ### gcp-managed-services-require-dual-mastery-application-and-identity [OUT] OBSERVATION GCP managed services require dual mastery spanning application semantics and identity lifecycle: Pub/Sub and Secret Manager demand application-level awareness of delivery guarantees, rotation semantics, and IAM granularity mismatches, while the container security chain from build provenance through runtime identity adds a parallel lifecycle requiring coordinated namespace/SA naming discipline — application-level and identity-level expertise cannot substitute for each other. ### gcp-managed-services-shift-complexity-not-eliminate [OUT] OBSERVATION GCP managed services (Cloud Run, GKE Autopilot) shift operational complexity rather than eliminating it: serverless networking requires VPC bridging, NAT chains, and peering navigation, while container security demands build attestation, binary authorization, and namespace-disciplined identity — both require the infrastructure expertise the managed abstractions were designed to replace. ### gcp-multi-tenant-serverless-worst-case-across-all-dimensions [OUT] OBSERVATION Multi-tenant serverless on GCP represents worst-case platform risk across all dimensions simultaneously: the serverless value proposition is negated by networking and identity engineering investment while managed service risk concentrates in naming conventions — the least formalized, least tested, and least visible part of the development lifecycle. ### gcp-observability-sufficient-for-security-forensics [OUT] OBSERVATION GCP default observability infrastructure (auto-collected metrics, per-resource log routing, zero-impact flow logs) provides sufficient data for comprehensive security incident forensics across all traffic patterns. ### gcp-platform-adoption-requires-shifted-not-reduced-investment [OUT] OBSERVATION GCP platform adoption demands engineering investment that is shifted rather than reduced: managed services redirect operational complexity to networking and identity design while security governance requires upfront immutable architectural commitments across IAM, CMEK, and infrastructure layers — the total engineering surface area is comparable to self-managed infrastructure, just differently distributed. ### gcp-private-connectivity-amplifies-highest-complexity-domain [OUT] OBSERVATION The universal VPC peering connectivity tax amplifies GCP's highest-complexity operational domain: data management already requires four-dimensional engineering (storage class economics, defense-in-depth protection, lifecycle automation, key governance), and every private data service adds a fifth dimension of peering non-transitivity, IP range exhaustion, and serverless bridging requirements. ### gcp-production-complexity-multiplicative-and-redirected [OUT] OBSERVATION GCP production engineering complexity exceeds naive estimates through two independent mechanisms: costs compound multiplicatively across infrastructure dimensions (HA, replicas, private networking, geographic redundancy) AND the investment target shifts from traditional operations to networking/identity/governance domains — teams that budget for only one mechanism systematically underestimate total effort. ### gcp-production-cost-multiplicative-across-dimensions [OUT] OBSERVATION GCP production costs are multiplicative rather than additive across two dimensions: infrastructure investment compounds within each service (Cloud SQL 2x for HA plus read replicas plus private networking; Interconnect 2x bandwidth plus encryption overlay plus geographic redundancy) AND each service requires independent protection engineering with no shared abstractions, so total cost = Σ(per-service compounding cost) with no economies of scale. ### gcp-production-guarantees-require-compounding-investment [OUT] OBSERVATION Production-grade GCP services require infrastructure investment that compounds multiplicatively: Cloud SQL demands concurrent investment in HA (2x cost for idle standby), read replicas (capped at 10, no independent backups), and private networking (peering-constrained), while Cloud Interconnect requires geometric scaling (2x bandwidth + 2x metros for 99.99% SLA) — each service's production readiness is independently expensive with no cross-service economy of scale. ### gcp-production-irrecoverability-compounds-across-layers [OUT] OBSERVATION GCP production irrecoverability compounds across layers: infrastructure-level immutability locks resource configuration at creation (AR format, KMS key rings, WIF pools, Cloud SQL private IP), while CMEK key destruction permanently eliminates all encrypted data — mistakes at either layer are unrecoverable, and the layers are independent (a correctly configured key ring can still encrypt data you can never access, and a perfectly mutable resource can have its data crypto-shredded). ### gcp-secret-and-key-dual-rotation-challenge [OUT] OBSERVATION GCP has two independent key/secret rotation challenges with complementary risk profiles: KMS rotation is operationally safe (duty-separated, non-disruptive) but destruction is catastrophic, while Secret Manager rotation is notification-only (Pub/Sub message, no actual value change) creating startup/rotation tension in Cloud Run — both channels must be mastered independently and both surface as availability events in production. ### gcp-secret-rotation-end-to-end-fragility [OUT] OBSERVATION GCP secret and key rotation is end-to-end fragile across two independent mechanisms: the event-driven Secret Manager rotation chain depends on Pub/Sub notifications that are subject to delivery guarantee trade-offs (approximate dead-letter counting, ordering throughput limits), while the dual rotation challenge compounds KMS rotation safety (non-disruptive but requires manual re-encryption) with Cloud Run startup tension (fail-fast semantics on secret version changes) — creating a system where no single rotation event can be assumed to propagate reliably to all consumers. ### gcp-security-dual-control-plane-access-and-data [OUT] OBSERVATION GCP security governance operates through two independent, non-overlapping control planes: IAM controls who can access resources via layered deny-first evaluation with service account hardening, while CMEK controls whether data remains readable at all via key lifecycle — compromising one plane does not compromise the other, but production security requires operating both simultaneously. ### gcp-security-requires-upfront-architectural-commitment [OUT] OBSERVATION GCP's dual security governance (IAM access control + CMEK data control) compounds with cross-layer infrastructure immutability: access policies are mutable post-deployment but encryption keys, repository formats, VPN configurations, and network identity pools are locked at creation, making security architecture an upfront design constraint that cannot be iteratively evolved. ### gcp-security-three-failure-domains-access-data-rotation [OUT] OBSERVATION GCP security governance spans three independent failure domains requiring simultaneous mastery: access control (IAM deny-first evaluation with upfront architectural commitment), data control (CMEK lifecycle where key destruction causes irrecoverable data loss), and credential rotation (fragile Pub/Sub notification chains for Secret Manager, KMS version management) — failure in any one domain compromises the security posture that depends on all three. ### gcs-customer-encryption-trades-durability-for-control [OUT] OBSERVATION GCS customer-managed encryption (CMEK/CSEK tiers in the four-tier model) trades data durability for access control: CMEK key destruction permanently shreds encrypted data across services, and CSEK key loss causes unrecoverable data loss — the stronger the customer control over encryption, the higher the operational risk to data availability. ### gcs-data-durability-conditional-on-key-governance [OUT] OBSERVATION GCS's eleven-nines durability guarantee is conditional on encryption key availability: with default Google-managed encryption, durability is unconditional; with CMEK, key destruction permanently renders data inaccessible (crypto-shredding); with CSEK, key loss means permanent data loss — higher customer encryption control inversely correlates with unconditional durability. ### gcs-durability-contingent-on-cmek-cross-service-blast-radius [OUT] OBSERVATION CMEK key lifecycle is the single governance surface for data persistence across GCP: a key that protects GCS objects (conditionally voiding eleven-nines durability on destruction), Spanner databases (auto-deleted after 30 days of key unavailability), and other CMEK-integrated services creates cross-service blast radius from a single key management decision — rotation is safe but destruction or revocation cascades across all dependent services simultaneously. ### gcs-four-dimensional-management-surface [OUT] OBSERVATION GCS operational management spans four largely independent dimensions: storage class economics with lifecycle automation, data protection via defense-in-depth across object/namespace/encryption layers, namespace security requiring organizational controls, and cross-service CMEK key governance where a single key destruction voids eleven-nines durability across GCS and every other CMEK-protected service — the fourth dimension is invisible in GCS-specific tooling but dominates the durability guarantee. ### gcs-versioning-complete-data-protection [OUT] OBSERVATION GCS versioning with soft delete provides complete data protection: immutable objects with atomic replacement, recoverable noncurrent versions, and default 7-day soft delete retention cover all accidental modification and deletion scenarios. ### gke-autopilot-complete-managed-kubernetes [OUT] OBSERVATION GKE Autopilot provides a complete managed Kubernetes experience — always regional, pod-level billing, zero-node scaling, Google-managed nodes — suitable for all production workload types. ### gke-autopilot-concentrates-risk-in-naming-conventions [OUT] OBSERVATION GKE Autopilot eliminates all infrastructure operations (always regional, Google-managed nodes, pod-level billing) but the identity design it shifts to is itself fragile: Workload Identity isolation depends on namespace + service account naming conventions across clusters (same name = same IAM identity), and service accounts require active hardening against dual-nature privilege escalation — concentrating all Autopilot operational risk into Kubernetes naming discipline and IAM policy hygiene. ### gke-autopilot-shifts-operational-burden-to-identity-design [OUT] OBSERVATION GKE Autopilot eliminates infrastructure operations (always regional, Google-managed nodes, pod-level billing) but shifts the operational burden to identity design: Workload Identity Federation demands namespace and service account naming discipline where same-namespace same-name collisions create identity aliasing, and mistakes in identity configuration are harder to detect than infrastructure misconfiguration because they fail silently at authorization time rather than visibly at provisioning time. ### gke-identity-isolation-shifts-risk-to-namespace-discipline [OUT] OBSERVATION GKE Workload Identity addresses service account key risks (dual nature, default editor role, impersonation surface) but shifts security requirements to namespace and naming discipline — same namespace + same KSA name = same GCP identity regardless of intent, requiring organizational practices rather than just enabling the feature. ### gke-keyless-identity-naming-dependent [OUT] OBSERVATION GKE Workload Identity eliminates service account keys via WIF's unified keyless pattern but makes identity isolation depend on naming conventions: same namespace + service account name across clusters in the same project maps to the same IAM identity, shifting the security boundary from cryptographic keys to organizational naming discipline. ### gke-naming-risk-cascades-through-managed-service-chain [OUT] OBSERVATION GKE naming-dependent identity risk cascades through the managed service chain: a namespace/service-account naming collision grants unintended IAM identity, which inherits access to Secret Manager secrets, Pub/Sub topics, and Cloud SQL instances — each of which shifts its own complexity to application-level awareness, amplifying the blast radius of a single naming error across the entire service mesh. ### gke-security-requires-naming-discipline-and-dual-governance [OUT] OBSERVATION GKE workload security requires mastery of two orthogonal dimensions: naming-dependent identity isolation where namespace/service-account conventions determine IAM identity across clusters (creating cross-cluster identity collisions from naming mistakes), AND the platform's dual IAM/CMEK control planes where access governance and data governance operate independently — making GKE security simultaneously a function of team naming discipline and architectural control-plane design. ### gke-workload-identity-complete-pod-isolation [OUT] OBSERVATION GKE Workload Identity Federation provides complete per-pod identity isolation for Google Cloud API access. ### interconnect-fully-production-ready-connectivity [OUT] OBSERVATION Cloud Interconnect achieves fully production-ready connectivity with redundancy overprovisioning, dynamic BGP routing, and active-active VLAN configuration across edge availability domains. ### interconnect-production-sla-proportional-to-investment [OUT] OBSERVATION Production Cloud Interconnect demands compounding infrastructure investment: the 99.99% SLA tier requires 4 connections across 2 metros (geographic redundancy with 2x bandwidth overprovisioning), and achieving confidentiality requires independently layering HA VPN or MACsec encryption on top — meaning the highest availability and security posture requires both geographic and protocol-level engineering that scales cost super-linearly. ### kms-governance-asymmetric-rotation-safe-destruction-catastrophic [OUT] OBSERVATION KMS governance provides complementary safety for routine operations (duty separation prevents admin crypto access, rotation creates new versions without re-encrypting) but cannot mitigate the catastrophic risk of key destruction — the 30-day scheduled destruction window is the sole safeguard, and once expired, data loss is permanent and cross-service, regardless of governance quality. ### memorystore-redis-zero-data-loss-failover [OUT] OBSERVATION Memorystore for Redis provides failover with preserved connection strings and no data loss. ### production-serverless-investment-comparable-to-traditional-infrastructure [OUT] OBSERVATION Production serverless on GCP requires engineering investment comparable to traditional infrastructure: the five-layer networking stack (VPC bridging, peering, private services access, NAT, secret rotation) plus build-to-runtime identity chain demands the same depth of infrastructure and security mastery that serverless was designed to eliminate, compounded by immutable dual control planes (IAM + CMEK) that cannot be retrofitted. ### production-serverless-requires-full-stack-engineering [OUT] OBSERVATION Production serverless on GCP requires parallel engineering investment across networking (five-layer private data stack: VPC bridging, peering non-transitivity, NAT chaining, private services access, Cloud DNS), identity (build provenance via SLSA attestation, Binary Authorization gate, Workload Identity naming discipline), and secrets (startup fail-fast vs rotation notification-only tension) — each dimension independently mandatory, collectively contradicting the managed-simplicity premise. ### pubsub-dead-letter-reliable-failure-handling [OUT] OBSERVATION Pub/Sub dead-letter topics provide reliable failure handling with configurable retry thresholds, proper IAM-gated routing, and cross-project dead-letter topic support. ### pubsub-delivery-guarantees-trade-throughput-for-correctness [OUT] OBSERVATION Pub/Sub delivery guarantees form a throughput-correctness trade-off spectrum: default at-least-once delivery is throughput-unconstrained but allows duplicates, adding ordering caps throughput at 1 MBps per key with cascading redelivery risk, and exactly-once narrows further to pull-only subscriptions — each stronger guarantee progressively shrinks the operational envelope, and composing ordering with exactly-once produces the most constrained mode (sequential in-order acks, thousands-per-second throughput). ### pubsub-exactly-once-end-to-end [OUT] OBSERVATION Pub/Sub provides exactly-once delivery guarantees from publisher to subscriber. ### pubsub-exactly-once-with-ordering-production-ready [OUT] OBSERVATION Pub/Sub combining exactly-once delivery with ordering keys achieves sequential exactly-once processing — the gold standard for message processing guarantees. ### secretmanager-replication-residency-accessibility-tradeoff [OUT] OBSERVATION Secret Manager replication creates a residency-accessibility trade-off: automatic replication provides global access with Google-chosen regions, while user-managed regional replication ensures data residency at rest, in use, and in transit but restricts access to applications in the same region — requiring upfront architectural alignment between compliance requirements and application deployment topology. ### secretmanager-requires-dual-level-architectural-decisions [OUT] OBSERVATION Secret Manager requires irreconcilable architectural decisions at two independent levels: infrastructure topology (replication trades data residency for global accessibility, regional secrets require regional service endpoints) and application integration (API-direct access with version pinning, Pub/Sub-based rotation notifications, IAM granularity mismatch at secret level) — neither level can be deferred or changed cheaply after deployment. ### serverless-multi-tenant-negates-serverless-value-proposition [OUT] OBSERVATION Serverless in multi-tenant GCP production environments negates the serverless value proposition: engineering investment matches traditional infrastructure (five-layer networking, identity lifecycle, security commitment) while the multi-tenant networking stack and per-message delivery semantics add complexity layers that traditional infrastructure does not impose — the abstraction saves nothing and costs more to reason about. ### serverless-multi-tenant-worst-case-total-cost [OUT] OBSERVATION Serverless workloads in multi-tenant GCP environments represent worst-case total cost of ownership: the five-layer networking stack compounds with per-service protection engineering costs, and each additional private data service (Cloud SQL, Memorystore, Secret Manager) multiplies both the networking and security governance dimensions independently — total cost grows superlinearly with service count. ### supply-chain-integrity-build-through-deploy [OUT] OBSERVATION Container supply chain integrity spans the full build-to-deploy lifecycle: Cloud Build creates attestations, Binary Authorization blocks unauthorized images and continuously validates running containers, while Cloud Run resolves tags to digests and caches images at deploy time — ensuring revisions always serve the exact verified artifact. ### vpc-flow-logs-complete-network-forensics [OUT] OBSERVATION VPC Flow Logs provide complete network forensics for all firewall-related security investigations, with no performance impact and standard aggregation.