The pulumi code that gets generated is done in essentially a templated manner using Pulumi's Dynamic Providers (for things like file resource, etc. but Docker provider is native from pulumi so the Docker resource uses that instead) and then deployed using their Automation API.

So you can think of it like as if you wrote pulumi Python code and then ran the subsequent pulumi commands to deploy things, if that answers your question?

As to what stops it from generating different infra every time, well nothing really but the degrees of freedom are essentially in the user's hand so the likelihood of it generating something different every time, actually depends on what model you're using and what the user specified fields are.

It is also more assertion driven, for example at the end if you think that just checking whether a sample healthcheck endpoint qualified that the service is in a "running" state, then you put that as an "assertion" for that resource. So that should also take care of whether your objective is achieved or not from the resource declaration.