No matter how you like to participate in developer communities, Pulumi wants to meet you there. If you want to meet other Pulumi users to share use-cases and best practices, contribute code or documentation, see us at an event, or just tell a story about something cool you did with Pulumi, you are part of our community.

Pulumi Community

If you use the service as your secret manager, then yes, it's not an issue.

We have a multi-account setup and each account has a specific `kms cmk` and use `aws-vault` for sessions so all my pulumi commands are either prefixed with `aws-vault exec` or I run the vault in the shell.

We do not have CI/CD yet and I see the benefit of different KMS keys as an extra layer of protection against human error.

But if you are going to use Pulumi service only for secrets instead of storing the state (I think)
<https://www.pulumi.com/docs/intro/concepts/secrets/#secrets>

This sounds like <https://github.com/pulumi/pulumi/issues/2823>

it is possible to have distinct kms keys, but you need to assume role and grab temporary credentials, and it's very finicky.

again, this is where the service comes into effect because it removes all the management overhead here

you can't use the service only for storing secrets