Secure networking

The correct answer is to use IP Flow Verify to test the specific five-tuple flow and identify which NSG rule is allowing or denying the traffic between the application and database VMs.

This is the best solution because:

1. IP Flow Verify is specifically designed for instant, on-demand testing of connectivity between two points using the five-tuple flow parameters (source IP, source port, destination IP, destination port, and protocol).

2. It provides immediate results showing whether traffic is allowed or denied, and crucially, it identifies the exact security rule (NSG rule name) that is affecting the traffic.

3. The question explicitly asks for the 'fastest way' to troubleshoot a 'specific connectivity issue' with known parameters (source: 10.1.2.15:45678, destination: 10.1.3.20:1433, protocol: TCP), which perfectly matches IP Flow Verify's use case.

4. It requires no setup time or configuration - you simply input the flow parameters and get an instant verdict.

5. It tests at the NSG level, which is where the question suggests the problem likely exists ('The security team has configured NSG rules').

Why the other answers are less suitable:

Connection Monitor is designed for ongoing, continuous monitoring of connectivity over time. While valuable for long-term monitoring and proactive detection, it requires setup and configuration, and doesn't provide the instant, on-demand troubleshooting needed for this immediate issue. It's better suited for ongoing health monitoring rather than quick troubleshooting of a specific known flow.

NSG Flow Logs with Traffic Analytics analyzes historical data and provides insights into traffic patterns over time. This approach requires waiting for logs to be generated, collected, and processed, which can take minutes to hours. It's retrospective rather than immediate, making it too slow for the 'fastest way' requirement. Additionally, correlating timestamps and analyzing historical data is more complex and time-consuming than needed.

Next Hop capability is designed to troubleshoot routing issues by showing the next hop type and IP address for traffic from a VM. While useful for routing problems, the question asks about traffic being blocked by security rules (NSG, Azure Firewall), not routing issues. Next Hop won't identify which security rule is blocking traffic - it only shows routing paths. This is the wrong tool for diagnosing security rule blockages.

The correct answer is that NSG flow logs with version 2 schema support a maximum retention period of 365 days when stored in a Storage Account with a configured retention policy.

Azure Network Watcher NSG flow logs allow you to configure retention policies directly on the flow log resource. When you enable NSG flow logs and store them in an Azure Storage Account, you can set a retention policy that automatically deletes logs older than the specified number of days. The maximum retention period supported for NSG flow logs is 365 days (1 year).

This retention setting is independent of any Storage Account lifecycle management policies you might configure separately. The 365-day limit is a built-in constraint of the NSG flow logs feature itself.

Why the other answers are incorrect:

The option suggesting 90 days with archive tier enabled is incorrect because the archive tier is a Storage Account feature that affects blob access tiers and costs, but it does not change the maximum retention period limit of NSG flow logs, which remains at 365 days.

The option suggesting 180 days is incorrect because this is not the maximum retention period - NSG flow logs support up to 365 days, not 180 days.

The option suggesting 730 days (2 years) with lifecycle management rules is incorrect because while Storage Account lifecycle management can be configured independently to retain or archive data for longer periods, the NSG flow logs feature itself only supports configuring retention up to 365 days. The built-in retention policy of NSG flow logs has a maximum of 365 days regardless of any additional lifecycle management rules you might apply at the Storage Account level.

The correct approach is to configure server-level firewall rules with one rule allowing subnet 10.75.15.0/24 using virtual network rules, one rule allowing the API Management public IP 20.45.78.100, and one rule allowing the partner subnet 165.88.34.0/23, then enable Connection Logging in server parameters for compliance tracking.

This solution is correct because:

1. Virtual Network Rules for Internal Subnet: Using VNet rules for 10.75.15.0/24 provides service endpoint integration, which is the appropriate mechanism for allowing Azure resources within a VNet to access the PostgreSQL server securely.

2. Direct IP Rule for API Management: Adding the API Management public IP (20.45.78.100) as a server-level firewall rule directly addresses the 'connection refused' errors. API Management uses its public IP for outbound connections to backend services, so this IP must be explicitly allowed.

3. Subnet Range for Partner: Allowing the entire partner subnet 165.88.34.0/23 accommodates future growth without requiring configuration changes each time they add new IP addresses, while still maintaining granular source tracking at the subnet level.

4. Connection Logging for Compliance: Enabling Connection Logging in server parameters provides the detailed audit trail required for GDPR compliance, tracking all connection attempts with source information for regulatory purposes.

5. Addresses Root Cause: The scenario states that NSGs allow traffic but connections aren't reaching the database from external sources - this indicates the PostgreSQL server's own firewall is blocking the connections, which is exactly what this solution fixes.

Why the other answers are incorrect:

The second option suggests allowing the entire corporate VNet (10.75.0.0/16) which violates the principle of least privilege and doesn't provide the granular access control needed for compliance. Additionally, Private Link endpoints are unnecessary complexity for this scenario and wouldn't solve the immediate connection issues.

The third option mentions an application gateway rule for translating API Management internal IP, which is incorrect - API Management uses its public IP for outbound connections, not an internal IP that needs translation. Azure Bastion is also irrelevant here as it's for RDP/SSH administrative access to VMs, not database connectivity.

The fourth option incorrectly suggests using private endpoint IP addresses for API Management and introduces Azure Front Door with WAF, which are web application delivery services not applicable to direct database connections. This adds unnecessary complexity and doesn't address the actual firewall configuration needed at the PostgreSQL server level.