Well, for me that feels like a bandaid for a different problem...

 resource=[JcrNodeResource, type=nt:unstructured, superType=null, path=/content/suncorp/businesspartners/en/home/reference-pages/policy-ref/rlg-nav/jcr:content/par/canvas/pars/content_container_1102807329]This the candidate.It's the node /content/suncorp/businesspartners/en/home/reference-pages/poli...

In the end, for testing purposes it's not different from a normal publish. Instead of configuring it behind the "publish" replication agent, you need to create a "preview" replication agent for it.

I don't think that this will work at all, in the end the bundle dependencies need to form a directed tree, and not a graph with cycles.

Why don't you use the replication API for this? 

You can have both at the same time  This is what we do with a customer. They have a lot of content, which is not changing frequently, and for which the classic invalidation is well suited. But they also have sections of the content, which need to expire very frequently, and for these we have a TTL c...

Yes, that user and its credentials is owned by Adobe.

But when you request that information from a publish instance, isn't the replication status always (and implicit) "replicated"? Because otherwise these CFS would not be present on a publish instance.

Where do these calculations happen? On author? In that situation the replication status is accurate. It's just that the information on publish is not accurate, but at that point you don't really need it at all.

 @TimothyJ wrote: I am an admin and Well, you might have an admin role in your organisation, but your are NOT the "admin" of the AEM instance (meaning that role you get when you use "admin/admin" on your local SDK instance). For that reason you cannot impersonate into other users unless these users ...