What about staging?
Before your files end up on the publicly available domain, you may want to test it on a separate environment. Or you may want to have multiple versions of the website. This is facilitated within the same Static Web App.The environment is created when a website is first published to Azure (e.g., using a pipeline).
If the Azure publish tool is used as part of a build pipeline for git, the name of the environment can either be specified explicitly or be taken from the branch that triggered the deployment. The new environment is automatically created by Azure, but can only be removed via the portal.
From test to production
Promotion of a test deployment to production is not done via Azure. You should have a step in your own process to promote the files that have been deployed to test, to the files to be deployed to the production environment. E.g., by merging branches in the git repository that holds all content files. If you want to be absolutely sure that the production version of the website is exactly the version published to test, then you should make sure the website as created by build tools is stored in git. You can of course also rebuild the website in the production pipeline. It's up to you, Azure doesn't care.
Keep people out of test
The subdomain generated to access the files in the new environment is the production subdomain plus the name of the environment. If you are using a custom domain for the production website, then the generated production subdomain can be found in the DNS of your custom domain. So it is possible for unauthorised people to guess the subdomain for the new environment and view the website.
The only way to prevent unauthorised people to view the website is to introduce authorisation.
Limitations
Azure also supports traffic splitting: having two production environments, one with the new and one with the old version. A percentage of the visits is directed to the new version, the rest to the old. This feature is (in 2025) not available in the free hosting plan.
Most of my projects have a public and a private website based on the same content. I use the default Production environment for the public website, and a second environment for the private website, both with (different) custom subdomains. As the websites are static, the website can be fully tested on a development machine using a local webserver and a test environment is not needed. There are times (e.g., when working on new software versions) that a hosted test environment is required. That is allowed in the free plan, but as there is a limit of 2 custom domains in 2025, the test environment cannot get a custom subdomain and I have to use the generated subdomain instead.