Meridian Line's charter-desk assistant, deployed on Model Serving, needs the same third-party API key across dev, staging, and production endpoints, but the security team wants production's key to be rotated independently without touching the dev or staging configurations. How should this be structured?

Structuring credentials as separate secrets (or separate secret scopes) per environment, with each environment's endpoint configuration pointing only at its own secret, is what makes independent rotation possible — changing production's secret value has no effect on what dev or staging endpoints reference, because they point at different secret objects entirely. A single shared secret used by all three endpoints does the opposite of the requirement: rotating it necessarily rotates it everywhere at once, since there is only one secret object being referenced. Embedding an API key in an endpoint's name is not how secrets or endpoint naming work on the platform, and endpoint names aren't a credential storage mechanism at all — this option describes something that isn't a real configuration path. Requiring all three environments to redeploy in lockstep against one rotated secret reintroduces exactly the coupling the security team is trying to eliminate — independent rotation means dev and staging are unaffected by a production rotation, not that all three must move together on a schedule. Exam framing: this extends the secrets-for-credentials point into environment isolation, a natural deployment-sequencing consideration when the same third-party integration exists across dev/staging/production.