Networking practice questions

Dynamic Routing Gateway

Why it fails: A Dynamic Routing Gateway is designed to facilitate private connectivity between a Virtual Cloud Network and an on-premises data centre via IPsec VPN or FastConnect, rather than public internet access. It is tempting to choose this component because it handles routing traffic outside the VCN boundaries, but it is not automatically generated by the VCN Internet Connectivity wizard because public internet traffic relies specifically on an Internet Gateway instead.

Local Peering Gateway

Why it fails: Local Peering Gateways are designed to enable VCN peering between two distinct Virtual Cloud Networks within the same region, allowing private communication without traversing the public internet. This makes them tempting because they deal with connectivity routing, but they fail this scenario because they facilitate inter-VCN traffic rather than establishing an outbound route to the public internet for a single VCN. A Local Peering Gateway would only be deployed when you need to connect separate Virtual Cloud Networks privately, not when setting up a newly wizard-provisioned VCN that requires direct internet access via an Internet Gateway.

FastConnect Virtual Circuit

Why it fails: A FastConnect Virtual Circuit provides a dedicated, private connection between your on-premises data centre and Oracle Cloud Infrastructure rather than traversing the public internet. While this option appears relevant because it establishes external network connectivity, it requires dedicated physical infrastructure setup with Oracle or a network partner. Conversely, the VCN Wizard automatically deploys internet-accessible resources via an Internet Gateway and NAT Gateway for public and private subnets, meaning a FastConnect circuit is only chosen when bypassing the public internet for hybrid cloud architectures.

Attach a NAT Gateway to the Load Balancer subnet.

Why it fails: Attaching a NAT Gateway to the subnet fails because it manages outbound routing and source Network Address Translation for traffic originating from backend servers toward the internet, rather than processing inbound proxy headers or preserving client IP addresses at the load balancing layer. This is tempting because network administrators frequently configure NAT Gateways to handle IP routing and address translation requirements for resources within private subnets. Such a gateway is the correct choice when instances without public IP addresses require outbound internet access to download software updates or communicate with external APIs, which is entirely distinct from ingress load balancer traffic preservation.

Switch the load balancer shape to asymmetric routing mode.

Why it fails: Asymmetric routing changes the return path of packet flows by bypassing the load balancer for outbound server responses, which breaks bidirectional TCP session integrity rather than modifying packet headers to retain client IP addresses. Administrators often confuse this routing optimisation feature with header manipulation because both deal with packet flow adjustments at the networking layer. It would be the correct choice if you needed to bypass the load balancer for return traffic to reduce latency and maximise throughput when handling heavy outbound workloads on backend servers.

Configure an Internet Gateway route on the backend servers.

Why it fails: Routing configuration on backend servers dictates the exit path for outbound packets rather than modifying or intercepting HTTP headers or proxy layers to inject original client IP addresses. Administrators often confuse routing with proxy protocol handling because Internet Gateway routes are essential for enabling backend servers to initiate outbound internet communication or receive return traffic destined for external networks. However, modifying routing tables has no effect on preserving inbound TCP connection attributes or adding `X-Forwarded-For` headers at the load balancing tier, rendering it completely ineffective for client IP preservation.

10.0.0.0/22

Why it fails: A /22 provides 1,024 addresses, but OCI reserves the first two and last address in each subnet, leaving 1,021 usable — far exceeding the 500 required, so a smaller block suffices. It is tempting because /22 comfortably covers 500 hosts, and would be correct if the requirement were roughly 1,000 usable addresses.

10.0.1.0/24

Why it fails: A /24 yields 256 addresses, and after OCI reserves three, only 253 usable IPs remain — short of the 500 required. It is tempting because /24 is the conventional default subnet size, and would be correct for a subnet needing up to roughly 250 usable addresses.

10.0.0.0/25

Why it fails: Providing a /25 CIDR block yields only 126 usable IP addresses after accounting for the five reserved addresses managed by Oracle Cloud Infrastructure, falling significantly short of the requirement to hold up to 500 usable addresses. This option appears tempting because administrators often miscalculate prefix lengths by confusing bits with host counts or underestimating network sizing formulas. A /25 block would be the correct choice in a scenario requiring a smaller segment, such as isolating a dedicated database tier or a management subnet restricted to a maximum of 120 compute instances.

OCI route tables only support 0.0.0.0/0 and cannot target individual IP addresses.

Why it fails: Oracle Cloud Infrastructure route tables fully support destination CIDR blocks more specific than default routes, allowing an administrator to direct traffic destined for the specific address 10.0.1.50/32 to a private IP target rather than routing everything to an Internet Gateway. This statement appears plausible because administrators frequently configure a single default route of 0.0.0.0/0 to an Internet Gateway for standard public subnet internet access, making it tempting to assume granular host routes are unsupported when designing custom security appliances.

Use a Service Gateway to route specific IP addresses.

Why it fails: A Service Gateway is designed exclusively to route traffic destined for Oracle Cloud Infrastructure public services, such as Object Storage, privately without traversing the public internet. It cannot direct general traffic or specific private IP addresses, such as `10.0.1.50/32`, to a virtual appliance VNIC. This option is tempting because architects frequently utilise route tables to direct subset traffic away from default internet paths, making a dedicated gateway appear relevant for targeted routing policies.

Set the Internet Gateway as the target for 10.0.1.50/32 and the firewall appliance as the target for 0.0.0.0/0.

Why it fails: Routing traffic destined for 10.0.1.50/32 to the Internet Gateway while sending all remaining traffic through the firewall appliance reverses the routing logic required by the scenario, directing specific internal or targeted traffic directly to the public internet instead of inspecting it. This configuration is tempting because it employs standard default routing structures, and it would be the correct choice if the objective were to bypass security appliances for general internet bound traffic while routing specific host traffic outwards through the gateway.

HTTP (unencrypted)

Why it fails: Selecting this protocol would send unencrypted traffic from the load balancer to the backend servers, which directly violates the requirement that backend traffic must be encrypted using HTTPS. This setting is tempting because it is commonly used when SSL termination occurs exclusively at the load balancer edge and internal communication to backend web servers can remain plain text HTTP within a trusted private subnet.

DNS

Why it fails: DNS operates at the application layer to translate human-readable domain names into IP addresses rather than handling network traffic transport or backend communication protocols. This option is tempting because administrators frequently configure domain routing alongside load balancer deployment, and it would be the correct choice if you needed to resolve hostnames to IP addresses for client traffic routing prior to reaching the load balancer. However, it fails in this scenario because backend sets require layer-7 protocols like HTTP or HTTPS to forward encrypted requests to backend servers, not name resolution services.

ICMP

Why it fails: Internet Control Message Protocol operates at Layer 3 of the OSI model to handle network diagnostics and error reporting, such as processing ping requests, whereas a backend set protocol requires a Layer 7 application protocol to route HTTP and HTTPS requests to backend servers. This option might seem tempting if you confuse network-layer reachability testing with application-layer load balancing, and it would be the correct choice when troubleshooting basic IP connectivity or routing paths using diagnostic utilities rather than configuring web traffic distribution.

OCI Compartment quota limits

Why it fails: Compartment quota limits govern the maximum resource consumption allowed within a specific OCI compartment, functioning as a governance mechanism rather than a traffic routing engine. While these limits are essential for managing cloud expenditure and preventing unauthorised resource sprawl, they lack the capability to inspect DNS queries or manipulate traffic flow. Traffic Management Steering Policies instead rely on health checks, geolocation, and load balancing weights to determine routing, whereas quotas are strictly administrative constraints used to enforce budgetary or organisational boundaries.

SQL query performance metrics

Why it fails: SQL query performance metrics are not a valid input for OCI Traffic Management Steering Policies, as these policies operate exclusively at the DNS resolution layer based on health checks, geolocation, or weighted load balancing. This option appears relevant because database administrators frequently monitor query execution times to optimise application latency. While such metrics are vital for tuning database performance within an OCI Autonomous Database or a managed SQL instance, they exist entirely outside the scope of the DNS routing logic managed by Traffic Management.

/24

Why it fails: While /24 is valid, it is not the smallest; /30 is smaller.

/32

Why it fails: /32 represents a single host IP and is not valid for a VCN.

/8

Why it fails: An IPv4 CIDR block of /8 is far too large for a standard Oracle Cloud Infrastructure Virtual Cloud Network, which restricts the maximum supported size to a /16 to prevent excessive address exhaustion within a single network boundary. However, this mask size is tempting because enterprise network administrators frequently utilise /8 prefixes for massive, legacy on-premises private networks adhering to RFC 1918. Such a block would only be the correct choice if you were designing an exceptionally large contiguous private internetwork spanning multiple global datacentres rather than an individual OCI VCN.

BYOIP prefixes can be assigned directly to private subnet VNICs without public IPs.

Why it fails: BYOIP addresses are public IPs and follow standard OCI public IP assignment rules.

BYOIP is only supported for private IP addresses within an on-premises datacenter.

Why it fails: BYOIP specifically applies to public IPv4 addresses.

OCI automatically transfers ownership of the IP block to Oracle permanently.

Why it fails: You retain ownership of your IP prefix; Oracle only advertises/uses it on your behalf.

It returns a 504 Gateway Timeout error to the DNS client.

Why it fails: OCI Traffic Management operates at the DNS layer rather than acting as a reverse proxy or application gateway, meaning it resolves names to IP addresses instead of handling HTTP requests and generating gateway timeout responses. This option is tempting because a 504 error is the standard HTTP status code for upstream server failures behind a load balancer when a backend endpoint stops responding. However, it would only be applicable if Traffic Management functioned as an HTTP proxy capable of intercepting web traffic and returning application-layer error codes to clients.

It shuts down the VCN associated with the endpoint.

Why it fails: Virtual Cloud Networks operate independently at the infrastructure layer for IP routing, meaning DNS steering cannot automatically terminate network boundaries based on endpoint health. This option is tempting because VCNs serve as the fundamental foundational network constructs for OCI resources, and administrators often conflate routing control with network provisioning. Such automated infrastructure teardown would only apply if you were orchestrating custom cloud-native event-driven automation via OCI Events combined with Functions to modify infrastructure lifecycle states following a health check failure.

It continues to send traffic to the failed endpoint until manual intervention occurs.

Why it fails: OCI Traffic Management automatically removes unhealthy endpoints from the answer pool and ceases returning their IP addresses in DNS responses once health checks fail, rendering static continuation impossible. This behaviour mimics manual static routing configurations where administrators wish to pin traffic to a designated primary server despite downstream failures. That static fallback approach is useful exclusively during scheduled maintenance windows when operators intentionally bypass automated checks to force routing to a specific node for diagnostic purposes.

FastConnect does not support BGP dynamic routing when redundancy is enabled.

Why it fails: BGP is fully supported and recommended for redundant FastConnect setups.

FastConnect redundant circuits must share the exact same physical cross-connect port.

Why it fails: Redundant circuits should utilize separate physical ports or diverse provider paths.

FastConnect automatically provides 100% SLA without requiring redundant circuits on customer end.

Why it fails: Customers must implement redundant circuits on their end to achieve high availability SLAs.

Recreate the Customer-Premises Equipment (CPE) object.

Why it fails: The CPE object describes the on-premises VPN endpoint's public IP, which is unchanged by adding a VCN subnet. Static routing requires the new 10.0.5.0/24 prefix to be added to the IPSec connection's static routes so traffic is tunnelled; recreating the CPE alters nothing relevant.

Switch the VPN from static routing to a NAT Gateway.

Why it fails: A NAT Gateway provides outbound internet connectivity for private subnets within a VCN, allowing instances to reach public endpoints while remaining shielded from incoming connections. It is tempting because engineers often confuse internal routing mechanisms with outbound translation tools when addressing connectivity blocks. However, implementing a NAT Gateway will not resolve this scenario because it cannot establish bi-directional tunnelling or advertise new VCN CIDR blocks across an existing site-to-site IPSec VPN tunnel to on-premises networks.

Update the VCN Internet Gateway routing table.

Why it fails: Routing traffic for an IPSec VPN tunnel relies on Dynamic Routing Gateways and local/remote static routes rather than the Internet Gateway. Updating the VCN Internet Gateway routing table is tempting because administrators frequently associate routing table modifications with adding new subnets and resolving connectivity issues. However, an Internet Gateway is strictly used to direct traffic between a VCN and the public internet, meaning any modifications to its routing table affect internet-bound traffic rather than hybrid tunnel traffic traversing an IPSec VPN connection.

Oracle Cloud Infrastructure Public Load Balancer with SSL termination

Why it fails: An Oracle Cloud Infrastructure Public Load Balancer operates at layers 4 and 7 to distribute incoming internet traffic across backend servers, which completely fails the requirement for a dedicated physical circuit bypassing the public internet from an on-premises datacenter. This option is tempting because it does handle encryption via SSL termination and manages high-throughput connections, making it the correct choice when you need to distribute public web application traffic across multiple backend instances in a Virtual Cloud Network.

Site-to-Site VPN over Public Internet

Why it fails: A Site-to-Site VPN traverses the public internet, directly contradicting the requirement to bypass it, and IPsec tunnels cannot sustain 10 Gbps. It is tempting because VPN is the standard encrypted on-premises-to-cloud link, and would be correct where budget is limited and internet transport is acceptable.

Remote Peering Connection (RPC)

Why it fails: An RPC is used to peer two VCNs across different regions, not for connecting an on-premises datacenter.

A VCN can span multiple OCI geographic regions simultaneously.

Why it fails: Virtual Cloud Networks are strictly regional software-defined networks that operate within a single Oracle Cloud Infrastructure region and cannot extend across geographical boundaries. This statement appears plausible because administrators frequently require interconnected workloads spanning multiple locations to achieve high availability and disaster recovery architectures. To satisfy such multi-region connectivity requirements in OCI, cloud architects must provision separate VCNs in each distinct region and link them using Local Peering Gateways or Remote Peering Connections via Dynamic Routing Gateways, rather than attempting to span a single VCN globally.

The maximum size of a VCN CIDR block is /8.

Why it fails: Oracle Cloud Infrastructure enforces a strict /16 upper limit for a Virtual Cloud Network CIDR block, meaning a /8 block exceeds the maximum permissible address space. Network architects often assume standard cloud enterprise scales apply uniformly and therefore confuse VCN sizing limits with the /8 allocations commonly permitted in traditional on-premises data centres or alternative hyper-scale providers like AWS VPCs. A /8 range would theoretically be correct if you needed to provision sixteen million private IP addresses within a single flat network boundary, but OCI architecture mandates segmenting massive enterprise topologies across multiple smaller VCNs.

A VCN is restricted to a single Availability Domain by default.

Why it fails: Virtual Cloud Networks span multiple Availability Domains by default, operating as regional software-defined networks rather than being constrained to a single Availability Domain. This statement seems plausible because Oracle Cloud Infrastructure architectures often partition resources across isolated Availability Domains for fault tolerance, leading administrators to incorrectly assume that network boundaries follow the same physical isolation. It would correctly describe subnet configuration if discussing regional subnets versus Availability Domain-specific subnets, where subnets can indeed be restricted to a single Availability Domain during creation.

Dynamic Routing Gateway DNS proxy

Why it fails: Dynamic Routing Gateway DNS proxy facilitates the forwarding of DNS queries from an on-premises network across a DRG to Oracle Cloud Infrastructure resolver endpoints, rather than creating a private DNS zone directly inside a Virtual Cloud Network for internal instance resolution. Although this feature manages hybrid cloud name resolution paths across a network transit boundary, it fails to provide the isolated domain ownership and internal record management required for a local application namespace.

Internet Gateway DNS forwarding rules

Why it fails: Internet Gateway forwarding rules manage outbound traffic routing from a VCN to the public internet rather than resolving internal private DNS records between VCN instances. Administrators often confuse this feature with private zone configuration because it deals with network-level DNS traffic management. It would be the correct choice when you need to forward DNS queries originating from your VCN instances to external or on-premises resolvers via an Internet Gateway, rather than hosting internal private zones.

Public DNS Zone with restricted Access Control Lists

Why it fails: Public DNS zones are resolvable from the public internet, which violates the requirement for internal-only resolution.

Local Peering Gateway (LPG) access control lists

Why it fails: Local Peering Gateways facilitate traffic routing between two distinct Virtual Cloud Networks rather than managing intra-VCN or cross-subnet security boundaries. This option appears appealing because it involves access control capabilities designed to restrict network flows. However, it would be the correct choice exclusively when establishing secure, transitive routing and traffic filtering between two peered VCNs across the Oracle Cloud Infrastructure backbone, rather than enforcing fine-grained instance-level isolation within the same network topology.

Security Lists associated with the database subnet

Why it fails: Security lists apply at the subnet boundary, so rules cannot reference application instances that may sit in other subnets. NSGs let rules reference instances by NSG membership regardless of subnet. Security lists are correct when you need broad subnet-level filtering applied to every VNIC in that subnet.

Dynamic Routing Gateway (DRG) security policies

Why it fails: A DRG routes traffic between a VCN and on-premises or remote networks; it enforces no instance-level security policy. NSGs provide that granular, membership-based control. DRG security policies are correct when you need to filter traffic traversing a DRG attachment between networks.

The route table on the VCN subnet does not have a route to 0.0.0.0/0.

Why it fails: Routing Internet traffic out of the VCN via an Internet Gateway requires a default route to `0.0.0.0/0`, which would be the correct configuration if you needed instances to reach public endpoints or handle outbound internet traffic. However, this is irrelevant to the BGP peering state; BGP sessions operate at Layer 3 to exchange internal routing information between your on-premises routers and the Oracle Cloud Infrastructure Dynamic Routing Gateway. A missing VCN subnet route prevents packet delivery within the network fabric rather than causing an 'Idle' BGP neighbour state, which typically stems from layer-2 encapsulation, incorrect ASN configurations, or missing physical cross-connect parameters.

The Security List on the DRG attachment blocks ICMP traffic.

Why it fails: Security lists operate at the subnet level to filter data plane traffic, whereas a Border Gateway Protocol 'Idle' state indicates a control plane failure occurring long before packet filtering takes effect. While security lists are indeed used to control inbound and outbound traffic, adjusting them would only be necessary if BGP peers were established and traffic was being dropped. In this scenario, the peering session has not even initialised due to misconfigured virtual circuit parameters or missing provider-side configurations.

The public subnet has an incorrect Internet Gateway route.

Why it fails: An Internet Gateway facilitates outbound traffic to the public internet for resources residing within a public subnet, making this option tempting when troubleshooting connectivity issues. However, it fails in this scenario because a FastConnect dedicated circuit relies on private peering via Dynamic Routing Gateways and Border Gateway Protocol rather than public internet paths, meaning internet gateway routing misconfigurations have no impact on establishing a BGP peer state that remains stuck in the 'Idle' phase.

NAT Gateway

Why it fails: NAT Gateways facilitate outbound internet access for private resources within a single VCN, but they lack the routing capabilities required to bridge on-premises traffic across multiple VCNs or regions. While they effectively enable private instances to initiate connections to the public internet without exposing them to inbound requests, they do not function as a transit hub. This component is designed for egress traffic management rather than the multi-region, multi-VCN connectivity architecture demanded by the scenario.

Local Peering Gateway (LPG)

Why it fails: Local Peering Gateways facilitate connectivity exclusively between two VCNs within the same region, rendering them incapable of supporting cross-region traffic or integrating with on-premises FastConnect circuits. This option appears relevant because it serves as a standard mechanism for routing traffic between peered VCNs within a single OCI region. However, it lacks the transit routing capabilities and regional reach required to aggregate multiple VCNs across different geographic locations into a single, unified hub architecture connected to an on-premises datacenter.

Internet Gateway

Why it fails: An Internet Gateway provides public connectivity between a VCN and the public internet, meaning it lacks the private routing capabilities required to bridge on-premises infrastructure with multiple regional VCNs. While it is the standard mechanism for enabling external traffic flow for resources with public IP addresses, it cannot facilitate the private, dedicated transit routing necessary for a hybrid cloud architecture. Consequently, it fails to provide the private connectivity backbone required to link disparate OCI regions through a single dedicated connection.

A NAT Gateway configured with DNS proxy settings

Why it fails: NAT Gateways facilitate outbound internet connectivity for private instances and do not possess DNS resolution capabilities or the ability to forward queries to on-premises resolvers. This option appears relevant because administrators often conflate general network traffic routing with DNS traffic management. While a NAT Gateway is essential when instances require internet access for software updates or external API calls, it lacks the functional integration with the OCI DNS Resolver required to bridge name resolution requests between a VCN and an external datacenter.

A public DNS zone for your on-premises domain

Why it fails: Public DNS zones are globally resolvable and intended for internet-facing services, whereas resolving private on-premises hostnames requires internal name resolution. Configuring a public zone exposes your internal infrastructure to the public internet, creating significant security risks. This option is tempting because it involves DNS zone management, which is the correct domain for hostname resolution; however, you must use OCI DNS Private Views and Resolver endpoints to bridge internal OCI VCN traffic with on-premises networks securely, rather than publishing private records to the public internet.

An Internet Gateway with custom host file mappings

Why it fails: An Internet Gateway forwards traffic to the public internet and performs no name resolution; host file mappings are local to each instance. Internet Gateways are correct when instances need outbound public connectivity, not on-premises DNS forwarding.

Dynamic Routing Gateway

Why it fails: A Dynamic Routing Gateway connects a VCN to on-premises networks or other VCNs, carrying traffic over IPSec or FastConnect, not to Oracle services. Object Storage without public internet requires a Service Gateway, which routes traffic across the Oracle network backbone to the region's service CIDR.

Internet Gateway

Why it fails: An Internet Gateway routes traffic to and from the public internet, so Object Storage access would traverse public endpoints rather than the Oracle network. It is tempting as the standard egress path, but private service access requires a Service Gateway with a service CIDR route.

NAT Gateway

Why it fails: A NAT Gateway provides outbound internet access from private subnets, so Object Storage traffic would still leave via public IP addresses. It is tempting because it keeps instances private, but private Oracle service access requires a Service Gateway instead.