Troubleshooting Scenario Questions

The Internet Gateway has exceeded its bandwidth limit.

Why it fails: Internet Gateways in Oracle Cloud Infrastructure provide a path for traffic to the public internet but do not impose bandwidth limits that trigger 504 Gateway Timeout errors. This option appears relevant because users often associate connectivity issues with edge infrastructure. It would be the correct choice only if the scenario involved a complete loss of internet reachability or severe packet loss across the entire virtual cloud network, rather than a specific timeout occurring during the handshake between the load balancer and backend servers.

The NAT Gateway is blocking incoming HTTP traffic.

Why it fails: NAT Gateways facilitate outbound connectivity for private subnets and do not process incoming traffic from a Public Load Balancer, meaning they cannot trigger 504 Gateway Timeouts for external requests. This option appears relevant because administrators often confuse network path components when troubleshooting connectivity failures. It would be the correct choice if the backend servers were unable to reach external services, such as software repositories or Microsoft Entra ID, due to a misconfigured routing table or a lack of an outbound path.

The VCN route table is missing a default route.

Why it fails: Missing a default route in the VCN route table prevents all outbound traffic from the backend servers, leading to a total loss of connectivity rather than intermittent 504 errors. This option appears relevant because route tables are fundamental to network reachability within OCI. It would be the correct choice if the backend servers were unable to reach the internet or other subnets entirely, as a missing default route causes a complete failure of packet routing for non-local traffic.

The Security List must have a stateful egress rule allowing all protocols to the internet.

Why it fails: Security Lists filter traffic for instances in a subnet; they do not program VCN routing, so a missing on-premises CIDR in the route table cannot be fixed there. Security Lists are tempting because dropped traffic often stems from overly strict rules, and would be the right construct when egress to a legitimate destination is blocked by a missing rule.

The Local Peering Gateway route table must map the on-premises subnet.

Why it fails: Local Peering Gateways facilitate connectivity exclusively between two Virtual Cloud Networks within the same region, meaning they lack the functional capacity to route traffic across an IPsec VPN. While this construct appears relevant when managing complex multi-VCN topologies, it remains entirely decoupled from the Dynamic Routing Gateway’s routing logic. You would only utilise a Local Peering Gateway when establishing private network peering between distinct VCNs, a scenario that does not involve the on-premises CIDR reachability requirements specified in this troubleshooting task.

The NAT Gateway route table must be updated with the on-premises CIDR.

Why it fails: NAT Gateways facilitate outbound internet connectivity for private subnets and do not participate in routing traffic across IPsec VPN tunnels. While this construct is essential when instances require private access to public internet services, it lacks the routing integration necessary to direct packets toward a Dynamic Routing Gateway. You would only configure a route rule pointing to a NAT Gateway when enabling private instances to initiate outbound connections to external public endpoints, rather than managing traffic flow between on-premises networks and OCI.

Oracle Database In-Memory Column Store

Why it fails: The In-Memory Column Store holds columnar copies in the database SGA; it accelerates analytic scans but performs no filtering or projection on storage cells. It is the right choice when queries benefit from in-memory columnar access rather than cell offload.

Hybrid Columnar Compression (HCC)

Why it fails: HCC compresses data into columnar storage units on disk, reducing I/O, but it does not push filter or projection processing to the storage servers. HCC suits reducing storage footprint and scan volume for largely read-only data.

Automatic Storage Management (ASM) Mirroring

Why it fails: Automatic Storage Management (ASM) Mirroring deals exclusively with data redundancy and high availability by maintaining multiple copies of extents across different Oracle Exadata storage servers to protect against disk failures. It does not perform SQL processing, filtering, or column projections. This option is tempting because it is a fundamental Exadata storage configuration component that administrators frequently interact with when managing storage cells, making it a familiar term when troubleshooting database-level performance issues.

The user's password in OCI IAM has expired and must be reset.

Why it fails: Federated SAML users authenticate at the IdP, so an expired local OCI password is irrelevant; the error indicates a missing user or group mapping. It is tempting because password expiry commonly causes login failures, but it cannot apply when authentication is delegated to the external identity provider.

The API signing key of the IdP metadata XML file needs to be rotated daily.

Why it fails: Rotating the IdP metadata XML file's API signing key daily addresses certificate expiration or cryptographic credential compromise, but has no functional impact on how SAML assertions map user identities or group memberships to Oracle Cloud Infrastructure IAM. This option appears attractive because administrators frequently troubleshoot authentication failures by focusing on security certificates and trust relationships established in the IdP metadata. However, certificate rotation would be the correct procedure only when dealing with cryptographic validation errors or imminent expiry of the signing certificate, rather than identity mapping or authorisation failures.

OCI requires manual creation of local user profiles for every federated login attempt.

Why it fails: Oracle Cloud Infrastructure delegates user provisioning and identity mapping entirely to the Identity and Access Management service via federation groups, meaning local user profiles are never required for external identities. This choice appears logical because administrators coming from legacy on-premises systems are accustomed to manually provisioning local accounts for every incoming user. However, manual creation is only necessary for native IAM users who authenticate directly with local credentials rather than relying on an external SAML identity provider.

NAT Gateway packet tracer

Why it fails: NAT Gateway packet tracer cannot test reachability between two internal instances because it is specifically designed to diagnose traffic traversing a NAT Gateway to or from the internet. It is tempting because its name implies general packet-tracing capabilities for troubleshooting network paths. It would be the correct choice if you needed to verify translation rules or troubleshoot outbound connectivity from a private subnet to a public destination on the internet, rather than lateral internal traffic between a private application instance and a database instance on port 1521.

OCI Load Balancer health check

Why it fails: An OCI Load Balancer health check monitors backend server availability by periodically sending HTTP, HTTPS, or TCP requests through a listener, making it tempting because it tests port-level connectivity. However, it fails in this troubleshooting scenario because health checks are designed to determine traffic routing for public or private load balancer backends, not to diagnose arbitrary point-to-point network reachability, security list configurations, or path-level packet drops between an independent application instance and a database instance located within a private subnet.

Service Gateway connectivity tester

Why it fails: A Service Gateway is exclusively designed to route traffic privately from a VCN to Oracle Cloud Infrastructure public services, such as Object Storage or Autonomous Database public endpoints, without traversing the internet. Although it deals with private database connectivity, it cannot test or troubleshoot security list rule evaluations between two compute instances within your virtual cloud network. It would be the correct choice if you needed to configure private routing to Oracle-managed public endpoints, but it offers no diagnostic utilities for examining packet flow, port accessibility, or security list blocks between internal subnets.

Explicit deny statements always take precedence over allow statements.

Why it fails: OCI IAM policies are strictly additive, meaning any 'allow' statement grants access regardless of other existing policies, as there is no mechanism for explicit denial within the OCI policy language. This option mimics the logic found in Microsoft Entra ID or AWS IAM, where explicit deny statements override allow rules to enforce security boundaries. Because OCI lacks a deny construct, this principle cannot influence policy evaluation, making the statement technically inapplicable to the OCI environment.

Compartment-level policies take strict precedence, overriding and nullifying tenancy root policies.

Why it fails: OCI IAM employs an additive evaluation model where policies at all levels are combined to determine access, meaning compartment-level statements cannot nullify or override broader tenancy-level permissions. This option is tempting because it mirrors the hierarchical inheritance models found in other identity providers, such as Microsoft Entra ID, where specific resource-level assignments often supersede inherited permissions. However, OCI IAM treats all applicable policies as a cumulative set, ensuring that any policy granting access remains effective regardless of its location in the hierarchy.

The most recently created policy overrides all older conflicting policies.

Why it fails: OCI IAM evaluates policies based on the principle of least privilege and additive permissions, meaning it grants access if any applicable policy allows it, rather than prioritising creation timestamps. This option is tempting because temporal precedence is a standard mechanism in other identity providers, such as Microsoft Entra ID, where conditional access policies or specific rule-based configurations may rely on evaluation order or priority numbers to resolve conflicts. In OCI, however, policy creation time is irrelevant to the cumulative authorisation logic applied during request evaluation.

The NAT Gateway is misconfigured.

Why it fails: A NAT Gateway facilitates outbound internet connectivity for private subnets rather than managing inbound traffic destined for a public load balancer, rendering it irrelevant to public listener dropped connections. Although this service is tempting because it handles outbound traffic routing and network address translation issues, it would only be the correct choice if internal backend instances were failing to reach external APIs or software repositories, not when external clients experience connection drops at the load balancer level.

The VCN route table is missing a default route.

Why it fails: Dropped connections on a public load balancer typically stem from backend health failures, listener limits, or security list mismatches, not a missing VCN default route. A default route is tempting because it governs egress, but load balancer traffic to backends uses subnet-local routing, so its absence would not cause this metric.

The DNS record has an incorrect TTL.

Why it fails: An incorrect Time To Live (TTL) on a DNS record affects record propagation speed and client-side caching duration, leading to stale IP resolution or delayed failover, but it has no mechanism to actively drop established or incoming TCP connections at the load balancer layer. This option is tempting when troubleshooting intermittent reachability problems because improper DNS caching often causes clients to intermittently target decommissioned or unhealthy backend endpoints, making DNS a frequent preliminary suspect; an adjusted TTL would be the correct choice if clients were persistently failing to discover updated backend pool IP addresses after a regional migration or disaster recovery failover event.

Events logs

Why it fails: Events logs record audit trails of control plane operations, such as who initiated a deployment or when a resource was modified, but they do not capture the granular execution details of the Terraform provider. This option appears relevant because administrators frequently consult these logs to identify the status of resource operations within the portal. However, you must access the specific Terraform output logs via the deployment job's execution stream to diagnose internal configuration errors or provider-level failures during the infrastructure provisioning process.

Audit logs

Why it fails: Audit logs track control plane operations and administrative actions performed against resources, failing to capture the granular execution output generated by Terraform providers during a deployment. While this option appears relevant because it records lifecycle events triggered by the Resource Manager, it is designed to monitor who performed an action and when. You should utilise Audit logs to investigate security events or configuration changes initiated via the portal or Microsoft Entra ID, rather than to debug internal stack execution errors.

Cloud Shell logs

Why it fails: Cloud Shell logs capture session-specific command history and environment interactions rather than the backend execution logs generated by the Resource Manager service during Terraform provider operations. This option appears relevant because Cloud Shell provides a pre-configured environment for running Terraform commands manually. It serves as a useful diagnostic tool when troubleshooting local CLI authentication or script syntax errors, but it lacks the visibility into the managed infrastructure-as-code service logs required to diagnose automated deployment failures within the platform.

HPC (High-Performance Computing) Shape

Why it fails: HPC shapes bill on-demand for full CPU without a burstable credit model, so credit exhaustion cannot occur. It is tempting because throttling suggests constrained CPU, but burstable shapes such as VM.Standard.E3 or E4 Flex are the ones that exhaust credits.

Bare Metal Standard Shape

Why it fails: Bare Metal shapes give dedicated physical cores with no burst-credit mechanism, so CPU throttling from exhausted credits cannot occur. Burstable VM shapes (such as E3/E4 flex with baseline OCPU utilisation) are the ones that consume credits and throttle once depleted, which is the scenario described.

GPU Shape

Why it fails: Graphics Processing Units are designed for massively parallel workloads such as machine learning, rendering, and scientific simulations rather than CPU credit-based throttling. They would be the correct choice if you were troubleshooting deep learning model training speeds or complex parallel rendering pipelines running on OCI instances equipped with NVIDIA hardware. However, they rely on dedicated high-performance processor architectures that bill continuously for dedicated physical resources, meaning they never accumulate or exhaust burstable CPU credits, making this shape entirely unrelated to the credit exhaustion issue described in the scenario.

Delete the VCN and recreate all networking subnets.

Why it fails: Recreating the entire Virtual Cloud Network (VCN) and its subnets is a destructive, disproportionate measure that fails to diagnose or resolve a targeted SSH unresponsiveness issue on a single instance, disrupting all other resources sharing that network. Administrators are often tempted to rebuild entire networking topologies when facing stubborn connectivity failures, assuming a deep-seated routing or gateway misconfiguration. Such a drastic measure would be the correct choice only during a fundamental architectural redesign, catastrophic subnet corruption affecting multiple services, or when wholesale replacement of the CIDR block structure and associated internet gateways is required to clear persistent underlying infrastructure faults.

Log into the physical data center and connect a physical keyboard to the server rack.

Why it fails: Oracle Cloud Infrastructure manages all underlying server hardware within multitenant cloud data centres, meaning tenants do not have physical access to server racks or facilities. This approach is tempting because connecting a physical console directly to hardware is the standard troubleshooting method for unravelling boot failures in an on-premises enterprise data centre where direct hardware access is available. However, in a public cloud architecture, physical intervention by the customer is strictly prohibited, and diagnostic procedures must instead utilise cloud-native mechanisms such as the OCI Console serial console connection or attaching the root volume to a rescue instance.

Reinstall the OCI tenancy IAM security policies.

Why it fails: Reinstalling Identity and Access Management (IAM) security policies does not restore network connectivity or resolve kernel panics on an unresponsive guest operating system, because IAM rules control who can authenticate and authorise actions against OCI API endpoints rather than managing virtual machine network interfaces or local daemons. This troubleshooting step can be tempting because administrators frequently suspect authentication failures or permission lockouts when an SSH connection drops, making IAM policy reapplication the correct choice when users experience 'Not Authorised' API errors, permission denied API responses, or need to reset tenancy-level access control permissions.

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.

Configure a NAT Gateway on the load balancer subnet.

Why it fails: Configuring a NAT Gateway on the load balancer subnet fails because it manages outbound traffic translation to the internet rather than permitting inbound packets to backend compute instances. Administrators often confuse routing architecture with stateful firewall rules when troubleshooting connectivity paths. A NAT Gateway would be the correct choice if backend instances residing in a private subnet needed to initiate outbound connections to external internet services while remaining shielded from unsolicited inbound requests.

Change the load balancer shape from Flexible to 100 Mbps.

Why it fails: Changing the load balancer shape solely alters its bandwidth capacity and does not modify network security rules or firewall paths, meaning traffic would still be blocked by the backend subnet security lists. This adjustment appears superficially relevant because performance modifications are a standard troubleshooting step when dealing with unreachable endpoints or sluggish service tiers, making it the appropriate choice when an application experiences throughput bottlenecks or requires a guaranteed baseline bandwidth during high-traffic events.

Attach an Internet Gateway to the backend subnet route table.

Why it fails: Attaching an Internet Gateway to the backend subnet route table fails because backend Compute instances reside in a private subnet where internet-bound traffic must flow through a NAT Gateway or Service Gateway rather than accepting direct public inbound packets. This option is tempting because Internet Gateways are fundamental networking components used to enable direct inbound and outbound internet connectivity for public subnets, making them the correct choice when configuring a VCN to allow public resources to communicate directly with the public internet.

Object Storage boot bucket logs

Why it fails: Object Storage buckets store block volume backups and exported custom image qcow2 or VMDK binaries rather than real-time hypervisor-level console output generated during an instance startup. This choice is tempting because administrators frequently interact with Object Storage when importing or exporting custom images between compartments or tenancies, making it a logical place to look for image-related artefacts. However, diagnostic logs capturing live kernel panics and low-level GRUB boot loader sequences are streamed directly to the instance serial console service rather than saved as log files within storage buckets.

OCI Logging service via custom log agents

Why it fails: Custom log agents require an operating system to boot completely and run daemon processes to forward application and system logs to the OCI Logging service. This approach is tempting because the Logging service provides centralised cloud-scale log management and analytics for running instances, making it the correct choice for aggregating application-level metrics, OS audit trails, and custom log files from healthy, fully operational compute instances. However, because the instance is stuck in a pre-boot state and suffering from a kernel panic, the OS and its agents cannot load, rendering agent-based log collection impossible.

OCI Monitoring service under instance metrics

Why it fails: OCI Monitoring metrics track performance data such as CPU utilisation, memory usage, and disk throughput, but they lack the granularity to capture kernel-level boot logs or text-based console output. This option is tempting because it provides visibility into instance health; however, it is intended for diagnosing resource bottlenecks or capacity issues during normal operation. It cannot display the low-level boot sequence or kernel panic messages required to troubleshoot a system that fails to reach the operating system login prompt.

The VCN CIDR block must be changed to /8.

Why it fails: Changing the Virtual Cloud Network (VCN) CIDR block to an /8 alters the total address space available within the network, which is tempting if one mistakenly believes internet access requires a larger local IP range. VCN sizing defines the pool of internal private IP addresses for resource allocation and has no direct functional bearing on routing traffic through an Internet Gateway. This adjustment would be appropriate only in scenarios where an existing VCN has completely exhausted its private IP address capacity and needs to expand its internal address pool to accommodate additional compute instances.

A Service Gateway must be attached to the VCN.

Why it fails: A Service Gateway is designed to provide private routing from a VCN to Oracle Services Network endpoints, such as Object Storage or Oracle Autonomous Database, without traversing the public internet. While this option sounds plausible because it involves extending VCN connectivity, it fails in this scenario because it does not enable general outbound internet access for private IP instances. A Service Gateway would be the correct choice if the instances needed to securely communicate with regional Oracle cloud services while remaining isolated from the public internet.

A NAT Gateway must be attached to the public subnet.

Why it fails: A NAT Gateway resides in a private subnet's route table, not a public subnet, and instances lacking public IPs need a NAT Gateway route rather than an Internet Gateway. It is tempting because NAT gateways do enable outbound internet for private instances, but the stem's subnet is already public with an Internet Gateway route.

Temporarily attach a public IP address to the worker node and connect via SSH.

Why it fails: Attaching a public IP exposes the node directly to the internet, contradicting the requirement that external SSH access stay disabled. It is tempting as a quick fix, yet the correct approach is a bastion host or OCI Bastion service reached through the private subnet, preserving isolation.

Modify the VCN security list to allow inbound SSH from 0.0.0.0/0 to the private subnet.

Why it fails: Opening the VCN security list to the entire internet exposes the private subnet to unauthorised access, violating the fundamental security principle of isolating private nodes from public traffic. While this method provides direct network connectivity for troubleshooting, it is intended only for public subnets where external reachability is a requirement. In this private cluster scenario, the approach fails because it bypasses the necessary bastion host or VPN tunnel architecture required to maintain a secure, private network boundary.

Run `kubectl exec` with privileged mode to gain root access to the underlying node's operating system.

Why it fails: `kubectl exec` operates strictly within the container runtime environment and lacks the capability to access the host node’s operating system, even when using privileged mode. This command is designed for troubleshooting application-level issues or inspecting containerised processes. It serves as a standard tool for developers needing to debug code or verify configurations inside a running pod. However, it cannot provide the SSH-level access required to manage the underlying node infrastructure or perform system-level maintenance on the host.