1Z0-1072-25 Question 169
Single answerYou have a compute instance in a private subnet that needs to communicate with your on-premises environment via an IPSec VPN connection. Despite verifying that your route tables and security lists appear correct, connectivity still fails. You suspect an incorrect network security group configuration may be blocking traffic. To accurately diagnose where traffic is being dropped using Network Path Analyzer, which step should you take next?
- A
Run a path analysis in the OCI console, specifying the compute instance� private IP as the source and the on-premises IP address as the destination, ensuring you select the DRG path relevant to the IPSec VPN.
- B
Assign a public IP address to the private instance and then rerun the path analysis to verify connectivity to the on-premises environment over the internet.
- C
Disable all network security groups on both the compute subnet and the DRG route, then re-run the path analysis to see if the route is functional.
- D
Clone the DRG� route table and apply it to the private subnet, then run the path analysis from the on-premises network to the compute instance.
Show answer and explanation
Correct answer: A
Explanation
Network Path Analyzer in OCI helps you verify each hop in the path�security lists, NSGs, and route tables�by specifying a source and a destination. When troubleshooting a VPN path, always choose the DRG as the critical connection point and verify that the correct subnet and IP addresses are used in the analysis. Refer to OCI documentation on �Using Network Path Analyzer for Troubleshooting� to see how to interpret each hop� status and identify exactly where the traffic is dropped.
- A. Correct.
Correct. Using Network Path Analyzer with the compute instance� private IP as source and the on-prem IP as destination allows you to trace exactly where traffic is blocked. Specifying the DRG path (used by the IPSec VPN) ensures that the tool checks NSG and routing configurations along the correct path.
- B. Incorrect.
Incorrect. Assigning a public IP to a private instance and testing over the internet changes the fundamental path and security configuration. This won't isolate the root cause for your IPSec VPN route and may introduce new variables into your test.
- C. Incorrect.
Incorrect. Disabling all NSGs and re-running the test is overly broad and not practical in a production environment. It may momentarily resolve a block but doesn�t help identify the specific NSG rule that might be causing the issue.
- D. Incorrect.
Incorrect. Cloning the DRG� route table and applying it to the subnet does not address whether an NSG rule is causing the block. It could also cause misconfigurations if the original route settings do not match the clone� intent.