Replace azure-deploy skill managed identity SQL access grant with a script

Summary

Copilot has identified a portion of a skill that is a good candidate for replacement with a script.

The candidate is the grant-managed-identity-SQL-access flow in the azure-deploy skill — load the azd environment, resolve the app's managed-identity name, then run an idempotent CREATE USER / ALTER ROLE against the database. The same flow appears in three files, with a non-idempotent divergent copy.

Candidate description

To let a deployed app reach its database via managed identity, the skill runs a fixed sequence:

1. Load azd env get-values and resolve the managed-identity/app name.
2. Run a single az sql db query with idempotent T-SQL: IF NOT EXISTS (SELECT ... FROM sys.database_principals ...) CREATE USER [<app>] FROM EXTERNAL PROVIDER; then ALTER ROLE db_datareader/db_datawriter/db_ddladmin ADD MEMBER [<app>];.

This is a strong script candidate because it is:

• Already partly shipped as scripts — sql-managed-identity.md contains a full idempotent grant-sql-access.sh / .ps1 (L80–L164). The problem is the non-idempotent duplicates that should call the one canonical script instead.
• A deterministic query-Azure-then-set sequence — resolve a name, run one parameterized query; no branching to run.
• Idempotent and safe to re-run when written once correctly, removing the risk of the agent pasting a non-idempotent variant that fails on the second run.

Sketch — grant-sql-access.{sh,ps1}:

• Input: --server, --database, --identity-name (or resolve from azd env), --roles (default db_datareader,db_datawriter,db_ddladmin).
• Output: a summary of which principal was created/confirmed and which roles were added, so the agent need not re-query to confirm.

Which roles to grant (read-only vs. read/write/migrations) is a deployment decision that stays a script parameter plus prose guidance. The first-time requirement that the caller be the Entra SQL admin stays prose.

Note — cross-skill overlap: This is the same query-Azure-then-feed-a-value-into-a-grant pattern already tracked for the azure-prepare skill (#2500) and the azure-validate skill (#2504). The three skills may be able to share the same script family rather than each authoring its own.

Affected file and lines

• references/recipes/azd/sql-managed-identity.md — Quick Grant + idempotent grant-sql-access script (L15–L164)
• references/recipes/azd/post-deployment.md — grant SQL access quick template (L36–L56)
• references/recipes/azd/sql-entra-auth.md — non-idempotent managed-identity grant (L65–L73)

Next steps

1. Evaluate the candidate — confirm the steps are stable and parameterizable, and that the script captures everything the skill needs.
2. Create both a bash and a PowerShell version of the script so the skill works across platforms.
3. Run integration tests to verify the scripts behave correctly and the skill still completes end-to-end.

Background Information

Why replace regular steps with scripts

Replacing a regular, well-defined series of steps with a script can:

• Reduce token usage — the skill no longer needs to spell out each command and parse large command output inline; the agent invokes one script and reads a compact result.
• Improve reliability — the logic is written and tested once, instead of being re-derived by the agent on every run.
• Improve determinism — the same inputs always produce the same steps and output, removing run-to-run variation.
• Improve speed of execution — a single script call replaces multiple round-trips of command generation, execution, and large-output parsing.

Authoring notes for the scripts

• Reference scripts with markdown links, not just a bare path to the script file.
• Include examples in the skill showing how to run each script (sample invocation with arguments).
• Briefly explain what each script does where it is referenced.
• The script output should explain what it did, so the agent and user can understand the result without re-inspecting raw command output.