Document setting up customer-managed encryption keys better for GCP secrets sync

content/vault/v1.20.x/content/api-docs/system/secrets-sync.mdx

@@ -403,7 +403,7 @@ This endpoint creates a destination to synchronize secrets with the GCP Secret M
   store replicated secrets. Note that secrets remain globally readable regardless of the selected locations.
 
 - `locational_kms_keys` `(map<string|string>: nil)` - A map of location names to KMS key names to leverage customer-managed encryption keys for
-  encryption at rest. Each pair follows the format `location_name=encryption_key_resource_ID`. Refer to the
+  encryption at rest. Each pair follows the format `location_name=encryption_key_resource_name`. Refer to the
   [sample payloads](#sample-payloads) for more details.
 
 - `secret_name_template` `(string: "")` - Template to use when generating the secret names on the external system.

content/vault/v1.20.x/content/docs/sync/gcpsm.mdx

@@ -95,7 +95,9 @@ Prerequisites:
   ```shell-session
   $ vault write sys/sync/destinations/gcp-sm/my-dest/associations/set \
       mount='my-kv' \
-      secret_name='my-secret'
+      secret_name='my-secret' \
+      replication_locations='us-east1' \
+      locational_kms_keys='us-east1=projects/my-project/locations/us-east1/keyRings/my-east-keyring/cryptoKeys/my-east-key'
   ```
 
   **Output:**
@@ -137,7 +139,30 @@ corresponds with the planned replication policy. The key rings and keys must be
 
 When using a global KMS key, it must be the only key set on the destination and the replication locations must remain unset, meaning
 it can only be used with using GCP's automatic replication. When specifying regional keys, a key must be set for each region in the
-replication location list. GCP key names are expected in the format of the entire resource ID, e.g. `projects/<project_id>/locations/<location_name>/keyRings/<key_ring_name>/cryptoKeys/<key_name>`. See the [API](#api) section for more details.
+replication location list.
+
+You must specify GCP key names using the entire resource name. For example, 
+`projects/<project_id>/locations/<location_name>/keyRings/<key_ring_name>/cryptoKeys/<key_name>`.
+GCP key names, including the `keyRings` and `cryptoKeys` segments, are
+case-sensitive.
+Refer to the [Secrets sync API examples](/vault/api-docs/system/secrets-sync#sync-secrets-to-gcp-with-a-global-kms-key) for more details.
+
+A service agent identity for the `secretsmanager` API must be created for GCP keys. 
+The correct IAM policy bindings must be granted to the service agents
+with the `cloudkms.cryptoKeyEncrypterDecrypter` role. Be aware that you must
+grant the CloudKMS role to the service agent for each key and its corresponding
+replication location you want to use.
+
+Refer to the [GCP documentation](https://cloud.google.com/secret-manager/docs/cmek)
+for more details on setting up your GCP key resources. 
+
+<Warning title="CMEK silent failures">
+
+Failure to establish the proper IAM policy bindings for all encryption keys and replication locations
+typically causes GCP to silently ignore the customer-managed keys and fall back to Google-managed keys. Ensure you are using customer-managed encryption by validating the encryption type value on
+the secrets from the gcloud CLI or the web console.
+
+</Warning>
 
 ## Permissions
 

content/vault/v1.21.x (rc)/content/api-docs/system/secrets-sync.mdx

@@ -403,7 +403,7 @@ This endpoint creates a destination to synchronize secrets with the GCP Secret M
   store replicated secrets. Note that secrets remain globally readable regardless of the selected locations.
 
 - `locational_kms_keys` `(map<string|string>: nil)` - A map of location names to KMS key names to leverage customer-managed encryption keys for
-  encryption at rest. Each pair follows the format `location_name=encryption_key_resource_ID`. Refer to the
+  encryption at rest. Each pair follows the format `location_name=encryption_key_resource_name`. Refer to the
   [sample payloads](#sample-payloads) for more details.
 
 - `secret_name_template` `(string: "")` - Template to use when generating the secret names on the external system.

content/vault/v1.21.x (rc)/content/docs/sync/gcpsm.mdx

@@ -95,7 +95,9 @@ Prerequisites:
   ```shell-session
   $ vault write sys/sync/destinations/gcp-sm/my-dest/associations/set \
       mount='my-kv' \
-      secret_name='my-secret'
+      secret_name='my-secret' \
+      replication_locations='us-east1' \
+      locational_kms_keys='us-east1=projects/my-project/locations/us-east1/keyRings/my-east-keyring/cryptoKeys/my-east-key'
   ```
 
   **Output:**
@@ -137,7 +139,30 @@ corresponds with the planned replication policy. The key rings and keys must be
 
 When using a global KMS key, it must be the only key set on the destination and the replication locations must remain unset, meaning
 it can only be used with using GCP's automatic replication. When specifying regional keys, a key must be set for each region in the
-replication location list. GCP key names are expected in the format of the entire resource ID, e.g. `projects/<project_id>/locations/<location_name>/keyRings/<key_ring_name>/cryptoKeys/<key_name>`. See the [API](#api) section for more details.
+replication location list.
+
+You must specify GCP key names using the entire resource name. For example, 
+`projects/<project_id>/locations/<location_name>/keyRings/<key_ring_name>/cryptoKeys/<key_name>`.
+GCP key names, including the `keyRings` and `cryptoKeys` segments, are
+case-sensitive.
+Refer to the [Secrets sync API examples](/vault/api-docs/system/secrets-sync#sync-secrets-to-gcp-with-a-global-kms-key) for more details.
+
+A service agent identity for the `secretsmanager` API must be created for GCP keys. 
+The correct IAM policy bindings must be granted to the service agents
+with the `cloudkms.cryptoKeyEncrypterDecrypter` role. Be aware that you must
+grant the CloudKMS role to the service agent for each key and its corresponding
+replication location you want to use.
+
+Refer to the [GCP documentation](https://cloud.google.com/secret-manager/docs/cmek)
+for more details on setting up your GCP key resources. 
+
+<Warning title="CMEK silent failures">
+
+Failure to establish the proper IAM policy bindings for all encryption keys and replication locations
+typically causes GCP to silently ignore the customer-managed keys and fall back to Google-managed keys. Ensure you are using customer-managed encryption by validating the encryption type value on
+the secrets from the gcloud CLI or the web console.
+
+</Warning>
 
 ## Permissions