{"results":[{"id":"ar-cmek-encryption-supported","text":"Artifact Registry supports CMEK encryption via Cloud KMS (Google-managed encryption by default), and organization policy can enforce CMEK.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"cloud-hsm-uses-kms-frontend","text":"Cloud HSM uses Cloud KMS as its frontend — all HSM operations go through the KMS API, not a separate API.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"cmek-autokey-creates-hsm-keys-by-default","text":"Cloud KMS Autokey automatically creates Cloud HSM keys by default; Autokey keys are functionally identical to manually created Cloud HSM keys.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"cmek-customer-owns-keys-envelope-encryption","text":"CMEK uses server-side, symmetric, envelope encryption with customer-controlled 256-bit AES-GCM keys; key material never leaves the Cloud KMS system boundary.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"cmek-governance-sufficient-for-data-lifecycle-control","text":"CMEK governance provides sufficient control over data lifecycle across GCP services through duty-separated KMS administration, non-disruptive rotation, and unified key lifecycle management.","truth_value":"OUT","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"cmek-single-control-plane-for-data-governance","text":"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.","truth_value":"OUT","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ekm-coordinated-keys-require-vpc-connection","text":"Coordinated (Cloud KMS-managed) EKM keys require a VPC connection; manual mode is required for internet connections.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ekm-double-encryption-symmetric-keys","text":"Cloud EKM symmetric encryption uses both internal key material (Cloud KMS) and external key material (EKM) — losing either makes data permanently unrecoverable.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gcp-dual-governance-effective-defense-in-depth","text":"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.","truth_value":"OUT","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gcp-immutability-comprehensive-networking-and-services","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gcp-immutable-infrastructure-decisions-require-upfront-design","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gcp-irrecoverability-invisible-at-security-boundaries","text":"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.","truth_value":"OUT","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gcp-production-irrecoverability-compounds-across-layers","text":"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).","truth_value":"OUT","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gcp-secret-and-key-dual-rotation-challenge","text":"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.","truth_value":"OUT","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gcp-secret-rotation-achieves-zero-downtime","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gcp-secret-rotation-end-to-end-fragility","text":"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.","truth_value":"OUT","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gcp-security-three-failure-domains-access-data-rotation","text":"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.","truth_value":"OUT","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gcs-cmek-vs-csek-storage","text":"CMEK keys are stored in Cloud KMS (Google stores them, customer manages them); CSEK keys are provided per-request and never stored by Google.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"kms-admin-role-no-encrypt-decrypt","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"kms-all-states-except-destroyed-incur-costs","text":"All Cloud KMS key version states except Destroyed incur costs, including Disabled and Scheduled for destruction.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null}],"count":51,"limit":20,"offset":0}