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 ...

The dispatcher is not involved here, this error message comes from AEM directly.

I wrote a 2 blog posts in the context of AEM CS backups and how you should use them: AEM CS backups are not for archival. And in my blog post I raised a number of questions why in one of my consulting projects I did not considered backups as a proper solution for an AEM on prem setup.And most of the...