The RAG indexer Function’s shared service principal secret must rotate on a schedule without downtime. Which approach fits?
Select an answer to reveal the explanation.
Short Explanation
You can rotate the service principal secret in Azure Key Vault and let consumers fetch the new version automatically, like changing the fleet garage key without locking everyone out. That scheduled handoff keeps your indexer running while workers move to the new credential.
Full Explanation
Rotating the shared service principal secret in Azure Key Vault and having consumers fetch the new version automatically supports scheduled renewal without forcing a hard outage. Key Vault keeps version history, and consumers that retrieve the current enabled version can pick up the replacement after refresh; the old version can be disabled once all workers have moved. This helps keep RAG indexer loads running through the change. A forever-valid password hardcoded in Function app settings fails because it never rotates, remains in configuration, and creates lasting exposure if leaked. Keeping the secret only in a developer laptop’s encrypted notes file bypasses centralized audit and versioning, and makes safe handoff unreliable if staff change or the laptop is unavailable during an overnight run. Publishing the secret to a public municipal wiki exposes it without access control; manual copying risks stale credentials, and wiki history can retain the secret after rotation. Exam caveat: rotation is not complete until every consumer stops using the retired version; cached values or workers outside the Function app may still use it, so a brief overlap of valid secrets can be safer than a hard cutover. Practical check: confirm Key Vault has a new enabled version, the Function retrieves it without 401/403 errors, and indexer success continues; then disable the previous version and check again for residual errors.