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

image.png

Pulumi is _only_ declarative. You cannot change things: you can only declare what they must look like. If you want to update a resource, you must define that entire resource.
Since you want to continue to manage that resource outside of Pulumi, you cannot use Pulumi to update it. You can update it in a Pulumi program though, using the normal SDK of whatever provider (AWS, Azure, ...) the resource is in.

so a dynamic provider would be the only interoperable choice in this case? <https://www.pulumi.com/docs/concepts/resources/dynamic-providers/>

never understood the `pulumi import` workflow, how would that differ?

No. You could manage the resource in Pulumi. Or you could update the resource via its normal SDK. You should almost certainly not try to get Pulumi to update an unmanaged resource.

gotcha, I missed the "normal" in your previous comment, and took it to mean "use the sdk in pulumi"

if, for whatever reason, the normal sdk was used to update state outside pulumi, would a `pulumi refresh` be helpful here to resolve drift?

No. Since you're using the SDK directly, that bit of code is imperative, not declarative. You can use the Pulumi get functions where needed, and they also aren't affected by `pulumi refresh`.

You probably want to put the bit of code that calls the SDK into an apply() so that it happens at the right time, and you probably want to put in some sort of guard so that it doesn't happen if not needed.

And if you happen to be using automation-api, you may want to consider putting the code outside of your Pulumi projects entirely, and putting it directly into your automation-api code instead.