{"results":[{"id":"alb-regional-for-data-residency","text":"Regional external ALB is the appropriate choice for compliance/data residency requirements (single geolocation).","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"ar-cleanup-dry-run-requires-data-access-logs","text":"Artifact Registry cleanup dry run results appear in Data Access audit logs, which must be explicitly enabled with \"data write\" type to see results.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"cloud-dns-service-directory-zones-no-direct-records","text":"Service Directory zones cannot have records added directly — data comes from the Service Directory namespace.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"cloudsql-private-networking-doubly-constrained-by-peering","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"cloudsql-production-architecture-requires-triple-investment","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"cloudsql-restore-requires-same-db-version","text":"Cloud SQL restores can only target instances with the same database version as when the backup was taken.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"cloudsql-supports-three-engines","text":"Cloud SQL supports exactly three database engines: MySQL, PostgreSQL, and SQL Server.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"cmek-crypto-shredding-destroys-data","text":"Destroying a CMEK makes all data encrypted by it permanently inaccessible, enabling crypto-shredding for off-boarding or security remediation.","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-key-lifecycle-controls-data-lifecycle","text":"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.","truth_value":"OUT","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"cmek-lifecycle-rotation-safe-destruction-catastrophic","text":"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.","truth_value":"OUT","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"cmek-revoking-access-or-disabling-key-makes-data-inaccessible","text":"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.","truth_value":"IN","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-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":"gce-durable-disks-network-attached","text":"Durable block storage (Hyperdisk and Persistent Disk) are network-attached devices transmitting data over Google's networks, not physically attached like Local SSD.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gce-ephemeral-compute-storage-workload-tier","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gce-local-ssd-data-lost-on-stop","text":"Local SSD data is lost on VM stop, suspend, restart, crash, or host failure — it is ephemeral storage.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gce-local-ssd-ephemeral-high-performance-tier","text":"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.","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gce-metadata-client-cert-valid-7-days","text":"The HTTPS MDS client identity certificate is valid for 7 days and must be refreshed","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null},{"id":"gce-metadata-custom-keys-case-sensitive","text":"GCE custom metadata keys are case-sensitive","truth_value":"IN","justification_count":0,"dependent_count":0,"challenges":[],"last_reviewed":null,"review_result":null}],"count":103,"limit":20,"offset":0}