1Z0-1072-25 Question 113
Single answerYour organization wants to connect an on-premises data center to multiple spoke Virtual Cloud Networks (VCNs) using a single hub VCN in Oracle Cloud Infrastructure (OCI). The goal is to route on-premises traffic to all spoke VCNs through the hub VCN, avoiding separate IPsec tunnels for each spoke. Which approach should you implement to fulfill this requirement?
- A
Create a Dynamic Routing Gateway, attach it to the hub VCN, configure local peering connections between the hub and spoke VCNs, and set up transit routing by updating both hub and spoke VCN route tables accordingly.
- B
Configure an Internet Gateway on each spoke VCN and create stateful security list rules to allow on-premises traffic to reach the spoke subnets over the public internet.
- C
Establish a VPN Connect (IPsec) attachment between each spoke VCN and the data center, bypassing the need for a hub VCN or local peering.
- D
Deploy a NAT Gateway in the hub VCN to permit on-premises traffic to transit from the hub to each spoke through NAT translation rules.
Show answer and explanation
Correct answer: A
Explanation
Transit routing in Oracle Cloud Infrastructure uses a Dynamic Routing Gateway (DRG) attached to a hub VCN, along with local VCN peering connections to spoke VCNs. Route tables in both the hub and spoke VCNs must be updated to forward on-premises traffic through the DRG and local peering pathways. For more details, refer to the OCI documentation on transit routing (https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/transitrouting.htm).
- A. Correct.
Correct. In a transit routing scenario, you typically attach a DRG to a hub VCN, establish local VCN peering between the hub and each spoke VCN, then configure specific route rules. On-premises traffic arrives via the DRG and is routed to the appropriate spoke VCNs through the hub. The spoke VCNs also need route rules pointing back to the hub through the local peering connections.
- B. Incorrect.
Incorrect. Using an Internet Gateway for on-premises traffic is not a secure or recommended design for private traffic. It exposes your spoke subnets to the public internet, which violates the requirement for a private or secure path and does not leverage transit routing.
- C. Incorrect.
Incorrect. This approach would require a separate IPsec tunnel for each spoke VCN, which is exactly what transit routing aims to avoid. It would be more complex and costlier than using a single hub-and-spoke design with a DRG.
- D. Incorrect.
Incorrect. A NAT Gateway provides address translation for outbound connections to the internet, not private routing between on-premises and peer VCNs. NAT does not solve the requirement to route private on-premises traffic across multiple VCNs.