Storage practice questions

Higher Performance

Why it fails: Selecting the Higher Performance level enables the administrator to dynamically scale IOPS and throughput far beyond the limits imposed by the default base capacity without needing to detach the volume. This capability directly satisfies the requirement for high IOPS and low latency while accommodating fluctuating database workloads in real-time. By adjusting the volume's performance tier independently of its storage size, the application maintains continuous availability and optimal database file performance during peak enterprise usage periods.

Lower Cost

Why it fails: Lower Cost performance lacks the high IOPS and dynamic throughput scaling required by demanding enterprise databases, failing to provide the performance tiers necessary for heavy transactional workloads without volume detachment. However, it is tempting because administrators often seek to minimise operational expenditure for non-critical storage environments. This level is designed for boot volumes, development or test databases, and low-throughput applications where cost optimisation takes priority over raw storage performance.

Balanced

Why it fails: Balanced is used for workloads that balance performance and cost, such as boot volumes and general-use databases.

Attach the Block Volume to multiple instances simultaneously across availability domains.

Why it fails: Block Volume attachments are single-instance (or read-only shareable) block devices, not an NFS file system, so they cannot present the FSS mount across three availability domains. Block volumes are the right choice for low-latency database or boot disks on one instance.

Create a separate FSS file system in each availability domain and peer them.

Why it fails: FSS file systems are regional and mountable from every availability domain in the region, so duplicating per-AD file systems and peering them adds needless replication and no shared namespace. Separate file systems suit isolation requirements, not cross-AD access to one dataset.

Use an OCI FastConnect circuit to route NFS traffic between availability domains.

Why it fails: FastConnect provides private connectivity from on-premises networks to OCI, not routing between availability domains inside a region; intra-region traffic already traverses the OCI network. FastConnect is correct when linking a customer data centre to a VCN.

Configure an event rule in OCI Events Service to trigger a function that modifies the storage tier after 30 days.

Why it fails: Lifecycle policies are built directly into Object Storage and do not require custom Event/Functions pipelines.

Set the bucket storage policy to automatically purge objects after 365 days and use Object Versioning to handle the 30-day tier shift.

Why it fails: Object Versioning manages historical states and protects against accidental deletion rather than controlling storage tier transitions, meaning it cannot shift data to the Infrequent Access tier after 30 days. It is tempting because versioning is frequently used alongside lifecycle policies to handle object retention and cleanup over extended periods, and it would be the correct choice if the requirement was strictly to preserve previous iterations of overwritten or deleted files while managing deletion timelines independently of storage tiers.

Create two separate rules: one for transition at 30 days and another rule evaluated independently for deletion at 335 days.

Why it fails: Deletion timing in lifecycle rules is calculated from the object creation date, meaning the second rule would need to specify 365 days, not 335.

The VCN lacks an Internet Gateway, and traffic is attempting to go over the public internet.

Why it fails: Access to Object Storage via a Service Gateway bypasses the internet, but lack of an IGW wouldn't cause 403s if internal routing is correct.

The bucket name is not globally unique within the tenancy.

Why it fails: OCI prevents duplicate bucket names within a namespace, so creation would fail rather than yielding a runtime 403 on GET.

The Object Storage bucket is configured in the Infrequent Access tier instead of Standard.

Why it fails: Choosing the Infrequent Access storage tier affects cost optimization and retrieval pricing rather than access control enforcement, meaning it does not alter permissions or trigger HTTP 403 Forbidden responses. This option is tempting because administrators often suspect tiering configurations when encountering unexpected bucket behaviour, and it would be the correct choice if the troubleshooting scenario involved unexpected storage expenditure or lifecycle management rule failures rather than authorisation blocks.

10 TiB

Why it fails: Wait, the maximum size for a single PUT object upload is 50 GiB, while the total object size using multipart upload can reach 10 TiB. Let's ensure precision. Single PUT request limit is 50 GiB.

5 TiB

Why it fails: 5 TiB is not the single PUT limit.

100 GiB

Why it fails: Uploading an object of this magnitude via a standard single-part PUT operation exceeds the strict hard limit enforced by the OCI Object Storage service, which restricts single-request uploads to a maximum of 50 GiB. Nevertheless, this capacity appears tempting because 100 GiB represents the maximum individual part size permitted when you structure data transfers as a multipart upload, making it the correct sizing threshold for an individual constituent chunk within a segmented upload workflow rather than an atomic upload request.

Manually export the volume to an Object Storage bucket and download it in the second region.

Why it fails: Exporting a block volume backup to an Object Storage bucket and manually downloading it across regions fails this scenario because it requires direct, unautomated human intervention rather than providing a continuous, event-driven automation pipeline for disaster recovery. This approach is tempting because it serves as a valid mechanism for long-term archival storage or cross-tenant sharing of raw volume data where automated synchronization policies are not needed.

Configure an OCI Object Storage lifecycle rule to replicate files across regions.

Why it fails: OCI Object Storage lifecycle rules manage the automated tiering or deletion of objects within a bucket based on age, which fails here because block volume backups in Oracle Cloud Infrastructure are managed natively through block volume policies rather than standard bucket objects. This option is tempting because lifecycle rules do handle automated data management across regions for disaster recovery, making them the correct choice when you need to automate cross-region replication for objects stored directly within Object Storage buckets rather than block volume archives.

Write an OCI Data Flow application to stream volume blocks across regions.

Why it fails: OCI Data Flow is designed for running Apache Spark applications to process large-scale batch data, making it tempting for developers accustomed to writing custom code for data movement tasks. However, it fails in this scenario because it cannot directly access or manage Oracle Cloud Infrastructure Block Volume block storage layers to copy backups across regions. Instead, the correct approach requires leveraging native cross-region copy policies configured directly within Block Volume service backups or using OCI Events paired with Oracle Functions to automate the native replication API calls.

OCI Data Transfer Appliance

Why it fails: Data Transfer Appliance is a physical offline data shipping device, not a network-based transfer tool.

OCI File Storage Service Mount Target

Why it fails: FSS mount targets are for cloud-native NFS access, not on-premises to cloud migration gateway caching.

OCI Archive Storage Uploader

Why it fails: No such dedicated standalone service exists by that exact name.

Object Storage provides eventual consistency for bucket listing operations.

Why it fails: OCI Object Storage provides read-after-write consistency for all operations (PUT, GET, DELETE, and bucket listings), not eventual consistency.

Objects larger than 50 GiB must be stored using Block Volume instead.

Why it fails: Object Storage natively supports individual objects up to 10 TiB in size through automated multipart uploads, rendering a 50 GiB limit false. Block Volume is designed for persistent block-level storage attached to compute instances to serve as boot drives or high-performance file systems running databases. Therefore, Block Volume would be the correct choice when you require low-latency, random I/O access for a mounted file system rather than scalable, flat-namespace object retention.

Full backups must be manually triggered because policies only support incremental backups.

Why it fails: Volume backup policies in Oracle Cloud Infrastructure explicitly support the scheduling of both incremental and full backups, rendering the claim that they are limited to incremental backups factually inaccurate. This option appears plausible because manual backups are indeed a valid method for creating full snapshots when an immediate, ad-hoc point-in-time recovery is required outside of a defined policy schedule. However, relying solely on manual triggers ignores the automated lifecycle management capabilities provided by the policy-based backup engine.

Block volume backups are stored in File Storage Service file systems by default.

Why it fails: Block volume backups reside exclusively within the OCI Object Storage service, not the File Storage Service. This option appears logical because the File Storage Service provides a managed, scalable network file system, which is a common destination for general-purpose data backups or shared storage workloads. However, OCI Block Volume backups are architected as point-in-time snapshots managed by the Block Volume service, which automatically offloads these data blocks to Object Storage to ensure durability and regional availability.

Block Volume Replication

Why it fails: Block Volume Replication facilitates disaster recovery by asynchronously copying block storage data between OCI regions, but it lacks the immutable WORM (Write Once, Read Many) capabilities required for regulatory compliance. It is designed for high availability and business continuity in the event of regional outages rather than enforcing data retention policies. While it ensures data persistence across geographical locations, it does not prevent administrators from modifying or deleting the underlying volumes, failing to meet the strict non-repudiation mandates specified in the scenario.

IAM Policy with Deny DELETE statements

Why it fails: IAM policies can be modified by tenancy administrators, meaning they do not provide immutable WORM compliance guarantees.

Object Storage Bucket Access Policy with Read-Only permissions

Why it fails: Access policies can restrict user access, but administrators can still modify or delete the policy and objects.

Copy the backup to the target region first, then restore it.

Why it fails: Cross-region copies are only necessary if restoring to a different OCI region; backups are region-wide within their home region.

Export the backup to an Object Storage bucket, download it on-premises, and re-upload it to the new AD.

Why it fails: Exporting a block volume backup to Object Storage and downloading it on-premises introduces an unnecessary, highly inefficient data transfer loop across the internet when simply moving data between Availability Domains within the same region. This roundabout workflow is actually intended for cross-region disaster recovery, migrating data to an entirely separate Oracle Cloud Infrastructure region, or archiving backup data outside the cloud environment for long-term off-site compliance.

Create a volume clone in the source AD and attach it across ADs.

Why it fails: Creating a volume clone in the source Availability Domain relies on live block storage infrastructure rather than using the requested encrypted block volume backup artefact to cross Availability Domain boundaries. This approach appears attractive because volume cloning generates an independent, usable copy of data within Oracle Cloud Infrastructure, which is the correct method for duplicating active block volumes within the same data centre or snapshotting a workload for immediate local attachment. However, it fails in this scenario because a volume backup must be restored directly as a new volume in the target Availability Domain, rather than attempting to clone and cross-attach an active volume between Availability Domains.

Block Volume Performance Level 'Lower Cost'

Why it fails: Block Volume Lower Cost is designed for boot volumes and secondary block storage requiring persistent block-level access rather than object storage archiving, failing the requirement for cost-effective mass data retention. It is tempting because its lower cost branding sounds appropriate for budget-conscious archiving, and it represents a valid choice when you need affordable block storage for infrequently accessed virtual machine attachments that still demand high-performance input/output operations per second.

Object Storage Standard Tier

Why it fails: Standard tier is designed for active data that requires frequent access and has higher storage costs.

Object Storage Infrequent Access Tier

Why it fails: Infrequent Access is optimized for data accessed less frequently than standard storage, but Archive offers lower cost for deep archive.

Volume Group Backup Policy

Why it fails: Volume Group Backup Policies manage the automated lifecycle and retention schedules for block storage snapshots rather than regulating network traffic or file-level access. This option appears relevant because administrators frequently manage data protection strategies alongside security configurations within the Oracle Cloud Infrastructure console. However, it remains entirely decoupled from the Export Options or NSG rules required to restrict mount targets, serving exclusively to automate data recovery workflows for block volumes rather than enforcing network-level access control for file systems.

IAM Dynamic Groups

Why it fails: IAM dynamic groups handle authentication for compute instances calling OCI APIs, not NFS mount access.

Bucket Access Policy

Why it fails: Bucket Access Policies manage identity-based permissions for Object Storage buckets rather than network-level access for file systems. While this option appears relevant because it governs resource authorisation, it functions exclusively within the Object Storage service to control API-level access to objects. It is the correct choice only when configuring granular, identity-centric access control for data stored in Object Storage buckets, whereas File Storage Service relies on Export Options and network security rules to manage connectivity from compute instances.

Encryption

Why it fails: Encryption secures data at rest by transforming it into ciphertext, ensuring confidentiality against unauthorised physical or logical access to the underlying storage media. It does not govern network-level traffic or validate the origin of requests based on Virtual Cloud Network (VCN) membership. This option is frequently confused with security controls because it protects data integrity; however, it is the correct choice only when the requirement is to satisfy regulatory compliance for data privacy or to protect against unauthorised decryption of stolen storage volumes.

Object Versioning

Why it fails: Object Versioning manages data lifecycle and recovery by retaining multiple variants of an object, whereas it provides no mechanism to filter network traffic or restrict access based on Virtual Cloud Network (VCN) origin. It is a tempting distractor because administrators often enable it to protect against accidental deletions or overwrites in production environments. You would select this feature when your primary requirement is to maintain a historical audit trail of file modifications or to facilitate data restoration after unintended user actions.

Lifecycle Rules

Why it fails: Lifecycle rules manage the automated transition of objects between storage tiers or their permanent deletion based on age or versioning status. While they provide essential cost optimisation and data retention automation for bucket contents, they lack any mechanism to evaluate network-level request origins. This option is tempting because it involves bucket-level configuration, but it is exclusively designed for data lifecycle management rather than the network security policies required to restrict access based on Virtual Cloud Network (VCN) source identifiers.

Archive Storage

Why it fails: Archive Storage introduces significant latency due to its time-to-first-byte delay, which prevents the immediate, high-speed data access required for real-time big data processing. While it provides a cost-effective solution for long-term data retention and regulatory compliance, its architecture prioritises durability and low expenditure over performance. Consequently, it remains the optimal selection for cold storage scenarios where data is rarely accessed and retrieval times of several hours are acceptable, rather than for active, high-throughput analytical workloads.

Block Volume

Why it fails: Block Volume provides the high-performance, low-latency block storage required for big data workloads by allowing users to scale throughput dynamically based on volume size and performance units. By leveraging high-performance NVMe-based storage backends, it delivers the consistent, high-bandwidth input/output operations necessary for intensive data processing tasks. This service satisfies the big data requirement for high throughput by offering adjustable performance tiers, ensuring that compute instances can access massive datasets with the sustained data transfer rates essential for analytical processing.

File Storage

Why it fails: File Storage relies on the NFS protocol, which introduces latency overheads that hinder the massive, parallelised I/O operations necessary for high-throughput big data processing. While it provides a POSIX-compliant, shared file system architecture that excels in scenarios requiring concurrent access to shared data across multiple compute instances, such as enterprise content management or shared application configurations, it lacks the raw, low-latency block-level throughput performance required to handle the intensive data ingestion and processing demands typical of large-scale big data analytics clusters.

Unlimited

Why it fails: Oracle Cloud Infrastructure Object Storage enforces a strict per-object capacity limit of 10 TiB, meaning a single file cannot grow without bound. This choice appears attractive because standard cloud storage architectures frequently promote infinite scalability as a core design principle to eliminate capacity planning overhead. In scenarios involving cumulative bucket capacity or total storage namespaces within a tenancy, scaling is indeed virtually limitless. However, individual file ingestion imposes hard structural boundaries determined by underlying block management limits rather than abstract conceptual limits.

1 TB

Why it fails: While 1 TB represents the upper storage limit for a single block volume in OCI Block Volume service, it falls significantly short of OCI Object Storage capabilities. This capacity is tempting because block storage volumes routinely scale to this size for database and file system workloads, leading administrators to incorrectly apply block storage limits to object storage architecture. However, OCI Object Storage supports single objects up to 10 TiB, meaning a 1 TB limit fails to reflect the maximum scale achievable through multipart uploads in the object store.

1 GB

Why it fails: Setting a one-gigabyte limit severely undercuts the actual capacity ceiling of ten terabytes allowed for a single standard object in Oracle Cloud Infrastructure Object Storage. Administrators often confuse this low threshold with multipart upload part sizes, where individual chunks can range from ten megabytes up to fifty gigabytes, or mistake it for block volume attachment limits. This restriction would prevent the successful upload of massive enterprise database backups, high-resolution media archives, and large virtual machine images that routinely exceed several gigabytes in modern cloud architectures.

Bucket size limit

Why it fails: Object Storage buckets do not impose a hard size limit that prevents Block Volume backups from completing, as the service automatically scales to accommodate incoming data. This choice appears relevant because users often confuse Object Storage capacity management with the specific service limits governing Block Volume snapshots. While bucket quotas exist for cost governance or resource isolation within an Object Storage compartment, they do not trigger backup failures for block-level storage operations, which rely on independent snapshot service quotas rather than bucket-level constraints.

FastConnect is down

Why it fails: Backup is an internal OCI control plane operation.

File system is mounted

Why it fails: Oracle Cloud Infrastructure Block Volume backups are crash-consistent snapshots that do not require unmounting the file system to function. This option is tempting because administrators often unmount volumes before performing manual file-level backups or filesystem-level consistency checks to prevent data corruption during the copy process. While unmounting is a standard procedure for traditional tape or file-based archiving to ensure data integrity, it is unnecessary for OCI Block Volume service backups, which handle the underlying block-level state automatically.

Lower Cost

Why it fails: Lower Cost storage is designed for throughput-intensive workloads where performance scales directly with volume size rather than allowing independent IOPS provisioning. It would be the correct choice when deploying large-scale boot volumes or sequential data processing tasks requiring economical capacity without custom performance tuning. However, it fails this scenario because it lacks the underlying mechanism to dynamically adjust IOPS per gigabyte independently of the total storage capacity allocated.

Archive

Why it fails: Archive storage is designed for rarely accessed data requiring long-term retention at the lowest possible cost, making it tempting for budgets focused on cold storage, but it fails this scenario because it does not support dynamic IOPS adjustment or active database workloads. It would be the correct choice when your primary requirement is the long-term, low-cost preservation of compliance backups or historical logs that are retrieved infrequently and do not demand high-performance block storage capabilities.

Ultra High Performance

Why it fails: Ultra High Performance is designed for extreme, fixed workloads requiring up to 300,000 IOPS and 50 GB/s per volume, making it tempting for databases demanding maximum throughput, but it fails this scenario because its performance parameters are statically provisioned rather than dynamically adjustable. In contrast, the Lower Cost tier permits flexible scaling of IOPS independently of storage capacity.

Block volume size

Why it fails: Block volume size dictates the total capacity and performance throughput of block storage, yet it has no functional relationship with the network-attached File Storage Service (FSS) protocol. Administrators often conflate these storage types because both reside within the Oracle Cloud Infrastructure ecosystem. Adjusting block volume size is the correct procedure when addressing throughput or input/output operations per second (IOPS) bottlenecks specifically on persistent block devices, but it remains irrelevant to the latency characteristics of an NFS-based file system mount.

Object storage versioning

Why it fails: Object storage versioning manages historical states and prevents accidental deletion of data within buckets, which is irrelevant to the network throughput and file-locking mechanics of a File Storage Service mount. It would be a tempting troubleshooting step if you were investigating missing files or data corruption within an Object Storage bucket, where retaining multiple variants of an object over time is necessary for data recovery, but it has no impact on mount latency.

Bucket policies

Why it fails: Object Storage bucket policies control access permissions and authentication for data buckets rather than managing network performance or throughput for file system storage mounts. Administrators often mistake them for general configuration settings because they govern resource interactions in cloud environments, making them the correct choice when troubleshooting permission denied errors, access control list restrictions, or authorisation failures when applications attempt to read from or write to cloud storage buckets.

OCI Data Transfer Appliance

Why it fails: OCI Data Transfer Appliance relies on physical hardware shipment rather than network-based transmission, failing the requirement for data migration over the internet. This tool remains the standard solution for moving petabyte-scale datasets where limited network bandwidth or high latency makes online transfer unfeasible. You should select this method when physical shipping logistics provide the only viable path to ingest massive volumes of data into OCI Object Storage within a reasonable timeframe, bypassing the constraints of your local network infrastructure entirely.

Web Console

Why it fails: The Web Console relies on browser-based uploads, which lack the multi-part parallelisation and automated retry mechanisms required for high-throughput, large-scale data transfers. While it provides a user-friendly graphical interface for managing individual files or performing ad-hoc uploads of small datasets, it is designed for manual object management rather than automated, high-volume migration tasks. Consequently, it fails to handle the bandwidth optimisation and fault tolerance necessary for migrating massive volumes of data from a local server to OCI Object Storage.

Storage Gateway

Why it fails: Storage Gateway functions as a file system interface that caches data locally to provide low-latency access to OCI Object Storage, rather than acting as a bulk migration utility. It is designed for hybrid cloud applications requiring persistent, on-premises access to cloud-based files. While it provides a seamless bridge for active, frequently accessed datasets, it lacks the high-throughput, parallelised data transfer capabilities required for the one-time, large-scale migration of static archives specified in the requirement.