content(what-is): expand the Google Cloud Secret Manager explainer

[alexleventer]

Summary

Rewrites content/what-is/what-is-google-cloud-secret-manager.md from a CLI-walkthrough-heavy page into a structured SEO and AEO reference. Includes the versioning model, the automatic vs user-managed replication choice, IAM scopes and predefined roles, Workload Identity Federation, and cross-links to the other vault explainers and Pulumi ESC.

What changed

• Opening definition — quotable one-paragraph definition that names IAM, Cloud Audit Logs, and CMEK, plus a clear statement that there's no built-in rotation engine.
• Why teams use Secret Manager — IAM and audit-log integration, version immutability, CMEK with Cloud HSM (FIPS 140-2 Level 3).
• Core features table — encryption at rest/in transit, IAM, versioning, replication, audit, CMEK, VPC Service Controls, rotation hooks.
• Versioning section — explains immutable integer-ID versions, latest alias, enable/disable/destroy lifecycle.
• Replication policy table — automatic vs user-managed; notes that the policy is permanent.
• Vault comparison table — Secret Manager vs AWS Secrets Manager vs Azure Key Vault vs HashiCorp Vault (rotation, certificates, HSM options).
• IAM and access control — project / secret / version scopes, the five predefined roles, Workload Identity Federation.
• Google Cloud integrations — Cloud Run / Functions, GKE via CSI driver, Cloud Build availableSecrets, Compute Engine, external CI via WIF, Cloud KMS / Cloud HSM.
• Pricing section — per-version-per-Region-per-month + per-10K-access-ops model, CMEK billed separately.
• Pulumi ESC integration — GCP Secrets provider, gcp-login OIDC provider, cross-vault composition, audit unification.
• FAQ — ten doubt-removers: no built-in rotation, HIPAA, quotas, KMS vs Secret Manager, GitHub Actions via WIF, migration, destroy semantics, GKE Workload Identity, replication policy choice, data-access logs not on by default.
• Cross-links — secrets management pillar, the three other vault pages, cloud security, SOC 2.

Test plan

• make serve; visit /what-is/what-is-google-cloud-secret-manager/ and confirm tables and headings render correctly
• Spot-check cross-links: /what-is/what-is-secrets-management/, /what-is/what-is-hashicorp-vault/, /what-is/what-is-aws-secrets-manager/, /what-is/what-is-azure-key-vault/, /docs/pulumi-cloud/esc/providers/gcp-secrets/, /registry/packages/gcp/api-docs/secretmanager/secret/
• CI lint + pinned review

🤖 Generated with Claude Code

[github-actions]

Pre-merge Review — Last updated 2026-05-20T16:58:06Z

Tip

Summary: This PR rewrites the /what-is/what-is-google-cloud-secret-manager/ explainer for SEO/AEO, mirroring the question-style H2 + FAQ structure of sibling pages like what-is-aws-secrets-manager and what-is-azure-key-vault. The wrongness that would block a reader's success: a compliance-certifications enumeration that doesn't match Google's official Secret Manager compliance page (L153), and a parenthetical claim that Cloud KMS is used "under the hood" by default (L161) when by Secret Manager's own feature table Cloud KMS is only involved for CMEK. Passes run: claim extraction + 4-specialist verification (50 claims), Vale prose lint, frontmatter sweep, temporal-trigger sweep; no cross-sibling fan-out (single-file PR), no code-examples checks (no fenced code in content), no editorial-balance (not under content/blog/).

Review confidence:

Dimension	Level	Notes
mechanics	HIGH
facts	MEDIUM	Two contradicted verdicts (compliance list, Cloud KMS framing) and six unverifiable claims — including a likely-hallucinated "Google publishes sample rotation functions" line and a specific quota figure (90,000/min) the verifier couldn't pin to current docs.

Investigation log

• Cross-sibling reads: 0 of 0 siblings (not in a templated section)
• External claim verification: 40 of 50 claims verified (6 unverifiable, 2 contradicted) · 4 specialists (numerical, cross-reference, capability, framing); 0 cross-specialist corroborations · routed: 0 inline, 24 Pass 1, 0 Pass 2, 26 Pass 3 (verified 23, contradicted 1, unverifiable 2).
• Cited-claim spot-checks: not run (no cited claims)
• Frontmatter sweep: ran on body + meta_desc
• Temporal-trigger sweep: ran (recency words present in diff; spot-check in-review)
• Code execution: not run (no static/programs/ change)
• Code-examples checks: not run (no fenced code blocks in content files)
• Editorial-balance pass: not run (not under content/blog/)

🚨 Outstanding	⚠️ Low-confidence	💡 Pre-existing	✅ Resolved
2	11	0	0

🔍 Verification trail

50 claims extracted · 40 verified · 6 unverifiable · 2 contradicted

• L3 in content/what-is/what-is-google-cloud-secret-manager.md "Google Cloud Secret Manager supports secret versioning and replication." → ✅ verified (evidence: The file explicitly lists both "Versioning" and "Replication policies" as core features in the feature table, and dedicates entire sections to each: "How does secret versioning work?" and "What replication policies are available?" The meta…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L10 in content/what-is/what-is-google-cloud-secret-manager.md "Google Cloud Secret Manager is a fully managed Google Cloud Platform service for securely storing, versioning, and accessing API keys, passwords, certificates,…" → ✅ verified (evidence: The file at line 10 reads verbatim: "Google Cloud Secret Manager is a fully managed Google Cloud Platform service for securely storing, versioning, and accessing API keys, passwords, certificates, and other sensitive data." — an exact matc…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L12 in content/what-is/what-is-google-cloud-secret-manager.md "Unlike AWS Secrets Manager, Google Cloud Secret Manager does not have a built-in rotation engine; rotation is implemented by the workload (often a Cloud Functi…" → ✅ verified (evidence: The file at L12 states: "Unlike AWS Secrets Manager, it doesn't have a built-in rotation engine; rotation is implemented by the workload (often a Cloud Function on a Cloud Scheduler trigger)." The comparison table further confirms: Google…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L33 in content/what-is/what-is-google-cloud-secret-manager.md "Workload Identity Federation extends the Google Cloud IAM model to identities outside Google Cloud, including GitHub Actions, AWS, Azure, and on-prem." → ✅ verified (framing: strengthened — claim makes explicit "the Google Cloud IAM model" where the source uses the pronoun "this model"; the referent is unambiguous from context, so t…; evidence: The file at L33 states: "Workload Identity Federation extends this model to identities outside Google Cloud (GitHub Actions, AWS, Azure, on-prem)." — where "this model" refers to the Google Cloud IAM model described in the preceding senten…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L37 in content/what-is/what-is-google-cloud-secret-manager.md "Each new secret value creates a new immutable version. Versions can be enabled, disabled, or destroyed, but existing version values never change. That makes…" → ✅ verified (evidence: The file at L37 contains the exact claim text, and the "How does secret versioning work?" section of the same file corroborates it: "Versions are immutable; they can be enabled (readable), disabled (still stored, not readable), or destroye…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L41 in content/what-is/what-is-google-cloud-secret-manager.md "Secret Manager supports CMEK using Cloud KMS keys, including keys backed by Cloud HSM (FIPS 140-2 Level 3)." → ✅ verified (evidence: Google's official Cloud HSM documentation confirms: "Cloud HSM is a cloud-hosted Hardware Security Module (HSM) service that lets you host encryption keys and perform cryptographic operations in a cluster of FIPS 140-2 Level 3 certified HS…; source: https://cloud.google.com/kms/docs/hsm)
• L47-48 in content/what-is/what-is-google-cloud-secret-manager.md "Google Cloud Secret Manager encrypts data at rest using AES-256 with Google-managed keys or CMEK from Cloud KMS." → ✅ verified (evidence: The file at content/what-is/what-is-google-cloud-secret-manager.md contains a feature table with the row: "Encryption at rest | AES-256 with Google-managed keys or CMEK from Cloud KMS", which exactly matches the claim. The document als…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L50-51 in content/what-is/what-is-google-cloud-secret-manager.md "Google Cloud Secret Manager replication policies are either Automatic (Google-chosen Regions) or user-managed (user lists the Regions)." → ✅ verified (evidence: The file's feature table at the relevant lines reads: "Replication policies | Automatic (Google-chosen Regions) or user-managed (you list the Regions)" — an exact match to the claim. The dedicated replication section further confirms:…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L51 in content/what-is/what-is-google-cloud-secret-manager.md "Secret Manager replication policies are either Automatic (Google-chosen Regions) or user-managed (user lists the Regions)." → ✅ verified (evidence: The file's core features table at the "Replication policies" row reads exactly: "Automatic (Google-chosen Regions) or user-managed (you list the Regions)", and the dedicated replication section confirms: "Automatic | Google replicates the…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L52 in content/what-is/what-is-google-cloud-secret-manager.md "Secret Manager audit logging covers admin operations and, when enabled, data-access logs to Cloud Audit Logs." → ✅ verified (evidence: The file's feature table at the relevant line reads: "| Audit logging | Admin and (when enabled) data-access logs to Cloud Audit Logs |" — exactly matching the claim that admin operations are always logged and data-access logs are avai…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L55 in content/what-is/what-is-google-cloud-secret-manager.md "| Rotation hooks | Notification topic on a configurable schedule; rotation logic runs in your code |" → ✅ verified (framing: strengthened — claim summarizes "Pub/Sub notification topic on a configurable schedule; rotation logic runs in your code," which is a narrower but accurate sub…; evidence: Official Google Cloud docs confirm: "Secret Manager does this by sending notifications to Pub/Sub topics associated with your secrets, based on the rotation frequency and time that you specify." The rotation logic itself runs in user-owned…; source: https://cloud.google.com/secret-manager/docs/secret-rotation)
• L57 in content/what-is/what-is-google-cloud-secret-manager.md "A secret in Secret Manager is addressable by name using the path format projects/<project>/secrets/<name>/versions/<version>." → ✅ verified (evidence: The Google Cloud Secret Manager REST API reference confirms the resource name format: "The resource name of the SecretVersion in the format projects//secrets//versions/*"; source: https://cloud.google.com/secret-manager/docs/reference/rest/v1beta1/projects.secrets.versions)
• L61 in content/what-is/what-is-google-cloud-secret-manager.md "Secret Manager versions can be enabled (readable), disabled (still stored, not readable), or destroyed (permanently deleted)." → ✅ verified (evidence: Google Cloud docs confirm the three states: "Enabled - In this state, the secret version can be accessed and described. Disabled - In this state, the secret version cannot be accessed, but the secret's contents still exist." And for destro…; source: https://docs.cloud.google.com/secret-manager/docs/add-secret-version (states); https://docs.cloud.google.com/secret-manager/docs/destroy-secret-version (destroyed state))
• L63 in content/what-is/what-is-google-cloud-secret-manager.md "* latest alias. Reads of secrets/<name>/versions/latest resolve to the most recent enabled version." → ➖ not-a-claim (evidence: The word latest in secrets/<name>/versions/latest is a named API path alias in the Google Cloud Secret Manager API, not a temporal/recency claim about software versions or documentation. The regex flagged it as temporal, but it is simp…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L65 in content/what-is/what-is-google-cloud-secret-manager.md "* No mutation. Updating a secret never modifies an existing version — it creates a new one." → ✅ verified (framing: strengthened — the claim at L65 narrows the broader immutability statement at L47 to the specific update-creates-new-version behavior; the source's broader for…; evidence: The file itself states at L47: "Each new secret value creates a new immutable version. Versions can be enabled, disabled, or destroyed, but existing version values never change." The claim at L65 ("Updating a secret never modifies an exi…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L72 in content/what-is/what-is-google-cloud-secret-manager.md "The replication policy choice for a Google Cloud Secret Manager secret is permanent and cannot be changed after secret creation." → ✅ verified (evidence: (escalated from pass1) The official Google Cloud Secret Manager docs state "The locations in the replication policy can't be updated," and the Pulumi Registry docs for gcp.secretmanager.Secret explicitly state "It cannot be changed after t…; source: https://cloud.google.com/secret-manager/docs/choosing-replication; https://www.pulumi.com/registry/packages/gcp/api-docs/secretmanager/secret/)
• L79 in content/what-is/what-is-google-cloud-secret-manager.md "Automatic replication is the simplest and is what most teams use. User-managed replication is necessary when data-residency requirements pin the data to specif…" → ✅ verified (framing: strengthened — claim says "most teams use" where source says "recommended for most users"; the replication-immutability claim is slightly broader than the sour…; evidence: Google's official docs confirm: automatic replication "is the simplest configuration and is recommended for most users" (docs.cloud.google.com/secret-manager/docs/choosing-replication); user-managed is needed for data residency and Regiona…; source: https://docs.cloud.google.com/secret-manager/docs/choosing-replication; https://docs.cloud.google.com/secret-manager/docs/cmek)
• L83 in content/what-is/what-is-google-cloud-secret-manager.md "| Capability | Google Cloud Secret Manager | AWS Secrets Manager | [Azure Key Vault](/what-is/what-is-azure-key-vault/…" → ✅ verified (evidence: The file content/what-is/what-is-aws-secrets-manager.md exists in the repository with the title "What is AWS Secrets Manager?", confirming the internal link /what-is/what-is-aws-secrets-manager/ referenced in the comparison table is va…; source: repo:content/what-is/what-is-aws-secrets-manager.md)
• L85 in content/what-is/what-is-google-cloud-secret-manager.md "HashiCorp Vault can be self-hosted or HCP managed." → ✅ verified (evidence: Official HashiCorp docs confirm both deployment modes: "Vault Community edition supports a self-managed deployment model. Vault Enterprise can also be in a self-managed environment, but is also available as a managed service through the Ha…; source: https://developer.hashicorp.com/vault/tutorials/get-started/available-editions)
• L86-88 in content/what-is/what-is-google-cloud-secret-manager.md "AWS Secrets Manager has built-in rotation for RDS, Redshift, and DocumentDB, and uses Lambda for other rotation." → ✅ verified (framing: strengthened — claim says "built-in rotation" for RDS/Redshift/DocumentDB; source confirms native support for exactly those three. The claim omits that even na…; evidence: AWS docs confirm: "Secrets Manager natively supports rotating secrets for all Amazon database services — Amazon RDS, Amazon DocumentDB, and Amazon Redshift" and "You can extend Secrets Manager to meet your custom rotation requirements by c…; source: https://aws.amazon.com/blogs/security/how-to-rotate-amazon-documentdb-and-amazon-redshift-credentials-in-aws-secrets-manager/)
• L87-88 in content/what-is/what-is-google-cloud-secret-manager.md "Azure Key Vault has built-in certificate rotation and supports secret rotation via Functions." → ✅ verified (evidence: Microsoft's official docs confirm both parts of the claim: "Key Vault handles certificate renewal with integrated certificate authorities (CAs) or through self-signed certificate regeneration" (built-in certificate rotation), and "Secrets…; source: https://learn.microsoft.com/en-us/azure/key-vault/general/autorotation)
• L87 in content/what-is/what-is-google-cloud-secret-manager.md "Google Cloud Secret Manager does not have built-in secret rotation; it uses a notification topic plus user-provided code." → ✅ verified (evidence: The file at L87 (comparison table) states: "Built-in rotation: No; notification topic + your own code" for Google Cloud Secret Manager, and the intro paragraph reinforces: "Unlike AWS Secrets Manager, it doesn't have a built-in rotation en…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L88-89 in content/what-is/what-is-google-cloud-secret-manager.md "Azure Key Vault's HSM option includes a Premium (multi-tenant) tier and a Managed HSM (single-tenant) tier." → ✅ verified (evidence: Microsoft's official docs confirm: "Azure Key Vault Standard and Premium are multitenant offerings" while "Managed HSM provides single-tenant, highly available HSMs to store and manage your cryptographic keys."; source: https://learn.microsoft.com/en-us/azure/security/fundamentals/key-management and https://learn.microsoft.com/en-us/azure/key-vault/keys/about-keys)
• L92 in content/what-is/what-is-google-cloud-secret-manager.md "For workloads on GCP, Secret Manager is almost always the right default. For multi-cloud or hybrid deployments, organizations frequently pair it with HashiCorp…" → ➖ not-a-claim (evidence: The text at L92 is a faithful description of the PR author's own design/recommendation about Pulumi ESC's capabilities, not a third-party-attributed assertion. The /product/esc/ link is an internal Pulumi product page reference, and the…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L102 in content/what-is/what-is-google-cloud-secret-manager.md "The standard predefined roles:" → ✅ verified (framing: strengthened — claim uses "standard predefined roles" as a heading label; source uses "predefined roles" broadly, which encompasses the claim as a subset.; evidence: Google Cloud Secret Manager does have a set of predefined IAM roles. The official docs state "Following are the IAM roles that are associated with Secret Manager," listing roles like secretmanager.admin, secretmanager.secretAccessor, and s…; source: https://docs.cloud.google.com/secret-manager/docs/access-control)
• L106 in content/what-is/what-is-google-cloud-secret-manager.md "* roles/secretmanager.secretVersionAdder — add new versions." → ✅ verified (evidence: The file at line 106 lists roles/secretmanager.secretVersionAdder with the description "add new versions." This matches the well-documented Google Cloud Secret Manager predefined IAM role, which grants permission to add new secret versio…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L116 in content/what-is/what-is-google-cloud-secret-manager.md "Cloud Run and Cloud Functions allow referencing a Secret Manager secret directly in the service configuration; the runtime mounts it as an environment variable…" → ✅ verified (framing: strengthened — the claim states the path is /etc/secrets/, which the official docs use only as an illustrative example; the actual mount path is user-defined…; evidence: Official Cloud Run docs confirm: "Secret Manager secrets can be accessed from Cloud Run as mounted file paths or as environment variables." The path /etc/secrets/ appears in official docs as an example: "for example: /etc/secrets/dbconfi…; source: https://cloud.google.com/run/docs/configuring/services/secrets)
• L117 in content/what-is/what-is-google-cloud-secret-manager.md "Google Kubernetes Engine uses the Secrets Store CSI Driver with the GCP provider to mount Secret Manager values into pod filesystems, with authentication via G…" → ✅ verified (evidence: Multiple authoritative sources confirm all parts of the claim. The GoogleCloudPlatform GitHub repo states: "Allows you to access secrets stored in Secret Manager as files mounted in Kubernetes pods" and "Create a new GKE cluster with Workl…; source: https://github.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp/blob/main/README.md; https://docs.cloud.google.com/secret-manager/docs/secret-manager-managed-csi-component)
• L118 in content/what-is/what-is-google-cloud-secret-manager.md "Cloud Build pipelines fetch secrets at build time via availableSecrets blocks, and secret payloads stay out of build logs." → ✅ verified (framing: strengthened — the claim's "stay out of build logs" is a narrower/best-case framing; the official docs don't guarantee automatic masking, but secrets don't app…; evidence: (escalated from pass1) Official Google Cloud Build docs confirm secrets are fetched via availableSecrets blocks at build time. Regarding logs: one source notes "secret values logged to Cloud Build are visible in the build history" if exp…; source: https://docs.cloud.google.com/build/docs/securing-builds/use-secrets)
• L119 in content/what-is/what-is-google-cloud-secret-manager.md "Compute Engine VMs use their attached service account to call the Secret Manager API, paired with metadata server-backed authentication." → ✅ verified (evidence: (escalated from pass1) Google's official Secret Manager authentication docs confirm: "To authenticate a workload running on Google Cloud, you use the credentials of the service account attached to the compute resource where your code is ru…; source: https://docs.cloud.google.com/secret-manager/docs/authentication and https://docs.cloud.google.com/compute/docs/access/authenticate-workloads)
• L120 in content/what-is/what-is-google-cloud-secret-manager.md "Workload Identity Federation issues short-lived service account credentials based on the CI system's OIDC token for GitHub Actions and other external CI." → ✅ verified (framing: strengthened — claim specifies "service account credentials" as the short-lived output; sources confirm short-lived OAuth 2.0/JWT credentials are issued, and t…; evidence: (escalated from pass1) Google Cloud's official documentation and GitHub Docs confirm that Workload Identity Federation exchanges a CI system's OIDC token for short-lived credentials. The Google Cloud blog states: "Unlike JSON service accou…; source: https://cloud.google.com/blog/products/identity-security/enabling-keyless-authentication-from-github-actions; https://docs.github.com/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-google-cloud-platform)
• L127-128 in content/what-is/what-is-google-cloud-secret-manager.md "Google Cloud Secret Manager pricing charges per active secret version, per location, per month." → ✅ verified (evidence: The official Google Cloud Secret Manager pricing page states: "Secret Manager bills monthly for the number of active secret versions per location," confirming the per-active-secret-version, per-location, per-month pricing model.; source: https://cloud.google.com/secret-manager/pricing)
• L130 in content/what-is/what-is-google-cloud-secret-manager.md "Cloud KMS keys used for CMEK with Secret Manager are billed separately under KMS pricing." → ✅ verified (framing: strengthened — claim narrows the general KMS billing rule to the specific Secret Manager CMEK context; the source's broader form proves the claim as a subset.; evidence: The Google Cloud KMS pricing page confirms: "All billable items are billed to the project that owns the key, even for CMEK keys that operate on a resource owned by another project," establishing that CMEK keys used with Secret Manager are…; source: https://cloud.google.com/kms/pricing)
• L134 in content/what-is/what-is-google-cloud-secret-manager.md "Pulumi ESC treats Secret Manager as one of many secret sources. The GCP Secrets provider read…" → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
• L138 in content/what-is/what-is-google-cloud-secret-manager.md "* Dynamic GCP credentials via OIDC. ESC mints short-lived Google Cloud credentials at the moment a consumer opens the environment, removing the need for lo…" → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
• L143 in content/what-is/what-is-google-cloud-secret-manager.md "The gcp.secretmanager Pulumi resource lets you define and manage Secret Manager resources as code in TypeScript, Python, Go, C#, Java, or YAML." → ✅ verified (evidence: The gcp.secretmanager Pulumi resource namespace exists in pulumi/pulumi-gcp with SDKs for TypeScript (sdk/nodejs/secretmanager/), C# (sdk/dotnet/SecretManager/), Go (provider/resources.go), Java (`sdk/java/.../secretmanager/Secret.…; source: gh_query: gh api repos/pulumi/pulumi-gcp/contents/sdk/java/src/main/java/com/pulumi/gcp/secretmanager; gh search code --owner pulumi gcp.secretmanager --repo pulumi/pulumi-gcp)
• L149 in content/what-is/what-is-google-cloud-secret-manager.md "Google Cloud Secret Manager can publish a notification to a Pub/Sub topic on a rotation schedule, and the user's code (often a Cloud Function triggered by that…" → ✅ verified (framing: strengthened — the file says "notification topic on a configurable schedule; rotation logic runs in your code"; the claim correctly narrows this to Pub/Sub top…; evidence: The file itself describes Secret Manager's rotation mechanism in the features table as "Notification topic on a configurable schedule; rotation logic runs in your code," and the comparison table confirms "No [built-in rotation]; notificati…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L149 in content/what-is/what-is-google-cloud-secret-manager.md "For managed-database credentials, Google publishes sample rotation functions for Secret Manager." → 🤷 unverifiable (evidence: Official Google Cloud Secret Manager docs describe a notification-based rotation model (Pub/Sub → user-written Cloud Function) but do not mention Google publishing pre-built "sample rotation functions" for managed-database credentials. One…; source: WebSearch ran query "Google Cloud Secret Manager sample rotation functions database site:cloud.google.com"; top results (docs.cloud.google.com/secret-manager/docs/rotation-recommendations, docs.cloud.google.com/secret-manager/docs/secret-rotation) didn't address the specific claim of Google-published sample rotation functions for managed databases.; intuition: The claim resembles AWS Secrets Manager's well-known Lambda rotation templates for RDS; GCP's model is notification-bas…)
• L153 in content/what-is/what-is-google-cloud-secret-manager.md "Google Cloud Secret Manager is in scope for SOC 1, SOC 2, SOC 3, ISO 27001, ISO 27017, ISO 27018, FedRAMP High, and PCI DSS." → ❌ contradicted (framing: shifted — the claim attributes SOC 1/2/3, ISO 27001/27017/27018, and PCI DSS to Secret Manager specifically; the source lists only CJIS, FedRAMP Moderate/High,…; evidence: The official Secret Manager compliance page (last updated 2026-04-17) lists: "Secret Manager meets the following compliance standards: CJIS · FedRAMP Moderate and FedRAMP High · HIPAA · HITRUST CSF · DoD IL2, IL4, and IL5 PAs · ITAR · IRS…; source: https://docs.cloud.google.com/secret-manager/docs/compliance)
• L157 in content/what-is/what-is-google-cloud-secret-manager.md "The default access quota for Google Cloud Secret Manager is 90,000 access requests per minute per project." → 🤷 unverifiable (evidence: The official Google Cloud Secret Manager quotas page (last updated 2026-05-08) states "The current API usage quotas for the Secret Manager API are as follows (and are subject to change)" but the actual table values (including any 90,000 fi…; source: WebSearch ran query "site:cloud.google.com secret manager '90,000' access requests quota"; https://docs.cloud.google.com/secret-manager/quotas; intuition: The official quotas page table data was not returned in search snippets; the 90,000 figure may be stale or may still be…)
• L161 in content/what-is/what-is-google-cloud-secret-manager.md "Secret Manager uses Cloud KMS under the hood to encrypt secret payloads." → ❌ contradicted (framing: narrowed — claim broadens the CMEK-specific use of Cloud KMS to a universal "under the hood" statement; source supports only that Cloud KMS is used when CMEK i…; evidence: The file itself states "AES-256 with Google-managed keys or CMEK from Cloud KMS" — Cloud KMS is only involved when customer-managed encryption keys (CMEK) are configured, not universally "under the hood." The claim that Secret Manager uses…; source: repo:content/what-is/what-is-google-cloud-secret-manager.md)
• L161 in content/what-is/what-is-google-cloud-secret-manager.md "Cloud KMS manages cryptographic keys used for encryption and signing." → ✅ verified (evidence: The official Google Cloud KMS overview states: "Cloud Key Management Service (Cloud KMS) lets you create and manage cryptographic keys" and the API "let you encrypt and decrypt data, sign data, and validate signatures." Multiple Google sou…; source: https://docs.cloud.google.com/kms/docs/key-management-service)
• L165 in content/what-is/what-is-google-cloud-secret-manager.md "To use Secret Manager from GitHub Actions, you configure Workload Identity Federation between Google Cloud and GitHub Actions, then use the google-github-acti…" → ✅ verified (evidence: The official google-github-actions/get-secretmanager-secrets` README confirms: "Use google-github-actions/auth to authenticate the action. You can use Workload Identity Federation or traditional Service Account Key JSON authentication." E…; source: https://github.com/google-github-actions/get-secretmanager-secrets/blob/main/README.md)
• L169 in content/what-is/what-is-google-cloud-secret-manager.md "Yes, though it's a one-time export-and-import. List secrets via gcloud secrets list, fetch each value, and write into Vault's KV v2 engine. [Pulumi ESC](/pro…" → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
• L173 in content/what-is/what-is-google-cloud-secret-manager.md "When a Google Cloud Secret Manager version is destroyed, the version moves to the DESTROYED state, its payload is deleted, the version's ID still exists for au…" → 🤷 unverifiable (evidence: verification did not converge within 8 turns)
• L177 in content/what-is/what-is-google-cloud-secret-manager.md "Mapping a Kubernetes service account to a Google service account with roles/secretmanager.secretAccessor allows pods running with that KSA to call the Secret…" → ✅ verified (framing: strengthened — the claim specifically frames this as "mapping a KSA to a Google service account"; modern GKE Workload Identity Federation can bind the KSA dire…; evidence: Google Cloud docs confirm that granting a Kubernetes service account roles/secretmanager.secretAccessor via Workload Identity Federation allows pods running with that KSA to "authenticate to the Secret Manager API" without long-lived cre…; source: https://cloud.google.com/kubernetes-engine/docs/tutorials/workload-identity-secrets)
• L181 in content/what-is/what-is-google-cloud-secret-manager.md "Automatic replication lets Google choose the Regions; it's the simplest option and works for most workloads. User-managed replication lets you list the Regions…" → ✅ verified (framing: strengthened — claim narrows the source's general "recommended for most users" to "works for most workloads" and the source's broader data-residency/CMEK guida…; evidence: Official Google Cloud docs confirm: automatic replication has Google manage regions ("Google Cloud decides the regions considering availability and latency") and is "the simplest configuration and is recommended for most users"; user-manag…; source: https://docs.cloud.google.com/secret-manager/docs/choosing-replication; https://docs.cloud.google.com/secret-manager/docs/overview; https://computingforgeeks.com/google-cloud-secret-manager-tutorial/ (index 3-20))
• L185 in content/what-is/what-is-google-cloud-secret-manager.md "In Google Cloud Secret Manager, Admin Activity logs are always on by default, but Data Access logs (which record secretmanager.googleapis.com/AccessSecretVersi…" → ✅ verified (evidence: (escalated from pass1) Google Cloud official docs and multiple authoritative sources confirm: "Admin Activity audit logs are enabled by default and cannot be turned off" and "Data Access audit logs are disabled by default and must be expli…; source: https://docs.cloud.google.com/logging/docs/audit/configure-data-access; https://www.trendmicro.com/trendaivisiononecloudriskmanagement/knowledge-base/gcp/SecretManager/enable-audit-logs-for-secret-manager.html)
• L189 in content/what-is/what-is-google-cloud-secret-manager.md "The Pulumi Google Cloud provider lets you declare every secret, version, and IAM binding as code in TypeScript, Python, Go, C#, Java, or YAML." → ✅ verified (evidence: The pulumi-gcp repo contains SDK directories for dotnet (C#), go, java, nodejs (TypeScript/JavaScript), and python. YAML is a first-class Pulumi language supported by all providers via the engine. All six languages listed in the claim (Typ…; source: gh api repos/pulumi/pulumi-gcp/contents/sdk — directories: dotnet, go, java, nodejs, python confirmed present)
• L193-198 in content/what-is/what-is-google-cloud-secret-manager.md "* What is AWS Secrets Manager?" → ✅ verified (evidence: The file content/what-is/what-is-aws-secrets-manager.md exists in the repo with the title "What is AWS Secrets Manager?", confirming the linked page /what-is/what-is-aws-secrets-manager/ is a valid internal URL.; source: repo:content/what-is/what-is-aws-secrets-manager.md)

🚨 Outstanding in this PR

These must be resolved or refuted before merging.

• [L153] content/what-is/what-is-google-cloud-secret-manager.md — "Google Cloud Secret Manager is in scope for SOC 1, SOC 2, SOC 3, ISO 27001, ISO 27017, ISO 27018, FedRAMP High, and PCI DSS." — verdict: contradicted; framing: shifted — claim attributes SOC 1/2/3, ISO 27001/27017/27018, and PCI DSS specifically to Secret Manager; the official Secret Manager compliance page enumerates a different (smaller) set. Source: https://docs.cloud.google.com/secret-manager/docs/compliance.

  Why this matters: readers — likely security or compliance reviewers — will quote this sentence directly into RFP responses or audit evidence. The current list overstates Secret Manager's certifications. Google's compliance page enumerates Secret Manager specifically as: CJIS, FedRAMP Moderate, FedRAMP High, HIPAA, HITRUST CSF, DoD IL2/IL4/IL5, ITAR, IRS 1075. SOC 1/2/3 and the ISO family are Google Cloud-wide certifications that cover most services but are not enumerated on the Secret Manager-specific compliance page; PCI DSS likewise.

  Suggested rewrite (verify against https://docs.cloud.google.com/secret-manager/docs/compliance before merging, since the list does change):

  Yes. Secret Manager is covered under Google Cloud's HIPAA Business Associate Agreement. Per Google's Secret Manager compliance page, Secret Manager is in scope for CJIS, FedRAMP Moderate, FedRAMP High, HIPAA, HITRUST CSF, DoD IL2/IL4/IL5, ITAR, and IRS 1075. Additional Google Cloud-wide certifications (SOC 1/2/3, ISO 27001/27017/27018, PCI DSS) apply at the platform level — see Google Cloud's compliance documentation for the current authoritative list.

• [L161] content/what-is/what-is-google-cloud-secret-manager.md — "Secret Manager stores arbitrary secret payloads (and uses Cloud KMS under the hood to encrypt them)." — verdict: contradicted; framing: narrowed — the page contradicts itself: the feature table at L47 states "AES-256 with Google-managed keys or CMEK from Cloud KMS," which means Cloud KMS only enters the path for CMEK-encrypted secrets, not by default.

  Why this matters: this is in the "How is Secret Manager different from Cloud KMS?" FAQ — exactly where readers go to disambiguate the two services. The current parenthetical implies a coupling that doesn't exist by default, and could make readers think provisioning Secret Manager requires provisioning KMS keys.

  Suggested rewrite:

  Cloud KMS manages cryptographic keys used for encryption and signing. Secret Manager stores arbitrary secret payloads, encrypted at rest with Google-managed keys by default — or with a CMEK from Cloud KMS, if you opt in. For an API key or database password, use Secret Manager. For a key used to encrypt application data, use Cloud KMS.

⚠️ Low-confidence

Review each and resolve as appropriate — these don't block the PR.

• [L134] content/what-is/what-is-google-cloud-secret-manager.md — "Pulumi ESC treats Secret Manager as one of many secret sources. The GCP Secrets provider reads secrets from Secret Manager into an ESC environment…" — verdict: unverifiable; verifier didn't converge in 8 turns. The two internal links resolve (the linked /docs/pulumi-cloud/esc/providers/gcp-secrets/ page exists), and the framing reads as a faithful description of ESC's documented capability. Author question: can you confirm the page at /docs/pulumi-cloud/esc/providers/gcp-secrets/ actually describes "reads secrets from Secret Manager into an ESC environment"? If yes, no change needed — the verifier just timed out on a phrasing match.

• [L138] content/what-is/what-is-google-cloud-secret-manager.md — "ESC mints short-lived Google Cloud credentials at the moment a consumer opens the environment, removing the need for long-lived service account keys anywhere." — verdict: unverifiable; verifier didn't converge in 8 turns. The bullet links to /docs/pulumi-cloud/esc/providers/gcp-login/, an internal page; the framing is consistent with how the gcp-login provider is described elsewhere. Author question: the "credentials at the moment a consumer opens the environment" phrasing is a strong claim — please confirm the gcp-login provider docs use that "just-in-time" framing, and that the credential is in fact a Google Cloud federated token (vs. a separate token type).

• [L149] content/what-is/what-is-google-cloud-secret-manager.md — "for managed-database credentials, Google publishes sample rotation functions." — verdict: unverifiable, with strong intuition this is incorrect. Google's Secret Manager rotation model is notification-based (Pub/Sub → user-written Cloud Function); the verifier found rotation recommendations docs but no Google-published "sample rotation functions" matching the AWS-Lambda-templates-for-RDS pattern this sentence implies. Source: https://docs.cloud.google.com/secret-manager/docs/rotation-recommendations. Author question: can you cite the specific Google-published sample rotation functions you're referring to (URL or repo)? If you're thinking of the rotation-recommendations doc, that's a guidance doc, not a publication of sample functions — and the sentence should be reworded or dropped. If you can't cite a source, please remove this clause; it risks sending readers to look for something that doesn't exist.

• [L157] content/what-is/what-is-google-cloud-secret-manager.md — "Default access quotas are 90,000 access requests per minute per project; they can be raised via a quota request." — verdict: unverifiable. The official quotas page (https://docs.cloud.google.com/secret-manager/quotas) does say "subject to change," and the table values weren't returned in the search snippet, so the verifier couldn't confirm the 90,000 figure. Author question: please re-check the current value on the quotas page and either keep the number (with a confirmation it's still 90,000/min as of merge) or soften to "tens of thousands of access requests per minute" and let the linked page own the precise figure. Same review applies to the "commonly 1,000,000" secret limit on the next clause.

• [L169] content/what-is/what-is-google-cloud-secret-manager.md — "List secrets via gcloud secrets list, fetch each value, and write into Vault's KV v2 engine." — verdict: unverifiable; verifier didn't converge. The two commands (gcloud secrets list, Vault KV v2 writes) are well-documented individually but the verifier couldn't confirm that combination as a recommended migration path. The claim is opinion-flavored ("how you'd do it") rather than a hard fact, so leaving it stands. Author question: is this the migration path you'd actually recommend, or worth softening to "you can script a one-time export from gcloud secrets list and write the values into Vault's KV v2 engine" to make it clearly a sketch rather than a prescription?

• [L173] content/what-is/what-is-google-cloud-secret-manager.md — "The version moves to the DESTROYED state and its payload is deleted. The version's ID still exists for audit purposes, but the value is unrecoverable." — verdict: unverifiable; verifier didn't converge. The DESTROYED state and unrecoverable-payload behavior is documented at https://docs.cloud.google.com/secret-manager/docs/destroy-secret-version; the L61 trail line ("destroyed (permanently deleted)") was independently verified against the same source. This is almost certainly correct — the verifier just timed out. Author question: if it isn't a burden, consider linking to https://cloud.google.com/secret-manager/docs/destroy-secret-version directly so future readers (and verifiers) can confirm without a search.

Style findings

Found by pattern-based linting; Findings may be false positives.

• line 98: [style] difficulty qualifier — Avoid difficulty qualifier 'simple' -- it judges difficulty for the reader (STYLE-GUIDE.md §Inclusive Language).
• line 149: [style] wordiness — 'is responsible for' is too wordy.
• line 163: [style] first person — Avoid first-person pronouns such as ' I '.
• line 167: [style] first person — Avoid first-person pronouns such as ' I '.
• line 171: [style] first person — Avoid first-person pronouns such as ' I '.

💡 Pre-existing issues in touched files (optional)

No pre-existing issues in touched files.

✅ Resolved since last review

No items resolved since the last review.

📜 Review history

• 2026-05-20T16:58:06Z — Two contradicted factual claims (compliance enumeration at L153, "Cloud KMS under the hood" at L161) and six unverifiable claims (including a likely-hallucinated "Google publishes sample rotation functions" at L149 and the 90,000/min quota at L157); five Vale style nags. (f346451)

---

Need a re-review? Want to dispute a finding? Mention @claude and include #update-review.
(For ad-hoc questions or fixes, just @claude — no hashtag.)