This message was deleted.
# python
s
This message was deleted.
f
As someone mentioned before, you should treat your pulumi code as the declarative way of getting your resources deployed. So in this case, is better that you just import the resource into pulumi (pulumi import) and manage it from there. If you still want to check the existence of a resource instead then use any of the helper functions (getResource(), lookupResource()).
g
As a follow up here, as indicated you should always have the desired state of Pulumi. At a minimum, ensure the resource is imported and managed into the state. As a workaround, if another program/process/etc is responsible for changing some properties of the resource and you are just trying to avoid Pulumi from "fighting" with it, you could leverage the IgnoreChanges feature to exclude certain properties that the other process "owns": https://www.pulumi.com/docs/intro/concepts/resources/options/ignorechanges/ I don't think it should be overused. At a certain point, depending on what the resource is, it should be decided who or what is an authoritative owner of something when you get right down to it...
This could be useful in your secret scenario, @agreeable-businessperson-73427, as you wouldn't care about future out of band updates to the actual secret (such as policy, etc), and just are concerned that it is managed and exists.
Lastly, Pulumi does encrypt the stack so even having the actual value of the SecretVersion shouldn't be a huge concern; however, if it is, the resource you're lfor is this one, I believe: https://www.pulumi.com/registry/packages/aws/api-docs/secretsmanager/secretversion/, because
Secret
itself doesn't care about the values in it IIRC.