Select Two (Multi-Select) Questions

FSS is designed exclusively for single-instance high-performance computing (HPC) boot volumes.

Why it fails: FSS provides shared NFSv3 file systems mountable by many compute instances concurrently, not block volumes attached to one instance. Block Volume is the correct service for single-instance HPC boot volumes, which is why this option tempts: it swaps a shared file protocol for a single-attach block device.

FSS file systems can be natively mounted across multiple OCI regions simultaneously over the public internet.

Why it fails: FSS mounts over a regional private subnet within one region; cross-region access requires separate file systems plus replication or a remote mount, not native simultaneous multi-region public-internet mounting. Object Storage with cross-region replication fits that global-access requirement instead.

Snapshots created in FSS consume additional baseline storage that must be explicitly pre-allocated.

Why it fails: OCI File Storage Service snapshots utilise a copy-on-write mechanism that consumes only incremental capacity as modified blocks change, meaning they do not require any explicit pre-allocation of baseline storage. Administrators often confuse this dynamic space utilisation with block storage volume reservations or traditional provisioning models where capacity must be pre-configured. Consequently, this statement is tempting because fixed allocation models are standard practice in other storage tiers such as Block Storage, where pre-provisioning dedicated performance and capacity units is required before creating point-in-time copies.

Compute Instance

Why it fails: The Events service streams to topics consumed by Functions, Notifications, and Streaming, not to a Compute Instance as a destination. It is tempting because instances generate and consume events, but the service publishes to supported targets; an instance would need to subscribe via a stream rather than being a destination itself.

Object Storage

Why it fails: Object Storage cannot be configured as an Events rule destination; the service delivers to Functions, Notifications, and Streaming only. It is tempting because Object Storage is a common target for event-driven archival, but that requires a Function to receive the event and then write the object.

Compress

Why it fails: Object Storage lifecycle rules in Oracle Cloud Infrastructure do not support compression as an automated tiering or archiving action, rendering this choice invalid regardless of the data retention schedule. It appears tempting because compression is a standard storage optimisation technique used to reduce data footprints and lower capacity costs for infrequently accessed files. In an environment where manual file management or compute-level archiving scripts are executed before upload, compressing objects prior to ingestion is common practice to minimise storage consumption.

Encrypt

Why it fails: Object Storage lifecycle policies manage data retention and cost optimization through automated tiering, archiving, and deletion rules, whereas encryption operates as a security control managed separately via Oracle Cloud Infrastructure Vault keys rather than scheduled state transitions. This action is tempting because administrators routinely combine data protection mandates with retention workflows when defining security compliance frameworks. Encryption would be the correct choice if you were establishing initial data-at-rest cryptographic keys or rotating secrets for buckets, but it falls outside the scope of automated lifecycle state management.

Service Gateway

Why it fails: An OCI Site-to-Site VPN terminates traffic at a Dynamic Routing Gateway rather than a Service Gateway, rendering the latter incorrect for establishing tunnel connections. A Service Gateway is tempting because it provides private access to Oracle Cloud Infrastructure services like Object Storage without traversing the public internet, making it the correct choice when configuring private service endpoints for subnets within a virtual cloud network, but it lacks the IPsec tunnel termination capabilities required for hybrid networking.

Local Peering Gateway (LPG)

Why it fails: A Local Peering Gateway facilitates traffic exchange between two Virtual Cloud Networks (VCNs) within the same region, making it tempting if you conflate VCN-to-VCN connectivity with hybrid cloud architectures. It fails this scenario because it cannot terminate IPSec tunnels or route traffic between an on-premises data centre and Oracle Cloud Infrastructure, lacking the required Dynamic Routing Gateway attachment that establishes external IPsec connections.

NAT Gateway

Why it fails: A NAT Gateway provides outbound internet connectivity for resources within a private subnet without exposing them to inbound internet traffic, making it tempting if you incorrectly assume that cloud-to-on-premises traffic traversal requires address translation. However, it fails in this scenario because setting up an OCI Site-to-Site VPN with redundant tunnels requires a Dynamic Routing Gateway (DRG) attached to your Virtual Cloud Network, whereas a NAT Gateway operates exclusively at the subnet route table level for internet-bound traffic and cannot terminate IPsec VPN tunnels.

Block-level multi-attach with read-write access across availability domains

Why it fails: Oracle Cloud Infrastructure File Storage Service relies on the Network File System (NFS) protocol rather than block storage architecture, meaning it cannot provide block-level multi-attach capabilities across availability domains. Block-level multi-attach is actually designed for OCI Block Volume, which allows a single block volume to be attached to multiple compute instances simultaneously with read-write access for clustering scenarios like Oracle Real Application Clusters (RAC) or shared-disk failover configurations.

Automatic tiering from file storage to Archive Storage

Why it fails: Oracle Cloud Infrastructure File Storage Service does not natively execute automated lifecycle policies to transition active file systems directly into Archive Storage tiers. This functionality would be tempting because administrators frequently seek automated cost-optimisation strategies to migrate infrequently accessed unstructured data from high-performance storage into lower-cost cold storage tiers. Such lifecycle management features are typically implemented within Object Storage buckets using object lifecycle rules, rather than within the Network File System (NFSv3) mount targets managed by the File Storage Service.

Native integration with Block Volume replication policies

Why it fails: OCI File Storage Service manages Network File System exports and does not integrate with Block Volume replication policies, which operate exclusively at the block storage layer for boot and data volumes. This option is tempting because administrators frequently configure cross-region data protection workflows for multiple storage tiers simultaneously, making block-level replication policies the correct choice when securing high-performance block volumes against regional disasters.

Maintenance events cause permanent data loss on attached boot volumes.

Why it fails: Instance maintenance events only require a reboot or migration of the virtual machine host, preserving all data on attached block storage and boot volumes rather than destroying it. This misconception arises because administrators often confuse infrastructure host retirement with local ephemeral storage decommissioning, where data residing on non-persistent local NVMe drives is indeed wiped during a reboot cycle. The statement would be correct if the architecture relied entirely on ephemeral local disks instead of durable, network-attached block volumes.

Instance maintenance events can only be managed using Terraform scripts.

Why it fails: Terraform is designed for infrastructure as code automation and can indeed provision or modify compute resources, but it is not the exclusive interface for managing Oracle Cloud Infrastructure instance maintenance events. Administrators frequently find this option tempting because infrastructure teams rely heavily on Terraform to orchestrate cloud environments and manage lifecycle states programmatically. It would be the correct choice if the scenario specifically required automating the initial deployment configuration or applying structural changes to infrastructure components via automated pipelines, rather than responding to native OCI control plane notifications and scheduled maintenance windows.

Customers have zero visibility into hardware retirement schedules and cannot take preemptive action.

Why it fails: Oracle Cloud Infrastructure actually provides customers with advance notifications and scheduled maintenance tracking for upcoming hardware retirements, allowing administrators to proactively migrate workloads before downtime occurs. This statement appears plausible because cloud providers historically managed underlying infrastructure completely behind the scenes without user intervention, a model that *would* apply if OCI operated as a black-box service offering no transparency into physical host lifecycles or operational scheduling.

Modify the underlying physical CPU hardware model of the hypervisor.

Why it fails: Physical server hardware specifications and hypervisor host configurations are exclusively managed by Oracle Cloud Infrastructure at the infrastructure layer, meaning customers cannot access or modify underlying host processors. Administrators often assume they have low-level hypervisor access because they configure database node shapes and scale vCPU counts within Oracle Base Database Service. However, compute sizing changes are performed through managed software interfaces rather than by altering physical CPU models on the hypervisor.

Delete the DB home while keeping all associated databases running unaffected.

Why it fails: A DB home cannot be deleted while its databases remain running; deletion requires the associated databases to be terminated or moved first. The option tempts because DB homes and databases are separate resources, but the dependency is enforced, so the DB home deletion cascades or is blocked.

Convert the database home into an Autonomous Container Database.

Why it fails: Oracle Base Database Service manages traditional virtual machine and bare metal database deployments where database homes run standard Oracle Database software rather than the specialised Exadata infrastructure required for Autonomous Databases. This option appears tempting because administrators frequently perform lifecycle management and architectural conversions on database homes. However, converting to an Autonomous Container Database is exclusively supported on Exadata Database Service infrastructure rather than standard Oracle Base Database Service VM or bare metal instances.

Send email notifications when an object storage bucket size exceeds a threshold.

Why it fails: Resource Manager stacks manage infrastructure-as-code lifecycle operations rather than monitoring storage metrics or triggering alerts. This option is tempting because OCI Events and Notifications services are the standard mechanisms for tracking bucket capacity and sending alerts when thresholds are breached. While Resource Manager automates the deployment and configuration of OCI resources using Terraform, it lacks the native telemetry integration required to monitor real-time object storage metrics or execute event-driven notification workflows based on capacity changes.

Create custom time-series metric alarms to monitor CPU and memory utilization.

Why it fails: Resource Manager stacks manage infrastructure-as-code deployments using Terraform, whereas metric alarms are configured exclusively within the OCI Monitoring service. While users often conflate infrastructure automation with operational observability, Resource Manager lacks the native integration to define or manage alarm thresholds. This option is tempting because administrators frequently need to monitor the performance of provisioned resources; however, such monitoring configurations reside within the Monitoring service API or console, rather than the declarative state files handled by Terraform stacks.

Automatically ingest and parse custom application log files from compute instances.

Why it fails: Resource Manager stacks manage infrastructure-as-code lifecycles via Terraform, whereas log ingestion requires the OCI Logging service and the Logging agent. This option is tempting because developers often need to centralise application logs for monitoring and troubleshooting. You would utilise the OCI Logging service to collect and parse custom logs from compute instances, as it provides the specific ingestion pipelines and parsing configurations necessary for log management, a functionality entirely outside the scope of Terraform-based infrastructure orchestration.

Internet Gateway

Why it fails: An Internet Gateway handles public traffic between an OCI virtual cloud network and the public internet, meaning it lacks the private routing capabilities required to connect a private subnet to an on-premises datacenter via FastConnect. It appears tempting because it serves as the primary edge routing component for external network connectivity within a tenancy, and it would be the correct choice if you needed to allow resources inside a public subnet to communicate directly with external public IP addresses over the internet.

Local Peering Gateway

Why it fails: A Local Peering Gateway (LPG) is designed exclusively to enable VCN peering between two Virtual Cloud Networks within the same region and tenancy, rather than connecting to an on-premises data centre. Although it functions as a gateway component for traffic routing, an LPG cannot peer a cloud network with an external physical environment. Consequently, it appears tempting because administrators frequently associate it with routing traffic across discrete network boundaries, making it a natural administrative choice when erroneously confusing internal VCN peering with external hybrid connectivity mechanisms like Dynamic Routing Gateways.

NAT Gateway

Why it fails: A Network Address Translation (NAT) Gateway is designed to enable outbound internet access for resources residing in a private subnet while blocking inbound connections from the internet, meaning it plays no role in private hybrid routing. It often tempts candidates because it handles traffic routing for private subnets, but it is exclusively intended for public internet connectivity rather than establishing private, high-bandwidth circuits to an on-premises data centre via FastConnect.

A fully configured Autonomous Data Warehouse

Why it fails: Autonomous Data Warehouses are pre-configured managed database services that must be explicitly provisioned by a user, meaning they are never automatically generated upon the creation of a brand-new Oracle Cloud Infrastructure tenancy. They are tempting because they represent a core, heavily utilised cloud service that administrators frequently deploy during initial environment setup. Consequently, an Autonomous Data Warehouse would be the correct choice when a project specifically requires a high-performance, fully managed analytical database for running complex SQL queries and business intelligence workloads.

A 10TB Object Storage archive bucket

Why it fails: Oracle Cloud Infrastructure does not provision pre-configured Object Storage archive buckets upon tenancy creation, as storage resources must be explicitly generated by administrators based on specific capacity and durability requirements. Archive storage is tempting because it provides long-term, low-cost data retention for infrequently accessed compliance records, making it the correct choice when you need to archive database backups or regulatory logs over multi-year lifecycles.

A pre-configured Kubernetes production cluster

Why it fails: Freshly provisioned Oracle Cloud Infrastructure tenancies contain solely foundational components like identity domains and root compartments, omitting any ready-made container orchestration engines. Beginners often assume a turnkey Kubernetes cluster is automatically deployed to allow immediate containerised workload hosting without manual cluster provisioning. Such a production-grade cluster becomes the correct choice only after explicitly deploying OCI Container Engine for Kubernetes through the console or API to manage microservice applications.

Fast Storage

Why it fails: Fast Storage is not a valid tier within Oracle Cloud Infrastructure Object Storage, making it completely invalid for this scenario. This distracter is tempting because engineers frequently associate high-performance input/output operations with disk or block storage architectures. It would be a logical choice if the requirement specified high-performance Block Storage volumes utilising NVMe drives for database workloads demanding ultra-low latency, but Object Storage explicitly relies on Standard and Archive tiers rather than performance-branded tiers.

Temporary Storage

Why it fails: Temporary Storage is invalid because Oracle Cloud Infrastructure Object Storage provides only Standard and Infrequent Access tiers, lacking any temporary classification for short-lived data. It is tempting because developers often require transient scratch space for intermediate processing tasks or short-term caching during data pipelines, where data is intended to be discarded automatically after a brief lifecycle. In an actual architectural scenario, ephemeral block volumes or local NVMe storage would serve this function for high-performance compute instances rather than object storage.

Cold Storage

Why it fails: OCI Object Storage provides Standard and Infrequent Access tiers, whereas "Cold Storage" is not an official tier nomenclature within this service, making this option invalid for cloud-based data placement. Cloud architects often confuse this distractor with Archive Storage—which is designed for long-term retention of rarely accessed data—making it tempting when designing compliance archives or disaster recovery vaults that require minimal retrieval frequency over multi-year lifecycles.

employee-badge-readers

Why it fails: Physical hardware devices such as employee badge readers operate entirely outside the scope of Oracle Cloud Infrastructure Identity and Access Management, which governs purely cloud-native computing and storage resources. This choice appears plausible because administrators frequently seek to control physical access permissions alongside cloud security policies within unified enterprise identity frameworks. Such physical hardware integration typically requires specialised Internet of Things management platforms or physical access control systems rather than standard OCI compartment-level governance policies.

corporate-laptop-hardware

Why it fails: Physical hardware assets such as laptops fall outside the scope of Oracle Cloud Infrastructure Identity and Access Management policies, which exclusively govern cloud-hosted resources within your tenancy. This option is tempting because administrators frequently need to control physical device access or integrate corporate endpoints with cloud environments, which would typically be achieved using endpoint management tools like Microsoft Intune combined with Microsoft Entra ID for identity federation, rather than cloud compartment policies.

office-wifi-routers

Why it fails: Physical network hardware such as office-wifi-routers exists entirely outside the boundary of Oracle Cloud Infrastructure cloud-native services, meaning cloud-level Identity and Access Management policies cannot govern on-premises enterprise infrastructure. This option appears tempting because administrators frequently conflate physical office network hardware access control with cloud network security lists or virtual cloud network routing, where device management policies are traditionally applied in local enterprise scenarios.

Bucket

Why it fails: Buckets belong exclusively to OCI Object Storage rather than the File Storage Service, making this choice incorrect because buckets organise unstructured flat data accessed via REST APIs rather than hierarchical file systems mounted via the Network File System protocol. This option is tempting because it is a fundamental OCI data persistence construct frequently utilised for cloud storage architectures, and it would be the correct choice if the question asked for the foundational containers used to store objects in Object Storage.

Backup gateway

Why it fails: A backup gateway is an on-premises appliance used to route and transfer data to Oracle Cloud Infrastructure Object Storage, making it tempting because it handles enterprise data protection tasks. However, it fails in this scenario because the File Storage Service relies on Network File System (NFS) mounts and mount targets for direct file-level access rather than block-level backup streaming architectures. It would be the correct choice when configuring hybrid disaster recovery pipelines that require archiving on-premises backup sets directly to Object Storage buckets.

Modify the operating system kernel source code

Why it fails: Modifying the operating system kernel source code requires low-level system access and source compilation tools that are restricted on Oracle Base Database Systems, where Oracle manages the underlying OS and hypervisor layers to maintain platform stability and security compliance. This option appears plausible because database administrators frequently need to tune kernel parameters—such as shared memory limits or semaphore allocations—to optimise enterprise workloads, a legitimate administrative task that is actually performed by modifying runtime parameters in `/etc/sysctl.conf` rather than recompiling the kernel itself.

Directly modify Oracle internal data dictionary tables

Why it fails: Direct modification of Oracle internal data dictionary tables is restricted to prevent structural corruption and bypasses supported database management interfaces. Database administrators often need to inspect internal metadata for troubleshooting or performance tuning through SQL queries. However, executing direct data manipulation language (DML) or data definition language (DDL) statements against SYS-owned dictionary tables is strictly prohibited by Oracle architecture and cannot be performed through the Oracle Cloud Infrastructure Console. Administrative tasks must instead utilise standard PL/SQL packages, Oracle Enterprise Manager, or documented SQL commands.

Rename the underlying VCN OCID

Why it fails: Oracle Cloud Infrastructure assigns a globally unique, immutable Oracle Cloud Identifier (OCID) to every Virtual Cloud Network automatically at creation, meaning this resource string cannot be modified afterwards. Although administrators frequently attempt to reorganise naming conventions or align resources with updated corporate taxonomies, OCIDs function as permanent backend identifiers that remain hardcoded into tenancy architecture and API references. Consequently, while you can easily update the user-friendly display name of a VCN post-creation, the underlying system-generated OCID is fixed for the entire lifecycle of that cloud network.

Modify the primary CIDR block of the VCN

Why it fails: Oracle Cloud Infrastructure does not permit the modification or resizing of a VCN's primary CIDR block once the network is created. Administrators often attempt this when expanding an existing subnet architecture requires a broader IP address range. It remains a tempting choice because you can add secondary CIDR blocks to an already provisioned VCN to accommodate growing workloads, making it seem logical to alter the original block when initial sizing proves insufficient.

Convert a regional subnet into an Availability Domain-specific subnet

Why it fails: Subnets in Oracle Cloud Infrastructure cannot have their scope altered from regional to Availability Domain-specific post-creation; subnet scope must be defined at creation time and remains immutable. Administrators often attempt this conversion when seeking to isolate workloads to a single data centre for strict latency or compliance requirements, a design choice that is valid only when configuring a new subnet from scratch rather than modifying an existing one.

Identity Domains replace Virtual Cloud Networks entirely.

Why it fails: Identity Domains handle user lifecycles, authentication policies, and OAuth-based application integrations, whereas Virtual Cloud Networks operate at the infrastructure layer to provide isolated IP address spaces, routing tables, and subnet architectures for compute instances. This option appears plausible because cloud architects frequently encounter both constructs when provisioning secure multi-tier environments. It would be the correct choice if the requirement specified configuring software-defined networking, peering connections, or internet gateways to govern packet-level routing across cloud resources rather than managing user identities and access control.

Every tenancy is restricted to having exactly one Identity Domain that cannot be changed.

Why it fails: Tenancies are not permanently restricted to a single Identity Domain; Oracle Cloud Infrastructure actually supports multiple domains per tenancy to help organisations segregate user populations across different departments or regions. This statement appears plausible because the Default Identity Domain is automatically provisioned during tenancy creation to handle initial administrative access and basic user management. It would be correct in a simplified enterprise scenario where a single centralised directory structure completely satisfies all authentication and governance requirements without needing administrative isolation.

Identity Domains store compute instance virtual disk images.

Why it fails: Identity Domains hold users, groups, apps and policies for authentication and authorisation; they never store compute images. Object Storage and Block Volume handle image storage. Identity Domains are tempting because they centralise identity artefacts, but virtual disk images fall outside their scope entirely.

Flow logs are only supported on public subnets.

Why it fails: Flow logs capture IP traffic for any virtual network interface card (VNIC) within a Virtual Cloud Network, meaning they function equally on private subnets, public subnets, and even DRG attachments rather than being restricted to public-facing architecture. This option is tempting because network traffic monitoring is frequently associated with internet gateways and public-facing perimeter security where visibility into inbound edge traffic is critical. However, administrators routinely configure flow logs on private subnets to troubleshoot internal database connectivity, inter-tier application communication, and compliance auditing across isolated backend workloads.

Flow logs automatically encrypt your database data at rest.

Why it fails: VCN Flow logs capture network traffic metadata for security analysis and troubleshooting rather than performing storage-level encryption for databases. This option is misleading because Transparent Data Encryption (TDE) is the specific OCI feature that handles automatic encryption of database data at rest. While TDE protects sensitive information within database files, Flow logs operate exclusively at the network layer to record packet flow information, making them entirely irrelevant to the encryption of persistent database storage.

Flow logs require an Internet Gateway to export logs out of the VCN.

Why it fails: Exporting OCI VCN Flow Logs does not require an Internet Gateway because flow logs are natively published to Oracle Cloud Infrastructure Logging service via internal service endpoints rather than traversing public internet routes. This statement seems plausible because an Internet Gateway is traditionally required for resources within a VCN to communicate with external public destinations. That gateway mechanism WOULD be the correct choice if you needed to route standard outbound traffic from private subnets to the wider public internet or external third-party SIEM endpoints situated outside the OCI tenancy.

A Local Peering Gateway (LPG) bridging the VPN tunnel to the database subnet

Why it fails: Local Peering Gateways facilitate connectivity exclusively between Virtual Cloud Networks within the same region, meaning they lack the functionality to terminate or route traffic for external IPsec VPN tunnels. Candidates often confuse this with the DRG, which serves as the central hub for all hybrid connectivity. You would utilise an LPG specifically when establishing private, low-latency communication between two distinct VCNs that require internal resource sharing without traversing the public internet or requiring an external VPN gateway.

An Internet Gateway attached to the private subnets handling the VPN traffic

Why it fails: An Internet Gateway handles public internet traffic for resources residing in public subnets, whereas an IPsec VPN tunnel terminates directly on a Dynamic Routing Gateway rather than passing through public routing constructs. This distractor appears plausible because administrators frequently associate routing external traffic with an Internet Gateway when connecting a Virtual Cloud Network to external endpoints. However, it would be the correct component only if the requirement explicitly involved establishing direct public internet access for resources via a public subnet, rather than building a private encrypted hybrid tunnel.

Google Cloud Persistent Disk

Why it fails: Google Cloud Persistent Disk is designed to provide block storage for workloads running natively within the Google Cloud Platform, offering seamless integration with Compute Engine instances. However, it fails in this scenario because an Oracle Base Database System must be provisioned on Oracle Cloud Infrastructure, which natively utilises OCI Block Volume or OCI Database File System storage architectures. Consequently, cross-cloud storage attachment of foreign block devices to Oracle-managed database nodes is not supported.

Local floppy disk drives

Why it fails: Legacy physical media emulation is fundamentally obsolete for modern cloud-native database architecture and entirely unsupported by Oracle Cloud Infrastructure provisioning workflows. However, administrators accustomed to bare-metal hypervisors or legacy on-premises virtualisation platforms might mistakenly expect virtual floppy drives to remain available for mounting basic bootstrap configuration scripts, unattributed OS response files, or legacy license keys during initial system deployment.

Amazon S3 object storage buckets

Why it fails: Oracle Base Database Systems rely exclusively on Oracle Cloud Infrastructure Block Volume service for high-performance database storage and Oracle Cloud Infrastructure File Storage service for shared file systems, meaning external third-party cloud storage endpoints cannot be attached natively during the provisioning workflow. This choice appears plausible because database administrators frequently utilise object storage for general data backups, archiving, and cross-platform data migration. Therefore, object storage buckets would be the correct choice if you were configuring long-term backup retention repositories or off-site data staging areas rather than the primary operational storage volumes required for active database files.

Automatic packet filtering like a Next-Gen Firewall

Why it fails: OCI Load Balancer functions as a Layer 4 to Layer 7 traffic distribution service rather than a deep packet inspection engine. It lacks the stateful, application-aware security inspection required for next-generation firewall capabilities. This option appears attractive because users often confuse traffic management with network security; however, advanced packet filtering and intrusion prevention are the specific domains of the OCI Network Firewall or third-party virtual appliances, which provide the granular threat detection and protocol analysis that the standard Load Balancer service does not perform.

Direct database query routing without backend compute instances

Why it fails: OCI Load Balancer distributes TCP/HTTP traffic to backend compute instances; it cannot query databases directly. It is tempting because load balancers route requests, but backend sets must reference compute resources, so database query routing without instances is unsupported.