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

Looking into the `pulumi import` command, where can I find the `type-token` for a given resource?
<https://www.pulumi.com/docs/reference/cli/pulumi_import/>
Also is it possible to import a resource that the provider does not fully cover?

<@UB39JFCKC> <@UCWG26BH7> what is your advice on mix-and-matching pulumi and az cli when setting up a single resource? Az cli is used to work around features not covered by pulumi. I'd like to be able to:
1. pulumi up: create the resource if it does not exist
2. set properties that are not supported in pulumi using the az cli and some outputs from step 1. 
3. make sure pulumi up is not going to fail or revert all changes made at step 2 the next time  I want to update my stack. 

<@UB39JFCKC> C#, but it should not matter in that case.

<@UB39JFCKC>did you have any thoughts on this thread?

&gt; where can I find the `type-token` for a given resource?
In the docs for each resource, e.g. <https://www.pulumi.com/docs/reference/pkg/azure-native/storage/storageaccount/#import>
&gt; Also is it possible to import a resource that the provider does not fully cover?
Not sure I understand exactly. To import something, it should be expressible with Pulumi code, so I guess no?
&gt; what is your advice on mix-and-matching pulumi and az cli when setting up a single resource?
There isn’t a great story for .NET. You could call them completely separately from a CI pipeline or make a trick similar to what’s described here but this will invoke your CLI on every run
<https://blog.headforcloud.com/2020/02/09/pulumi-azure-static-sites/>

Thanks a lot <@UB39JFCKC>for your answers on type-token and import limitations.
That link shows a pretty interesting work around too, I may give it a try using the Graph SDK instead. By "this will invoke your CLI on every run", this will be on every deploy, not on every update right?

&gt; every deploy, not on every update
What’s the difference?
The example above will run on every program execution, so even on preview. There is a flag to check if you are in preview and short-circuit if needed.

Sorry <@UB39JFCKC>, "this will invoke your CLI" on every preview (pulumi up) or actual deployment of the update (yes to pulumi up)?

By default, on every execution, so previews and updates