Multicloud And Hybrid practice questions

1500 bytes

Why it fails: 1500 bytes is standard Ethernet, but FastConnect supports larger jumbo frames.

576 bytes

Why it fails: 576 bytes is the minimum IPv4 reassembly buffer size.

65535 bytes

Why it fails: 65535 bytes exceeds standard physical interface limits for FastConnect.

Local Peering Gateway

Why it fails: Local Peering Gateways are for VCN-to-VCN peering.

Customer-Premises Equipment (CPE) object

Why it fails: CPE objects are specifically required for IPSec VPN connections, not FastConnect.

Internet Gateway

Why it fails: Internet Gateways are for internet connectivity, not FastConnect.

Peer an AWS VPC directly to an OCI VCN using Local Peering Gateways.

Why it fails: Local Peering Gateways only connect VCNs within the same OCI region.

Attach an AWS Elastic IP directly to the OCI Autonomous Database.

Why it fails: AWS Elastic IPs cannot be attached to OCI resources.

Use OCI Object Storage pre-authenticated requests over HTTPS.

Why it fails: Pre-authenticated requests use HTTPS over the public internet, which does not provide private network connectivity for application servers.

Yes, Oracle and Microsoft automatically handle TLS 1.3 encryption for all packets.

Why it fails: TLS is an application-layer protocol and is not automatically applied to all network traffic.

Yes, all traffic is encrypted using MACsec by default.

Why it fails: MACsec is not enabled by default on standard interconnect circuits.

No, and encryption is strictly prohibited by Oracle security policies.

Why it fails: Customers are encouraged to apply encryption over hybrid links when required.

It requires public IP addresses on all Azure Virtual Machines for cross-cloud routing.

Why it fails: Cross-cloud routing works entirely over private IP addresses.

It requires the customer to pay standard OCI and Azure egress data transfer fees across the interconnect.

Why it fails: Data transfer fees (egress) are waived or structured specifically, with no standard internet egress charges applied between connected regions.

It is available in every OCI region globally without exception.

Why it fails: The interconnect is only available in specific partnered regions (e.g., Ashburn, London, etc.).

OCI Web Application Firewall (WAF)

Why it fails: WAF is an application-security service and is not required for network connectivity.

Customer-Premises Equipment (CPE) object

Why it fails: CPE objects are only required for IPSec VPN connections, not FastConnect.

Running Ophalmic routing daemons on OCI compute instances.

Why it fails: This is a distractor and not a valid OCI feature.

Enabling OCI Bastion service across all VPN subnets.

Why it fails: Bastion is for administrative access, not VPN high availability.

Attaching an Internet Gateway directly to the VPN tunnel endpoints.

Why it fails: Internet Gateways do not manage VPN tunnel endpoints.

Modifying the OCI tenancy tenancy home region to reroute physical fiber cables.

Why it fails: A tenancy home region is an IAM and resource-placement construct; changing it cannot reroute physical fibre, which is provisioned by the FastConnect provider. It is tempting because home region appears in tenancy settings, and it would be correct when relocating identity and regional service metadata, not for diagnosing circuit latency.

Rebooting the OCI IAM service to reset global routing tables.

Why it fails: OCI IAM is an identity and authorisation service with no role in global routing tables, so rebooting it cannot affect FastConnect paths. It is tempting because IAM outages cause authentication failures that look like connectivity problems, and it would be correct when troubleshooting sign-in or policy evaluation errors.

Whether the customer wants to route FastConnect traffic over the public internet for cost savings.

Why it fails: FastConnect never routes over the public internet in either model.

Whether Oracle requires root administrator access to the customer's on-premises firewall.

Why it fails: Oracle never requires or requests root access to on-premises customer firewalls.

Whether the Virtual Cloud Network uses IPv6 or IPv4 addressing.

Why it fails: IP version does not dictate the choice between Colocation and Provider FastConnect models.

The OCI console password of the administrator who created the VPN.

Why it fails: Console passwords are irrelevant to IPSec tunnel establishment.

The Oracle Cloud Infrastructure region home datacenter geographic coordinates.

Why it fails: Geographic coordinates have no impact on IPSec VPN configuration.

Create a local peering gateway on the VCN and peer it with the FastConnect virtual circuit.

Why it fails: FastConnect circuits cannot be peered directly with Local Peering Gateways.

Deploy an OCI DRG and configure static routes pointing to the Object Storage service endpoints.

Why it fails: DRGs are used for private peering, and public peering bypasses the DRG altogether, using a virtual circuit directly attached to the VCN.

Attach a NAT Gateway to the VCN and configure default routes pointing traffic to the FastConnect circuit.

Why it fails: NAT Gateways do not handle inbound public peering traffic for on-premises connectivity.

Attach an Internet Gateway to each VPN connection to translate overlapping subnets.

Why it fails: Internet Gateways are not used for Site-to-Site VPN routing.

Deploy separate OCI Dynamic Routing Gateways (DRGs) for each branch office and use Local Peering Gateways.

Why it fails: You can only attach one DRG per VCN, and LPGs cannot resolve overlapping IP ranges.

Enable OCI Service Gateway to automatically perform NAT on overlapping customer networks.

Why it fails: Service Gateways only handle traffic to Oracle services, not on-premises overlapping subnets.

Enable Equal-Cost Multi-Path (ECMP) routing on the DRG to split packets evenly across FastConnect and VPN.

Why it fails: ECMP across FastConnect and VPN is not supported due to vastly different bandwidth and latency profiles.

Configure identical metric values for both FastConnect and VPN routes within a single DRG route table to load-balance traffic.

Why it fails: Load balancing between FastConnect and VPN can cause asymmetric routing issues and packet drops due to differing latency and MTU sizes.

Attach both the FastConnect virtual circuit and the VPN tunnel to the default VCN route table directly, bypassing the DRG.

Why it fails: FastConnect and VPN attachments must connect through a DRG; they cannot attach directly to the VCN route table.

FastConnect public internet gateway model

Why it fails: FastConnect provides dedicated private peering or public peering over a partner or colocated cross-connect; it does not offer a public internet gateway deployment model. Traffic traverses a private dedicated circuit, not the internet. This tempts those confusing FastConnect with site-to-site VPN over the internet, which is the correct choice when a dedicated circuit is unavailable.

FastConnect IPsec tunnel overlay model

Why it fails: FastConnect offers private peering and public peering over a dedicated circuit; IPsec overlays belong to site-to-site VPN, not FastConnect. FastConnect does not encapsulate traffic in IPsec tunnels. This tempts those wanting encryption over the dedicated link, but IPsec VPN is the correct choice when encryption over the internet is required.

FastConnect satellite uplink model

Why it fails: FastConnect supports dedicated private peering and public peering via cross-connect or partner, not satellite uplinks. Satellite connectivity is a separate transport outside FastConnect's documented deployment models. This tempts architects seeking connectivity to remote or offshore sites, but FastConnect requires terrestrial fibre cross-connects at Oracle or partner locations.

Attach an Internet Gateway to the Azure VNet to route private interconnect packets.

Why it fails: Interconnect traffic is private and does not traverse an Internet Gateway.

Configure an OCI Local Peering Gateway to bridge the Azure and OCI subnets.

Why it fails: Local Peering Gateways cannot connect to Azure VNets.

IPSec VPN over the public internet between OCI and Azure

Why it fails: An IPSec VPN over the public internet would introduce unpredictable latency and jitter because traffic traverses public network paths. Although it is private via encryption, it does not meet the low-latency requirement and does not leverage the existing FastConnect circuit as the transport, making it unsuitable for a latency-sensitive trading application.

Azure ExpressRoute Global Reach with OCI FastConnect

Why it fails: Azure ExpressRoute Global Reach connects ExpressRoute circuits to each other, but it does not directly integrate with OCI FastConnect. OCI's supported method for cross-cloud private connectivity to Azure is OCI-Azure Interconnect, not Global Reach, so this option would not establish the required OCI-to-Azure path.

OCI Remote Peering Connection between OCI and Azure VNets

Why it fails: Remote Peering Connection (RPC) is used to peer VCNs across OCI regions within the OCI network, not to connect to other cloud providers. It cannot establish connectivity to Azure, so it fails to address the multicloud requirement. Using it would not provide any path to Azure resources.

Site-to-Site VPN with BGP dynamic routing and the on-premises CPE as the initiator

Why it fails: BGP dynamic routing is valid, but having the on-premises CPE as the initiator does not satisfy the requirement that OCI initiates. Additionally, BGP may not be required if static routing is sufficient. This option fails to meet the initiation requirement and adds unnecessary complexity.

Site-to-Site VPN with static routing and the on-premises CPE as the initiator

Why it fails: Static routing requires manual route configuration and does not support dynamic failover. Having the on-premises CPE as the initiator contradicts the requirement that OCI initiates the connection. This configuration would not meet the specified initiation requirement.

Site-to-Site VPN with BGP dynamic routing and OCI as the initiator

Why it fails: BGP dynamic routing is used for route exchange, but the initiator role is not a BGP setting. The OCI Site-to-Site VPN can be configured with BGP, but the initiation of the tunnel is determined by the CPE configuration. This option does not directly address the requirement for OCI to initiate the connection.

Local Peering Gateway

Why it fails: A Local Peering Gateway connects VCNs within the same OCI region and carries no BGP session or on-premises routing capability. It is tempting because it attaches to a DRG, and it would be correct when peering two VCNs locally rather than linking a datacenter over FastConnect.

NAT Gateway

Why it fails: A NAT Gateway provides outbound internet translation for private subnets and cannot terminate FastConnect or exchange BGP routes with on-premises routers. It is tempting because it is a DRG-attachable gateway, and it would be correct where instances need outbound internet access without public IP addresses.

Internet Gateway

Why it fails: An Internet Gateway handles public internet traffic for a VCN and does not establish BGP peering or propagate on-premises routes. It is tempting because it is another DRG-attached gateway, and it would be correct where subnets require direct inbound and outbound internet connectivity.

Deploy an OCI NAT Gateway inside the VCN.

Why it fails: A NAT Gateway translates outbound traffic to a public address; it cannot resolve overlapping RFC1918 ranges between the VCN and VNet, so routing remains ambiguous. It is tempting because NAT is commonly used for outbound internet access, and it would be correct when private subnets need egress without inbound exposure.

Configure a Dynamic Routing Gateway route table with static overriding rules.

Why it fails: A DRG route table distributes routes but cannot resolve overlapping CIDRs; both sides still advertise 10.0.0.0/16, so traffic is ambiguous. Static overrides only steer existing prefixes. DRG route tables are correct for controlling route selection between non-overlapping VCNs and on-premises networks.

Enable FastConnect MACsec encryption.

Why it fails: MACsec encrypts traffic on a FastConnect link; it cannot translate overlapping 10.0.0.0/16 prefixes, so the VCN and VNet still cannot route to each other. It is tempting because MACsec genuinely secures Interconnect traffic, and would be correct where link-level encryption is the requirement rather than address overlap.

OCI Storage Gateway

Why it fails: OCI Storage Gateway caches file, block, or object data between on-premises systems and OCI; it does not terminate IPSec tunnels or route VCN traffic. It is tempting because it links on-premises environments to OCI, and would be correct for extending storage capacity or migrating file data over an existing connection.

OCI API Gateway

Why it fails: OCI API Gateway publishes and manages REST APIs with authentication and rate limiting; it does not establish network-layer tunnels between premises and a VCN. It is tempting because it fronts private backends, and would be correct for exposing serverless or private services as managed API endpoints.

OCI Bastion Service

Why it fails: OCI Bastion Service provides restricted, time-bound SSH access to private subnets through a managed jump host; it carries no IPSec tunnel or customer-premises gateway peering. It is tempting because both concern private network access, and Bastion would be correct for administrative session access without exposing instances publicly.