Azure SQL: private endpoint, Entra auth, and PITR you can actually restore

TL;DR: Lock Azure SQL behind a private endpoint, authenticate apps with Entra managed identity (not SQL logins), and know the point-in-time restore steps before the incident. Create contained Entra users: CREATE USER [app-identity] FROM EXTERNAL PROVIDER, then ALTER ROLE db_datareader ADD MEMBER [app-identity] (and writer as needed). Delete the SQL admin password from your runbooks after Entra works; keep one break-glass SQL login in the vault.

The fix

1. Networking. Private endpoint in the app VNet + deny public access. SQL's firewall defaults to allow-Azure-services; turn that off once the endpoint works.
2. Auth. Create contained Entra users: CREATE USER [app-identity] FROM EXTERNAL PROVIDER, then ALTER ROLE db_datareader ADD MEMBER [app-identity] (and writer as needed). Connection string uses Authentication=Active Directory Managed Identity. Delete the SQL admin password from your runbooks after Entra works; keep one break-glass SQL login in the vault.
3. PITR. Automatic, retention 7-35 days by business criticality. Restore: az sql db restore --dest-name [db]-restored --time "2026-09-25T10:00:00Z". Restores create a NEW database; nothing is overwritten in place.
4. Long-term retention. Weekly/monthly/yearly policies for compliance; PITR alone does not cover "we need last quarter".
5. Failover. Auto-failover group to the paired region for prod; test it. Traps:
6. FROM EXTERNAL PROVIDER must run as the Entra admin of the server; a SQL login cannot create Entra users.
7. Firewall "allow Azure services" left on after adding the private endpoint: the endpoint is then theater.
8. Restoring over the live DB by mistake: restore always targets a new name; rename after verifying. Verify: app connects with managed identity from the VNet; public connection attempts fail; a test PITR restore to a scratch DB succeeds.

When to use this

• This covers exactly what the title says: Azure SQL.
• You are setting this up for the first time, or auditing an existing setup.
• You want the key gotchas in one place before you start.

When not to use this

• You are doing a different workflow with Azure; these steps are specific to the title above.
• You need the full reference docs; this is the short path, not the manual.

Compatibility

• Not pinned to a specific version; follows current Azure behavior.

Proactive workflow skill. Entra auth and restore flow verified against current Azure SQL docs. Evidence: https://learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-overview