Compute practice questions

Dedicated Virtual Machine Hosts

Why it fails: Dedicated Virtual Machine Hosts provide single-tenant compute capacity by ensuring that the underlying physical server is exclusively allocated to your specific tenancy. This mechanism satisfies the requirement for hardware isolation, as it prevents any other tenant’s virtual instances from residing on the same physical host. By bypassing the multi-tenant resource sharing inherent in standard virtual machine shapes, this service ensures strict physical separation, allowing you to maintain full control over the hardware environment for compliance or performance consistency.

Instance Pools

Why it fails: Instance pools are groups of identical instances managed as a single entity, not a multi-tenant isolation feature.

Protected Compute Shapes

Why it fails: Protected Compute Shapes do not provide physical hardware isolation, as they rely on memory encryption to secure data in use rather than ensuring exclusive access to the underlying server. This feature is intended for workloads requiring enhanced confidentiality against potential side-channel attacks or memory scraping within a multi-tenant environment. While it offers advanced security for sensitive data processing, it fails to satisfy the requirement for single-tenant hardware tenancy, which is exclusively achieved through the use of Dedicated Virtual Machine Hosts.

VCN Route Tables

Why it fails: Virtual Cloud Network route tables control packet forwarding and direct network traffic between subnets and gateways, meaning they dictate routing paths rather than managing compute instance placement or physical hardware isolation for OKE worker nodes. You might consider them when configuring specific egress paths or forcing traffic through a firewall appliance. However, they do not interact with fault domains or anti-affinity rules, which are required to distribute compute nodes across distinct physical infrastructure.

Kubernetes Horizontal Pod Autoscaler

Why it fails: Horizontal Pod Autoscaler adjusts the number of replica pods running inside a cluster based on observed CPU utilisation or custom metrics, meaning it manages workload scaling rather than underlying node placement across physical hardware infrastructures. It is tempting because it is a vital cluster scaling feature that administrators often configure alongside OKE deployments, and it would be the correct choice if the objective were to automatically scale application pods dynamically in response to fluctuating incoming traffic loads.

Pod Security Policies

Why it fails: Pod Security Policies control cluster-wide security permissions and authorization for pod creation, meaning they do not manage underlying compute infrastructure placement or anti-affinity rules across physical hardware. This option is tempting because it is a vital cluster configuration feature often enabled during initial setup to enforce security standards, and it would be the correct choice if the requirement was to restrict root access or govern privilege escalation for workloads running on the cluster.

Use the OCI Database Migration service to copy the operating system boot sectors.

Why it fails: OCI Database Migration service functions exclusively at the database layer, facilitating the transfer of schemas and data between Oracle databases rather than capturing block-level boot sectors or file systems. While this tool effectively automates the migration of complex database workloads between on-premises environments and OCI, it lacks the capability to replicate operating system volumes. Migrating a Windows Server boot volume requires block volume replication or custom image creation to preserve the boot configuration and sensitive application data stored on the disk.

Detach the boot volume, attach it to a secondary compute instance, and use rsync over a VCN remote peering connection.

Why it fails: Boot volumes cannot be attached as secondary data volumes to arbitrary running instances easily, and OS volumes require image export/import mechanisms for cross-region migration.

Create a custom image from the instance, export the image to an Object Storage bucket, copy the bucket to the target region, and import the image in the target region.

Why it fails: Custom images can be exported to Object Storage, copied across regions, and imported to provision instances in another region.

Make the Object Storage bucket completely public so any function can read from it without authentication.

Why it fails: Exposing the Object Storage bucket to the public domain violates the principle of least privilege by removing authentication entirely, meaning unauthorised external actors could harvest sensitive object data over the internet. This approach is tempting because public visibility is intended for hosting static web assets or public-facing documentation where data confidentiality is irrelevant and direct URL access without IAM overhead is required.

Embed the tenancy administrator API signing key directly in the function's source code.

Why it fails: Hardcoding a tenancy administrator API signing key directly into the deployment package violates the principle of least privilege and exposes high-privilege credentials if the source repository is compromised, failing to utilise resource-to-resource authentication. This approach appeals to developers because API keys are routinely used for local script authentication and programmatic management against the OCI REST API, and such credentials would correctly authenticate an external application or local development environment running outside of Oracle Cloud Infrastructure.

Attach a user credential to the function environment variables.

Why it fails: OCI services use dynamic groups and instance/resource principals rather than storing user credentials in environment variables.

To a local file directory `/var/log/kubernetes/` on the worker nodes.

Why it fails: Control plane logs are not written to worker nodes at all; OKE runs `kube-apiserver` and `kube-controller-manager` on managed control plane hosts, so `/var/log/kubernetes/` on worker nodes holds only kubelet and container runtime logs. It tempts because node-local log directories are the standard place to inspect kubelet or pod logs.

Control plane logs are permanently discarded for security reasons.

Why it fails: OCI Kubernetes Engine never discards control plane telemetry; instead, component logs are automatically routed to the Oracle Cloud Infrastructure Logging service. This distracts administrators because high-security compliance frameworks often mandate the permanent destruction of sensitive debugging output to prevent data leakage. In a theoretical zero-retention architecture designed strictly to satisfy ephemeral processing policies where audit trails are legally prohibited, discarding logs entirely would achieve that compliance goal.

Directly to an Object Storage bucket without enabling any service configuration.

Why it fails: OCI Container Engine for Kubernetes control plane logs are not automatically routed to an Object Storage bucket upon cluster creation, meaning this setup requires manual logging configuration or integration with OCI Streaming and Service Connector Hub. This approach is tempting because Object Storage is commonly used for long-term audit archiving and data compliance workflows, and it would indeed be the correct choice if you were specifically tasked with building a cold-storage backup pipeline for historical compliance records rather than performing live operational debugging.

Direct attachment to VCN Internet Gateways without any intermediate services

Why it fails: Internet gateways route VCN traffic, they do not invoke functions directly.

Scheduled cron jobs running inside block volume snapshots

Why it fails: Snapshots do not execute cron jobs or invoke functions.

VCN packet drop error rates

Why it fails: Virtual Cloud Network packet drop error rates measure underlying network interface card or path congestion issues, whereas Oracle Cloud Infrastructure Autoscaling relies exclusively on compute resource utilization metrics like CPU and memory usage to trigger instance pool adjustments. This metric appears tempting because network degradation can severely impact application performance, making it a logical choice for proactive capacity planning in scenarios where throughput bottlenecks—such as heavy ingress traffic spikes or DDoS mitigation—demand rapid scale-out actions to distribute network load across multiple backend servers.

Memory utilization percentage

Why it fails: Memory utilization is also supported as a threshold metric for autoscaling.

Object Storage bucket download count

Why it fails: Object storage bucket metrics do not trigger compute instance pool autoscaling directly.

Database transaction commit latency

Why it fails: Oracle Cloud Infrastructure Autoscaling evaluates compute instance pool metrics at the infrastructure layer, specifically CPU and memory utilisation, rather than application-tier database performance. Database transaction commit latency is tempting because it is a crucial metric for measuring database health and storage responsiveness under high workloads, making it the correct choice for configuring database scaling policies or alerts within Oracle Autonomous Database management tools. However, compute instance pool autoscaling engines lack native integration with database transaction logs and cannot poll database-internal performance counters to trigger infrastructure-level scaling events.

Modifying DNS records in external third-party domain registrars

Why it fails: Oracle Cloud Agent operates strictly within the guest operating system boundary to manage local compute lifecycle operations, meaning it lacks the external network integration required to interact with third-party domain registrar APIs. This option appears plausible because cloud administrators frequently need to configure external DNS records during instance provisioning or migration workflows. Such DNS management tasks are correctly handled through external network tooling, DNS service APIs, or specialized automation frameworks rather than a local instance management agent.

Configuring VCN security list packet filtering rules

Why it fails: Virtual Cloud Network security list rules operate at the subnet level within the core networking infrastructure rather than inside the guest operating system, meaning Oracle Cloud Agent has no role in processing or enforcing these perimeter filters. Administrators often confuse host-level firewall management with network-level configuration because both control traffic flow; this option would represent the correct administrative path if the requirement specified managing software-based firewalls residing locally on the compute instance itself, such as firewalld or iptables, via agent plugins.

Managing physical data center hardware maintenance and rack replacements

Why it fails: Oracle Cloud Agent operates exclusively within the guest operating system of a virtual machine to execute internal management tasks, whereas physical data centre hardware maintenance and rack replacements involve underlying infrastructure managed entirely by Oracle cloud operations staff. This option is tempting because hardware maintenance is an essential part of the cloud lifecycle, and administrators often confuse guest-level monitoring utilities with hypervisor- or datacenter-level management tooling. It would be the correct choice if the question asked about low-level hardware provisioning workflows handled by Oracle data centre technicians rather than tenant-managed compute instances.

Running `scp` from the on-premises hypervisor directly into the OCI hypervisor control plane

Why it fails: Direct network transfers into the OCI hypervisor control plane are blocked because customers lack direct administrative access to the underlying bare-metal hypervisor layer, meaning file-transfer utilities like `scp` cannot target it. This method appears superficially tempting because system administrators routinely rely on secure copy protocols to move large virtual disk images between local virtualisation hosts and storage repositories. Such direct host-to-host transfers would be the correct approach if managing a private, on-premises OpenStack or KVM deployment where root hypervisor access is natively available.

Directly plugging physical hard drives into OCI compute bare metal server USB ports

Why it fails: Oracle Cloud Infrastructure does not provide physical USB port access on bare metal compute instances for data ingestion, rendering direct hardware attachment impossible for migrating virtual machine disk images. This approach appears plausible because connecting physical storage directly to hardware is a standard local data transfer technique in on-premises server maintenance. Consequently, physical drive attachment is instead utilised with high-capacity offline data transport appliances like OCI Data Transfer Disk to securely ship large volumes of physical storage media to a designated data centre facility.

kubectl get events

Why it fails: This command retrieves cluster-level diagnostic events such as pod scheduling failures, container restarts, or node provisioning issues rather than application container output streams. It is tempting because administrators frequently use it during troubleshooting phases when pods fail to start or crash repeatedly on worker nodes. It would be the correct choice if you needed to investigate Kubernetes control plane events or resource lifecycle transitions rather than inspecting runtime standard output and error streams generated by active application code.

kubectl describe pod

Why it fails: *Describe* outputs metadata, configuration settings, and event histories for a pod rather than streaming stdout and stderr streams generated by the container runtime. This option is tempting because administrators frequently rely on it to troubleshoot failing pods when investigating CrashLoopBackOff states or scheduling failures. It would be the correct choice when you need to inspect infrastructure-level details such as volume mounts, restart counts, and node assignment rather than application-level diagnostic output.

oci compute instance list-logs

Why it fails: `oci compute instance list-logs` is invalid because it operates on Oracle Cloud Infrastructure bare metal or virtual machine compute instances rather than Kubernetes cluster objects. It is tempting because administrators frequently conflate underlying worker nodes with the container workloads running on them, and this OCI command is indeed the correct choice when you need to query native logging service entries for standalone infrastructure instances outside of a Kubernetes orchestration layer.

Enable instance pool autoscaling on the function application.

Why it fails: Instance pool autoscaling adjusts the number of container instances running concurrently to handle fluctuating request volume, yet it fails here because every newly provisioned container still undergoes a cold start and incurs the same thirty-second database connection penalty upon initialisation. While this feature is tempting due to its name suggesting capacity management, it is actually designed to handle traffic spikes and horizontal scaling by dynamically adding execution units. It would be the correct choice if the function timeout stemmed from queue saturation or concurrency limits rather than per-instance startup overhead.

Increase the function memory allocation to 32 GB.

Why it fails: Memory allocation does not persist connections across invocations; cold-start initialisation is avoided by provisioning concurrency or using a database connection pool outside the function. It is tempting because more memory does raise CPU share and speed execution, which helps CPU-bound functions rather than repeated connection setup.

Migrate the function container to an OKE cluster DaemonSet.

Why it fails: A DaemonSet guarantees that a pod runs on every node within an OKE cluster, which appears tempting for pre-warming database connections because running a persistent pod locally to the cluster infrastructure seems to eliminate cold-start overheads. However, this fails because OCI Functions operates as a fully managed, serverless FaaS platform executing code in ephemeral containers managed entirely by the Oracle Cloud infrastructure, meaning you cannot deploy or schedule serverless function invocations onto custom Kubernetes DaemonSets. OKE requires container images packaged as standard Kubernetes workloads rather than adhering to Fn Project specifications required by OCI Functions, rendering this architecture incompatible with the serverless function invocation model.

VM.Standard1.16

Why it fails: VM.Standard1.16 is a legacy standard shape offering 16 OCPUs, far exceeding the required 6, so resources are wasted. It is tempting because it is a general-purpose VM shape, and it would be correct where a workload genuinely needs 16 OCPUs rather than the exact 6 OCPU, 32 GB specification.

BM.Standard.E3.128

Why it fails: BM.Standard.E3.128 provides 128 OCPUs and 2,048 GB of RAM, which vastly exceeds the requested 6 OCPUs and 32 GB, causing significant resource wastage through over-provisioning. While this bare metal shape offers the high-performance isolation and dedicated hardware access required for massive, compute-intensive workloads that demand full physical server control, it fails to meet the specific sizing constraints of this deployment. It is intended for large-scale, single-tenant applications that necessitate the entire physical host's capacity rather than a small, granular virtualised instance.

VM.Standard2.8

Why it fails: VM.Standard2.8 provides 8 OCPUs, exceeding the required 6, so two OCPUs are wasted. It is tempting because it is a current-generation standard shape, and it would be correct where the workload needs 8 OCPUs or where only whole standard shapes are available.

Inside the VCN Security List configurations

Why it fails: VCN Security Lists manage packet filtering at the subnet level to control ingress and egress traffic via stateful or stateless rules. While these lists are essential for defining network access policies and firewalling, they cannot modify hardware-level instance properties such as NIC virtualization modes or firmware boot parameters. Candidates often confuse network security with instance configuration because both involve infrastructure settings, yet Security Lists lack the functional capability to interact with the hypervisor-level launch options required for custom boot environments.

Via the compute instance's operating system kernel parameters

Why it fails: Modifying the operating system kernel parameters occurs after the boot process has initiated, meaning it cannot influence the initial hardware abstraction layer or the NIC virtualization mode required by the hypervisor. While this approach is standard for tuning runtime performance or passing arguments to the Linux kernel during normal operation, it lacks the authority to dictate how the OCI virtual machine platform presents hardware devices to the guest during the initial boot sequence.

In the Instance Configuration template parameters

Why it fails: Instance Configurations define the reusable settings for scaling and auto-scaling groups, but they lack the specific fields required to override low-level virtualisation modes or UEFI boot parameters for individual compute instances. This option appears relevant because it serves as a blueprint for deploying multiple identical resources, leading users to conflate general deployment templates with the granular, instance-level launch options needed to satisfy unique hardware compatibility requirements for legacy migrations.

The instance is terminated, and a new instance is provisioned to replace it, temporarily exceeding the maximum limit if necessary until scaling rules scale it back down.

Why it fails: The pool will terminate the unhealthy instance and provision a replacement within the defined bounds.

The instance is terminated and not replaced because the pool is already at its maximum limit.

Why it fails: Auto-scaling maximum limits cap standard operational expansion, which makes terminating a retired instance without replacement seem logical when capacity is fully saturated. This behaviour would correctly apply during standard scale-in events or when evaluating normal capacity constraints against fixed maximum boundaries. However, hardware maintenance retirement triggers a mandatory replacement lifecycle that supersedes current pool size thresholds. Oracle Cloud Infrastructure guarantees high availability by provisioning a replacement instance to maintain the desired configuration state, temporarily allowing the pool to exceed its nominal maximum limit before systematically draining and terminating the degraded node.

The autoscaling configuration must be manually edited to increase the max limit before the instance can be replaced.

Why it fails: Manually adjusting the maximum limit is unnecessary because Oracle Cloud Infrastructure Instance Pools with Autoscaling automatically manage instance lifecycles and replacement operations internally. This option sounds plausible because administrators frequently modify autoscaling configuration parameters when they intentionally wish to scale out capacity beyond current bounds to accommodate sustained workload growth. However, in this hardware maintenance scenario, the system autonomously replaces the retired instance while strictly adhering to the existing maximum boundary, ensuring service availability without requiring manual administrative intervention to redefine pool limits.

Direct polling of Object Storage buckets by the function container

Why it fails: OCI Functions operates on a stateless, event-driven model that cannot maintain a persistent listening process, meaning direct bucket polling would require a continuously running container to check for new files, completely defeating the serverless architecture. Developers are often tempted to use polling when building scheduled batch-processing tasks where an application periodically queries a data store to fetch unprocessed records at fixed time intervals.

Scheduled Cron Jobs in Compute

Why it fails: Scheduled Cron Jobs in Compute rely on time-based intervals rather than event-driven architectures, meaning they cannot react dynamically to the moment a new file lands in OCI Object Storage and would instead poll the bucket on a rigid schedule, leading to unnecessary resource consumption or missed uploads. This approach is typically used for batch processing tasks, periodic data backups, or routine maintenance scripts that must run at fixed calendar times.

API Gateway direct integration

Why it fails: API Gateway does not natively subscribe to OCI Object Storage events, as it functions as a managed entry point for HTTP requests rather than an event-driven consumer for storage lifecycle notifications. This option appears attractive because developers frequently use API Gateway to expose serverless functions to external clients or web applications. It serves as the primary mechanism when you need to provide a public RESTful interface or manage authentication for function invocations triggered by external HTTP traffic.

Block Volume Backup

Why it fails: Block volume backups capture data for restore, not a bootable template, so they cannot launch new instances with the baked-in configurations and agents. Backups are correct for disaster recovery and rollback; a custom image is required to provision identical instances repeatedly.

Boot Volume Clone

Why it fails: A boot volume clone duplicates only the block storage of one instance, so it cannot be launched as a reusable image across availability domains or shared. Cloning suits quick single-instance recovery; custom images are the artefact for standardised, repeatable instance provisioning.

Instance Configuration

Why it fails: Instance Configurations merely store templates containing metadata, boot disk parameters, and shape definitions to deploy identical virtual machines, lacking the capability to capture the actual operating system state, custom security configurations, or pre-installed binaries. Administrators typically find this choice tempting because it is designed for rapid horizontal scaling and automated fleet provisioning, making it the correct feature when you need to define a repeatable blueprint for launching identical compute instances from an existing source image rather than building a custom persistent image.

BM.Standard3.64

Why it fails: BM.Standard3.64 provides NVMe local storage, but its X7-class Intel platform targets general-purpose and HPC workloads rather than the dense, high-IOPS raw NVMe transaction logging this database demands. It is tempting because bare metal removes hypervisor overhead, which would be the right reasoning when raw compute performance, not storage latency, is the constraint.

VM.Standard.E4.Flex

Why it fails: VM.Standard.E4.Flex instances utilise network-attached block storage, which introduces latency overheads incompatible with the requirement for direct-attached, low-latency NVMe drives for transaction logging. This shape provides a flexible, general-purpose compute environment designed for cost-effective scaling of web servers or application tiers where local NVMe performance is not a prerequisite. It serves as a versatile option for standard enterprise workloads that prioritise elastic resource allocation over the hardware-level storage throughput provided by Dense I/O shapes.

BM.GPU3.8

Why it fails: BM.GPU3.8 attaches NVMe drives, yet its eight NVIDIA GPUs address GPU-accelerated compute such as machine learning training, not transaction-log write latency. It is tempting because the shape does include fast local NVMe storage, so it would be the correct selection when the workload's actual bottleneck is GPU parallelism rather than database logging throughput.

The cluster becomes completely inaccessible, and all pods are evicted permanently.

Why it fails: A control plane upgrade leaves worker nodes running and workloads intact; the API server is upgraded while existing pods continue serving. Nodes are upgraded separately via node pools. Total permanent inaccessibility describes a failed or deleted cluster, not a routine version upgrade.

Control plane upgrades are blocked until all worker nodes are upgraded first.

Why it fails: Oracle Cloud Infrastructure Container Engine for Kubernetes allows independent control plane and worker node lifecycles, meaning control plane upgrades do not require prior node remediation and will proceed without blocking. This approach is tempting because administrators often need to maintain version skew compatibility where worker nodes must not lag behind the control plane by more than one minor version, which resembles workflows in managed environments where node pools are updated to match a newly targeted control plane version first.

All worker nodes are automatically terminated and recreated with the new version.

Why it fails: Upgrading an Oracle Cloud Infrastructure Container Engine for Kubernetes (OKE) control plane does not disrupt worker nodes, which continue running workloads independently while management components are updated. This misconception likely stems from node pool management workflows where nodes must be replaced to apply a new Kubernetes version, which would be the correct procedure if the requirement specifically mandated upgrading the data plane worker nodes rather than the control plane itself.

VM.Standard.E4.Flex

Why it fails: VM.Standard.E4.Flex relies on AMD EPYC processors rather than ARM-based Ampere architecture, meaning it fails to utilise the specific silicon requested by the scenario. It is tempting because it is a flexible shape designed to provide cost-effective compute for general-purpose workloads, and it would be the correct choice when you specifically require x86-64 compatibility with customisable core and memory allocations on AMD hardware.

BM.DenseIO2.52

Why it fails: BM.DenseIO2.52 relies on x86-based Intel Xeon processors rather than the ARM-based Ampere architecture required for the lowest cost per core. While this shape is tempting due to its high-performance local NVMe storage, it serves workloads demanding intensive disk I/O and low-latency data access rather than general-purpose compute cost-optimisation. Consequently, it fails to meet the specific requirement for ARM-based efficiency, as its hardware design prioritises storage throughput over the cost-effective scaling provided by the Ampere A1 compute platform.

VM.Standard3.Flex

Why it fails: VM.Standard3.Flex relies on x86-based Intel Xeon processors rather than the ARM-based Ampere architecture required by the question stem, meaning it cannot deliver the specific low-cost-per-core economic advantage demanded. This shape would be the correct choice when you need a flexible, general-purpose x86 compute instance with customisable OCPUs and memory allocations to run traditional enterprise applications or software that lacks native compilation for ARM instruction sets.

terraform

Why it fails: Terraform is an Infrastructure as Code engine designed to provision and manage cloud resources declaratively, such as setting up the underlying Oracle Cloud Infrastructure networking, applications, and function service configurations, making it tempting when automating a deployment pipeline. However, it fails this scenario because it lacks the container tooling required to build, test, and push Open Container Initiative images directly to the Oracle Registry. Therefore, developers must rely on the Fn Project CLI combined with a container engine for image management tasks.

oci-cli

Why it fails: The oci-cli manages Oracle Cloud Infrastructure resources such as functions, applications and triggers, but image build and push are performed by the Fn Project CLI (fn) with Docker. It is tempting because oci-cli does deploy functions, yet it does not build or push container images to the registry.

kubectl

Why it fails: `kubectl` fails in this scenario because it is designed to manage Kubernetes cluster resources, pods, and deployments, lacking the specific capabilities required to build, test, and push Open Container Initiative function images to the Oracle Functions Registry. It remains tempting due to its ubiquity as a standard container orchestration command-line interface for deploying workloads, making it the correct choice when managing native Kubernetes objects on Oracle Cloud Infrastructure Container Engine for Kubernetes rather than serverless functions.