Staging identities must not read production secrets for the courts assistant. What Key Vault design fits?

Use separate Key Vaults per environment so staging identities can access only the staging vault, while production secrets for the courts assistant remain in a vault accessible to production identities. This creates a clear environment boundary; network rules, diagnostics, and purge protections can also differ by environment. Using one shared Key Vault where staging and production identities both have full secret access fails isolation: a staging bug or leaked staging principal could expose production courts secrets. Copying production secrets into staging app settings as plaintext for convenience fails confidentiality and creates unmanaged duplicates outside Key Vault rotation. Granting staging the same Key Vault Administrator role used in production violates least privilege and gives staging excessive access; that role is never appropriate for staging workloads. Exam caveat: separate vaults are stronger than relying on secret-name conventions such as prod- and staging- in one vault, where RBAC mistakes are easier; use separate managed identities too. Non-secret configuration can still use App Configuration labels, but staging must not be able to read production secrets. Practical check: attempt a secret Get against the production courts vault using a staging identity and confirm it returns 403; verify staging apps use only staging vault URIs and that no staging principal has production Secrets User or Administrator access.