1Z0-1072-25 Question 84
Single answerYou have created two Virtual Cloud Networks (VCNs) in the same region for your internal application. The first VCN hosts application servers in a private subnet, while the second VCN contains supporting microservices in another private subnet. You set up Local Peering Gateways in both VCNs and established a valid local peering. After adding the necessary route rules, instances in the second VCN still cannot access the application servers in the first VCN. Which additional step do you need to perform to ensure connectivity?
- A
Create a new NAT Gateway in both VCNs to facilitate private subnet traffic
- B
Add a Service Gateway in the first VCN to route traffic to the second VCN
- C
Configure the security rules (Security Lists or Network Security Groups) in the first VCN to allow traffic from the second VCN� CIDR
- D
Attach a Dynamic Routing Gateway (DRG) to both VCNs and update the route tables accordingly
Show answer and explanation
Correct answer: C
Explanation
In local VCN peering setups, traffic flow is controlled by route tables and security rules. Even if the local peering is established and route tables are configured correctly, you must still grant access through Security Lists or Network Security Groups by specifying the peered VCN's CIDR block. Refer to Oracle documentation under 'VCN Peering' for detailed guidance on setting up local peering gateways and configuring corresponding security rules.
- A. Incorrect.
Option 1: NAT Gateway is used typically for egress to the internet from private subnets, not for traffic flowing between two locally peered VCNs. This does not solve the connectivity issue here.
- B. Incorrect.
Option 2: A Service Gateway allows access to Oracle services such as Object Storage. It does not enable VCN-to-VCN traffic. Thus, it will not help with the cross-VCN connectivity issue.
- C. Correct.
Option 3: Correct. Even if the local peering is established and routes are in place, you must also configure the security rules to allow traffic. By updating Security Lists or Network Security Groups with an ingress rule for the second VCN� CIDR block, the instances in the second VCN can successfully communicate with the application servers in the first VCN.
- D. Incorrect.
Option 4: A Dynamic Routing Gateway (DRG) is used for connecting your VCN to on-premises environments or other external networks (e.g., via IPSec VPN or FastConnect). DRG is not required for local peering within the same region.