A Function must send to Service Bus without storing a connection string in app settings. What authentication approach should the city use?
Select an answer to reveal the explanation.
Short Explanation
You can give the Function a managed identity—a city badge it presents to Service Bus instead of keeping a master key in app settings. With the right data-plane permissions, it can send securely without a connection-string secret.
Full Explanation
A Function that sends to Service Bus should use a managed identity with Azure RBAC data-plane permissions rather than a connection-string secret in app settings. Assign the Function’s system- or user-assigned managed identity a role such as Azure Service Bus Data Sender on the namespace or queue, then use identity-based configuration or SDK authentication. This avoids exposing a shared secret in configuration dumps, reduces rotation effort, and supports municipal security baselines. Embedding a shared access connection string in source control for every environment fails secret hygiene and risks exposure through forks or CI logs. Putting the Service Bus key in a public GitHub gist referenced by the Function exposes the credential even more directly. Disabling authentication so anonymous callers can enqueue civic AI jobs invites abuse, cost attacks, and untrusted workloads on city queues. Exam caveat: managed identity must be enabled on the Function app and its role correctly scoped; local development needs a substitute, such as Azure CLI login, a user identity, or carefully controlled development secrets. Do not replace identity by pasting production keys into repositories. Practical check: remove the connection string from app settings, confirm the Function still enqueues using identity, temporarily deny its role and confirm sending fails, then restore only least-privilege sender rights.