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

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:

- `FROM EXTERNAL PROVIDER` must run as the Entra admin of the server; a SQL login cannot create Entra users.
- Firewall "allow Azure services" left on after adding the private endpoint: the endpoint is then theater.
- 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.