After someone deleted platform NSG rules and forced all MI subnet traffic through a firewall without documented exceptions, the Managed Instance lost management connectivity. What should the security engineer restore, and which port applies if a public endpoint is truly required?
Select an answer to reveal the explanation.
Short Explanation
MI subnets have a required NSG/UDR choreography—put it back. If you really must open a public endpoint, it’s TCP 3342 from known sources, not wide-open 1433.
Full Explanation
Managed Instance subnets require documented NSG rules and UDR patterns; deleting platform allowances and forcing all traffic through a firewall without exceptions breaks management connectivity for the lock-telemetry instance. The security engineer must restore the required NSG and UDR pattern. If a public endpoint is truly required, allow only TCP 3342 from known sources—not classic SQL 1433 from the open Internet.
Leaving the stripped NSG and opening TCP 1433 from the Internet fails by concept: it keeps the broken platform posture and uses the wrong public-endpoint port model for MI. Disabling all UDRs permanently and relying solely on Microsoft Entra database authentication fails by concept: Entra auth is Domain 3 identity to the database and does not restore MI subnet networking requirements. Replacing the MI NSG with an Application Gateway WAF policy attached to the MI subnet fails by concept: WAF is an HTTP(S) application edge control, not a substitute for MI platform NSG/UDR choreography.
Exam caveat: remember MI public endpoint uses TCP 3342 when enabled; do not default to 1433 as on Azure SQL Database public listeners. Operational check: restore documented MI NSG/UDR rules, confirm management connectivity returns, and if public access is approved, restrict TCP 3342 to known source ranges and verify 1433 is not the exposed public control.