Validate the hosted identity separately in a passwordless Queue migration

Source facts

Microsoft’s migration guide configures a developer’s user permissions for local execution and then configures a managed identity for the deployed application. DefaultAzureCredential chooses among supported authentication methods at runtime, allowing local and deployed environments to use different methods. Microsoft Learn

Applicability

Use this guide when an existing application is being migrated from a secret-based Queue Storage connection to the documented passwordless approach.

DSE recommendation

DSE recommends recording the expected local principal and the expected hosted principal as two separate entries in the migration plan. Verify the intended hosted identity association and its required queue permissions before deployment. Ask the application owner to define a small end-to-end message test that can be repeated in both environments. Keep any old connection-secret retirement as a later controlled step after the deployed path has been validated.

Verification

Run the agreed test locally and again in the actual hosting environment. For each run, retain enough configuration evidence to identify the intended principal and target queue without exposing credentials or message content. Investigate a hosted authorization failure as its own finding, and do not infer deployment readiness solely from the developer’s successful local run.

Official references

• Microsoft: Migrate applications to use passwordless authentication with Azure Queue Storage – Azure Storage | Microsoft Learn