Select Two (Multi-Select) Questions

Rely solely on single-instance virtual machines with automatic daily backups instead of multi-node clustering.

Why it fails: Single-instance VMs with daily backups leave an outage window until restore completes, so no fault isolation or automatic failover occurs. Backups suit disaster recovery of data, not continuous uptime. Multi-node clustering across availability domains is required for resilience.

Deploy all database and application instances in a single Fault Domain to optimize network latency.

Why it fails: Concentrating every instance in one fault domain means a single hardware or power failure takes down the whole stack, defeating fault isolation. Co-location suits latency-sensitive single-domain workloads, but the stem demands maximum uptime across independent failure boundaries.

Storage Gateway

Why it fails: Storage Gateway is an on-premises caching appliance, not a VCN gateway.

Database Gateway

Why it fails: Database Gateway is not an OCI networking gateway.

Providing cloud services exclusively through public multi-tenant data centers operated solely by Oracle.

Why it fails: OCI's distributed cloud model spans public regions, dedicated regions, Cloud@Customer and hybrid deployments, not public multi-tenant data centres alone. It is tempting because Oracle does operate public regions, but the tenet is choice of deployment location, so exclusivity contradicts the model's defining characteristic of running the same services across many environments.

Restricting all database services to run exclusively on-premises.

Why it fails: OCI distributed cloud delivers the same services across public, dedicated, hybrid and on-premises locations; it does not confine database services to on-premises. It is tempting because Cloud@Customer and dedicated region options exist, but those are optional deployment choices, not a restriction, and Exadata services remain available in OCI public regions.

Requiring customers to manage their own underlying physical hardware in OCI public regions.

Why it fails: OCI operates the physical infrastructure in its public regions; customers consume services rather than managing hardware. It is tempting because Cloud@Customer places hardware in the customer's data centre, but that is a distinct deployment model, and the distributed cloud tenet concerns consistent services across locations, not customer hardware ownership in public regions.

Flexible shapes are only available on Bare Metal instances and cannot be used with Virtual Machines.

Why it fails: Flexible shapes are available on both Virtual Machine and Bare Metal instances, so restricting them to Bare Metal is false. The temptation arises because bare-metal workloads often need custom OCPU-to-memory ratios, but flexible shapes exist precisely to let VMs scale OCPUs and memory independently.

Flexible shapes do not support boot volume resizing.

Why it fails: Boot volume resizing is independent of compute shape flexibility, so this claim is false. It tempts administrators who associate flexible shapes with fixed storage, but block volume and boot volume resizing are governed by storage settings, not by whether the compute shape is flexible.

You must select a fixed tier of memory for every OCPU selected.

Why it fails: Flexible shapes let you set memory independently per OCPU within allowed ratios, so a fixed memory tier per OCPU is false. The distractor mirrors fixed shapes, where OCPU and memory are bundled; that model applies to non-flexible standard shapes, not flexible ones.

Service limits cannot be increased under any circumstances.

Why it fails: Limits are soft quotas that can be raised by submitting a service-limit increase request, so claiming they are permanently fixed is false. It tempts because some limits are hard and cannot change, but the general OCI service-limits model supports approved increases.

Service limits are managed entirely by writing IAM policy statements.

Why it fails: Service limits are quota values set per tenancy and region, adjustable via support requests, not through IAM policy statements, which govern authorisation. It tempts because IAM policies control resource access, but quotas and permissions are separate mechanisms; policy syntax cannot raise a limit.

Service limits apply only to Object Storage and cannot restrict compute or networking.

Why it fails: Service limits apply across OCI services, including compute, networking and storage, so restricting them to Object Storage is factually wrong. It tempts because Object Storage has well-known limits, yet the stem asks about the general service-limits framework, which spans all resource types.

An availability domain can span across multiple geographic countries to maximize data locality.

Why it fails: Availability domains are contained within a single region and cannot span countries; a region is the geographic boundary. It is tempting because spreading data across locations improves locality and resilience, but that is achieved by deploying across multiple regions, not by stretching one availability domain beyond its region.

Availability domains share power, cooling, and physical security infrastructure to reduce operational overhead.

Why it fails: Availability domains are isolated from each other: each has independent power, cooling, and physical security, so sharing them is false. It is tempting because sharing infrastructure reduces cost, which is why fault domains within an AD share some resources, but AD isolation is the design principle enabling high availability across ADs.

Internet Gateway with Public IP

Why it fails: An Internet Gateway gives a VCN inbound and outbound public connectivity, but it does not provide a private dedicated path to an on-premises data centre; that requires IPSec VPN or FastConnect. It is tempting because it connects networks, yet it is designed for public internet access, not site-to-site private connectivity.

Local Peering Gateway

Why it fails: A Local Peering Gateway connects two VCNs within the same OCI region, not an on-premises data centre to a VCN; that requires IPSec VPN or FastConnect. It is tempting because peering links networks, but its scope is intra-region VCN-to-VCN traffic, not hybrid on-premises connectivity.

Object Storage Gateway

Why it fails: An Object Storage Gateway is a software appliance that exposes OCI Object Storage buckets over NFS or SMB to on-premises clients; it does not extend a VCN's layer-3 network to a data centre. It is tempting because it bridges on-premises workloads to OCI storage, but the question asks about connecting to a VCN, which requires IPSec VPN or FastConnect.

OCI Virtual Private Tenant

Why it fails: No such OCI deployment model exists; OCI's distributed cloud comprises Dedicated Region, Cloud@Customer, and public regions, not a "virtual private tenant". It is tempting because tenancy isolation is a genuine OCI concept, but tenancy describes logical account separation within a region, not a deployment model placing services at customer or data-residency locations.

OCI Local Compute Zone

Why it fails: OCI Local Compute Zone is not a named distributed cloud deployment model; the strategy's models are Dedicated Region, Cloud@Customer, and public regions. The name tempts because OCI does offer local compute placement, yet that describes capacity within an existing region rather than a distinct deployment model serving data-residency requirements.

OCI Bare Metal Isolated Instance

Why it fails: Bare metal instances are a compute shape within OCI regions, not a distributed cloud deployment model; the strategy's models are Dedicated Region, Cloud@Customer, and public regions. The term tempts because bare metal offers isolation, but isolation of a single instance does not relocate cloud services to customer premises or residency locations.

DNS Service

Why it fails: DNS Service resolves domain names to IP addresses, providing naming rather than data persistence. It tempts because it is a real OCI service and networking components often appear in the same console region as storage, but the storage services are Object Storage, Block Volume, File Storage and Archive Storage.

Load Balancer

Why it fails: Load Balancer distributes incoming traffic across backend servers; it holds no data as a storage offering. It tempts because it is a core OCI networking service frequently deployed with storage in reference architectures, but the question asks specifically for storage services such as Object Storage and Block Volume.

Functions

Why it fails: Functions is a serverless compute service that runs code in response to events, storing nothing persistently. It tempts because it is a genuine OCI service and appears alongside storage in console menus, but the storage services are Object Storage, Block Volume, File Storage and Archive Storage.

Internet Gateway

Why it fails: An Internet Gateway provides public connectivity for instances in a VCN, not the encrypted tunnel terminating at the on-premises customer-premises equipment. It is tempting because internet reachability is often assumed necessary for VPN traffic, and it is correct when subnets need direct inbound or outbound public internet access, but IPsec VPN requires a DRG and CPE.

Local Peering Gateway

Why it fails: A Local Peering Gateway connects two VCNs within the same region, so it cannot terminate an IPsec tunnel from an on-premises data centre. It is tempting because peering is a common connectivity building block, and it is correct when linking VCNs in one region, but the scenario requires a Dynamic Routing Gateway plus CPE.

Availability domain identifier

Why it fails: An OCI IAM policy statement comprises subject, verb, resource and optional conditions; availability domains are placement constructs, not policy syntax. Naming a domain is tempting because ADs scope compute and storage resources, yet policies reference compartments and resource types instead.

Compute shape specification

Why it fails: Compute shape specifications belong to instance launch parameters, not to IAM policy grammar, which needs subject, verb and resource. Shapes are tempting because they define OCI compute capability, but no policy statement ever names a shape to grant access.

Local NVMe Storage

Why it fails: Local NVMe Storage is directly attached to a compute instance, providing ephemeral block-level storage, not file or object storage, so it fails the question's requirement. It tempts because it delivers very high IOPS for scratch data and temporary workloads, where low-latency local block access is genuinely the right choice.

OCI Block Volume

Why it fails: OCI Block Volume presents raw block devices attached to instances, so it is the block storage the question explicitly excludes, not file or object storage. It tempts because it underpins boot volumes and databases needing durable, resizable block devices, where block storage is genuinely the correct choice.

Boot Volume

Why it fails: A boot volume is block storage attached to an instance, holding the operating system image, not a file or object store. It is tempting because boot volumes are persistent and appear in storage listings alongside file and object services, yet they expose raw blocks over iSCSI rather than files or objects.

Every OCI region is guaranteed to have exactly three availability domains.

Why it fails: Availability domain count varies by region; some OCI regions offer a single availability domain, so a fixed three-domain guarantee misstates the architecture. It is tempting because three domains is the common layout in mature commercial regions, and that assumption would hold when designing resilience for a specific multi-AD region.

Regions span across multiple continents simultaneously.

Why it fails: An OCI region is a localised geographic area within one country or continent; it does not straddle continents, which is why customers pair regions for global reach. It is tempting because multi-region architectures do span continents, and that description would be accurate for a realm or a customer's overall deployment footprint.

Regions are logical constructs used exclusively for billing purposes.

Why it fails: Regions are physical geographic areas containing one or more availability domains; billing is handled through compartments, tenancy and cost-tracking tags, not region definitions. It is tempting because region selection affects pricing and data residency, and treating a region as a billing boundary would fit a cost-allocation discussion rather than an architectural one.

Compute Scaling Gateway

Why it fails: No such OCI gateway exists; scaling is handled by instance pools and autoscaling configurations, not a VCN-attached gateway. It tempts candidates because compute autoscaling is a real OCI capability, but that operates on instances rather than providing the VCN's network path to external or on-premises destinations.

Object Routing Gateway

Why it fails: OCI offers no Object Routing Gateway; object storage is reached through a service gateway or the internet gateway. The name tempts because service gateways do route traffic to OCI services such as Object Storage, but the actual attachable gateway is the service gateway, not a routing construct named for objects.

Local Storage Gateway

Why it fails: Local Storage Gateway is not an OCI VCN gateway; block and file storage attach to instances, not to the VCN itself. It tempts because OCI does offer storage gateway concepts for hybrid access, yet those are separate appliances, not gateways you attach to a VCN for routing.

Availability domains are purely logical constructs with no physical representation.

Why it fails: Availability domains are physically isolated data centres grouped within a region, each with independent power, cooling and network, so they do have physical representation. The logical construct is the fault domain. This statement would describe fault domains, which are logical groupings within an availability domain.

A single fault domain can span across multiple availability domains.

Why it fails: Fault domains are the grouping beneath an availability domain, so one cannot span several; each fault domain sits wholly inside a single AD. It tempts because fault domains do provide isolation from hardware failures within an AD, which is the correct answer when the question asks how to spread instances against rack-level outages.

Availability domains are shared across multiple distinct OCI regions.

Why it fails: Availability domains are isolated datacentres within one region and are never shared between regions; each region holds its own ADs. The option tempts because regions themselves are globally distributed and independent, so the idea of shared infrastructure sounds plausible when discussing resilience across geographies.

Using OCI Cloud Guard to deploy compute instances.

Why it fails: Cloud Guard detects and responds to misconfigurations and threats across a tenancy; it does not deploy compute instances. It is tempting because Cloud Guard can trigger remediation via Functions or Notifications, but provisioning instances belongs to Compute or Resource Manager, not a security posture service.

Using OCI Cost Analysis to write IAM policies.

Why it fails: Cost Analysis visualises and forecasts spending by compartment, tag, or service; it cannot author IAM policies. It is tempting because cost reporting is part of governance and both live under OCI's administration umbrella, yet policy authoring happens in IAM, not in the billing and cost tooling.

Using OCI Audit to create virtual cloud networks.

Why it fails: OCI Audit records API activity for compliance and security forensics; it cannot provision or organise network resources such as virtual cloud networks. It is tempting because Audit does track configuration changes across tenancies, but that visibility role is read-only logging, not infrastructure management.

Relying solely on a single availability domain with no redundancy.

Why it fails: A single availability domain shares power, cooling and network infrastructure, so a failure there takes down every instance regardless of redundancy within it. It is tempting because one AD suits dev/test workloads where cost outweighs resilience, but the stem demands fault tolerance across failure domains, which requires multiple availability domains or regions.

Placing all database and application instances in a single fault domain for faster local communication.

Why it fails: A single fault domain shares power and hardware with its availability domain peers, so an outage there takes down every instance together. It is tempting because co-locating instances reduces network latency, and would be correct when minimising inter-node latency matters more than surviving hardware failure.

Creating all resources in the root tenancy without compartments.

Why it fails: Compartments govern identity and access isolation and resource quotas, not physical placement or replication, so they add no fault tolerance. It is tempting because compartmentalised tenancy design is a governance best practice, and would be correct when the requirement is least-privilege access separation rather than availability.

Availability domains span across multiple global regions to provide high availability.

Why it fails: Availability domains are isolated data centres within a single region, not spanning multiple regions. The tempting idea is that ADs provide global high availability, but region-level resilience requires deploying across separate regions; ADs only protect against single-datacentre failures within one region.

Availability domains share physical power infrastructure to minimize data center costs.

Why it fails: Availability domains have independent power, cooling and network infrastructure precisely to isolate failures; sharing power would defeat that purpose. The tempting cost-saving logic misreads the design goal: ADs exist for fault isolation, so each maintains separate physical infrastructure rather than shared utilities.

Fault domains are software-defined constructs that exist across different availability domains.

Why it fails: Fault domains are hardware groupings within a single availability domain, not software-defined constructs spanning multiple ADs. The tempting association is that fault domains offer isolation like ADs, but that isolation is physical rack-level within one AD; cross-AD resilience comes from deploying across availability domains themselves.

Security Lists require an Internet Gateway to function, while NSGs require a NAT Gateway.

Why it fails: Security Lists and NSGs function independently of gateway types for packet filtering.

Security Lists can contain both stateful and stateless rules, while NSGs only support stateless rules.

Why it fails: Both Security Lists and NSGs support both stateful and stateless rules.

DenseIO Compute Instances

Why it fails: DenseIO shapes are VM or bare metal instances with local NVMe storage; they still expose an operating system you must administer, so they fail the no-OS-management requirement. They are tempting for storage-intensive databases needing high local IOPS, not for abstracting the OS away.

Bare Metal Compute Instances

Why it fails: Bare metal instances give you the physical server with no hypervisor layer, but you still own and patch the operating system, so the no-OS-management requirement fails. It is tempting because bare metal suits workloads needing direct hardware access, licensing constraints or maximum performance.

Standard Virtual Machine Compute Instances

Why it fails: Standard VM instances still require you to patch and administer the guest operating system, so they fail the no-OS-management requirement. They are tempting because VMs remove hypervisor management, which is the correct choice when you want infrastructure control but not physical hardware.