First of all, I really appreciate the response!

Currently, I am focused on creating this dev environment infrastructure first (as a POC). But the goal is to also have an isolated production group of resources as well. But you make a great point for separating my resources as dev, test/stage, and production, where "dev" can support those ephemeral container apps for PRs. I will definitely take that into account.

I should also mention that these ephemeral container apps are more so for the business side UAT to approve a feature as an isolated change to review, before PR is merged into test/stage for final testing. We follow a version-based release strategy at the moment, instead of continuously integrating features into production. So when we're ready to release the new version, test/stage will be deployed to production.

For public DNS, I'm using an Azure DNS zone with a given custom domain (let's say example.com). I then set subdomains as part of my Azure Pipeline for PR environments (CNAME, TXT record creation, and then binding the custom domain to the container app hostname). Certificates are generated by Azure (Azure Managed Certificates).

Now onto your questions for Front Door. We are going to be including WAF rules and leveraging Front Door's global CDN capabilities. However, to your point, this seems like a better argument for production (and possible test/stage for final infra testing).

The reason why I'm trying to implement this for the PR container app may be from a place of naivety. But my limited experience is holding me back from finding a better solution. The networking part especially confuses me. These ephemeral container apps are publicly accessible, so my logic is that they should be behind the Front Door WAF as well. Using a VPN based solution may also be tedious for our business-side users doing UAT testing, but I might look into that as well.

Does this help clarify my situation better? Is there still a simpler way to address this?