220-1101Chapter 94 of 123Objective 4.2

Cloud Storage: Object, Block, File

This chapter covers cloud storage types: object, block, and file storage. For the 220-1101 exam, understanding these three models is critical, as they appear in roughly 5-10% of questions, often in scenario-based formats. You must be able to distinguish them by their access methods, performance characteristics, and typical use cases in cloud environments. This chapter provides the depth needed to answer exam questions correctly and to apply this knowledge in real-world cloud deployments.

25 min read
Intermediate
Updated May 31, 2026

Cloud Storage: Warehouses, File Cabinets, and Bookshelves

Imagine you run a large company with three different storage systems. First, you have a massive warehouse (object storage). Each item you store—whether a document, a photo, or a backup tape—gets a unique barcode and is placed on a shelf. You don't care about the order; you just need a way to retrieve it by its barcode. The warehouse can hold billions of items, and you access them via a simple API: 'give me item with barcode X'. Second, you have a file cabinet (file storage). Each drawer holds folders, and each folder holds files. You navigate by path: 'Cabinet A, Drawer 3, Folder 'Reports', File 'Q1.docx'.' This is familiar but requires you to manage the hierarchy. Third, you have a bookshelf with blocks (block storage). The bookshelf is divided into fixed-size slots. You write data onto a block, label it with an address (like block number 456), and later ask the shelf to fetch that block. You don't see the content as files; you just read raw blocks. Your operating system assembles these blocks into files. In the cloud, object storage is like the warehouse—scalable, accessed via HTTP, perfect for static assets and backups. File storage is like the file cabinet—used for shared drives, needs a network protocol like NFS or SMB. Block storage is like the bookshelf—used for virtual machine disks, low-latency, and presented as raw volumes. Each has its use case, and the CompTIA A+ exam expects you to know when to use which.

How It Actually Works

What Are Cloud Storage Types?

Cloud storage is a service model where data is maintained, managed, and backed up remotely and made available to users over a network. The three primary types—object, block, and file—differ in how they organize data, how they are accessed, and their performance characteristics. The CompTIA A+ 220-1101 exam objective 4.2 specifically requires you to 'Summarize aspects of cloud storage' and differentiate between these types.

Object Storage

Object storage treats data as discrete units called objects. Each object consists of the data itself, metadata (descriptive information), and a globally unique identifier (often a URL). Objects are stored in a flat address space (a bucket or container), not in a hierarchical directory tree. Access is typically via RESTful APIs over HTTP/HTTPS using commands like GET, PUT, DELETE. Examples include Amazon S3, Google Cloud Storage, and Azure Blob Storage.

How it works internally: When you upload a file to object storage, the service breaks it into an object, assigns it a unique ID, and stores it across multiple devices and locations for redundancy. The metadata can include custom attributes like content type, creation date, and access permissions. Retrieval is done by specifying the object's ID or key; the service locates it using a distributed hash table or similar index. This design makes object storage highly scalable—you can store billions of objects without performance degradation.

Key characteristics: - Scalability: Virtually unlimited storage capacity. - Durability: Data is replicated across multiple servers and locations (e.g., 99.999999999% durability for S3). - Access: HTTP/HTTPS, often via API calls. - Use cases: Static website hosting, backup and archive, media files, big data analytics. - Limitations: Not suitable for low-latency random access or for databases that require frequent updates to small portions of data. Objects are immutable in many implementations; to update, you must overwrite the entire object.

Block Storage

Block storage organizes data into fixed-size blocks (e.g., 512 bytes, 4 KB). Each block is addressed by an offset or block number. This is the same model used by traditional hard drives and SSDs. In the cloud, block storage volumes are presented as virtual drives to cloud servers (VMs). Examples include Amazon EBS, Google Persistent Disk, and Azure Managed Disks.

How it works internally: The cloud provider creates a virtual disk image that is sliced into blocks. The operating system on the VM sees the volume as a raw block device (e.g., /dev/xvda) and manages file systems (NTFS, ext4) on top of it. When an application writes to a file, the OS translates the file offset into a block address and sends an I/O request to the block storage service. The service then reads or writes the specified block on the underlying physical storage, which may be SSD or HDD, and may maintain snapshots for backup.

Key characteristics: - Performance: Low latency, high IOPS (input/output operations per second). Suitable for databases and transactional workloads. - Access: Via a block-level protocol (SCSI, iSCSI, NVMe over Fabrics). The OS mounts it as a drive. - Persistence: Data persists independently of the VM's lifecycle. You can detach a volume and attach it to another VM. - Use cases: Boot volumes for VMs, database storage, application data requiring frequent updates. - Limitations: Typically limited to a single VM at a time (unless using clustered file systems). Scaling requires provisioning more volumes or larger volumes.

File Storage

File storage presents data in a hierarchical file system with directories and files. Access is via network file sharing protocols such as NFS (Network File System) for Linux/Unix and SMB (Server Message Block) for Windows. Examples include Amazon EFS, Azure Files, and Google Cloud Filestore.

How it works internally: The cloud provider runs a file server that exports a file system over the network. Clients mount the file system using the appropriate protocol. The file server manages file locks, permissions, and metadata (file names, timestamps). When a client reads a file, the server sends the file's data blocks over the network. Write operations update the server's file system, which may replicate data for durability.

Key characteristics: - Access: Standard file I/O operations (open, read, write, close) over a network. - Concurrency: Multiple clients can access the same file system simultaneously, with file locking to prevent conflicts. - Use cases: Shared home directories, content management systems, lift-and-shift migrations of on-premises file servers. - Limitations: Performance can be limited by network latency and throughput. Not as scalable as object storage for billions of files.

Key Differences at a Glance

Granularity: Object storage manages entire objects; block storage manages fixed-size blocks; file storage manages files and directories.

Access Protocol: Object storage uses HTTP/HTTPS (REST); block storage uses block-level protocols (iSCSI, NVMe); file storage uses NFS/SMB.

Performance: Block storage offers the lowest latency and highest IOPS; file storage is moderate; object storage has higher latency due to HTTP overhead.

Scalability: Object storage scales best; file storage has limits on file count and namespace size; block storage scales by adding volumes.

Modification: Object storage requires rewriting entire objects; block and file storage allow partial updates.

Interaction with Related Technologies

Object storage is often used as a backend for cloud-native applications, serving static assets via CDN. Block storage is integral to virtualization—each VM has a boot volume (block storage) that contains the OS. File storage is used for shared file systems that multiple VMs need to access, such as for web server clusters. In hybrid cloud scenarios, on-premises applications can access cloud file storage via VPN or Direct Connect. Understanding these interactions helps in designing cloud architectures and troubleshooting performance issues.

Configuration and Verification

In the cloud, you typically configure storage via the provider's console, CLI, or API. For example, to create an S3 bucket (object storage) via AWS CLI:

aws s3 mb s3://my-bucket

To attach an EBS volume (block storage) to an EC2 instance:

aws ec2 attach-volume --volume-id vol-123 --instance-id i-456 --device /dev/sdf

To mount an EFS file system (file storage) on Linux:

sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 fs-123.efs.us-east-1.amazonaws.com:/ /mnt/efs

Verification commands include listing objects with aws s3 ls, checking volume status with aws ec2 describe-volumes, and checking file system mount with df -h.

Common Pitfalls and Exam Traps

Confusing block and file storage: Block storage is raw disk; file storage is a shared file system. The exam may test by describing a scenario: 'Which storage type is best for a shared home directory?' Answer: file storage.

Assuming object storage is always the best: It's not for low-latency databases. Block storage is better.

Ignoring protocol details: The exam may ask which protocol is used for file storage (NFS or SMB) or for block storage (iSCSI).

Misunderstanding 'durability': Object storage is highly durable due to replication, but that doesn't mean it's fast.

Summary of Core Concepts

Object storage: flat namespace, HTTP access, scalable, for static data.

Block storage: fixed-size blocks, low latency, for VM disks and databases.

File storage: hierarchical, shared access via NFS/SMB, for file shares.

The exam expects you to match use cases to storage types.

Walk-Through

1

Identify the Storage Need

Begin by analyzing the workload requirements. Ask: Is this a database that needs low-latency random writes? Then block storage is the answer. Is it a shared document repository for multiple users? Then file storage fits. Is it a backup or static website? Object storage is optimal. The exam will present scenarios like 'A company wants to store millions of user photos accessible via HTTP.' The correct answer is object storage. A common trap is choosing file storage because photos are files; but the key is HTTP access and massive scale, which object storage excels at.

2

Select the Access Protocol

Determine how clients will connect. For block storage, the protocol is typically iSCSI (Internet Small Computer System Interface) or NVMe over Fabrics. For file storage, it's NFS (for Linux/Unix) or SMB (for Windows). For object storage, it's HTTP/HTTPS using RESTful APIs (GET, PUT, DELETE). The exam may test: 'Which protocol is used to mount a cloud file share on a Windows server?' Answer: SMB. Knowing these protocols is crucial for scenario-based questions.

3

Provision the Storage Resource

In the cloud provider's console, create the storage resource. For object storage, create a bucket (e.g., in S3) and configure permissions. For block storage, create a volume of a certain size (e.g., 100 GB) and attach it to a VM. For file storage, create a file system (e.g., EFS) and note the DNS name for mounting. The exam doesn't require deep CLI knowledge but expects you to understand the provisioning steps conceptually. For example, 'Which step is required before attaching a block volume to a VM?' Answer: Create the volume in the same availability zone.

4

Configure Access and Permissions

Set up authentication and authorization. For object storage, use IAM policies or bucket policies to control access. For block storage, set up security groups or firewall rules to allow iSCSI traffic (port 3260). For file storage, configure NFS export rules or SMB share permissions. The exam may test: 'What must be configured to allow an EC2 instance to mount an EFS file system?' Answer: Security group rules allowing inbound NFS traffic (port 2049).

5

Mount or Integrate with Application

Finally, the client connects to the storage. For block storage, the OS detects the new disk; you must partition, format, and mount it (e.g., `mkfs.ext4 /dev/xvdf; mount /dev/xvdf /data`). For file storage, mount it using the appropriate command (e.g., `mount -t nfs4 ...`). For object storage, use an SDK or CLI to access objects. The exam may ask: 'After attaching a block volume, what is the next step before storing files?' Answer: Format the volume with a file system.

What This Looks Like on the Job

In enterprise cloud deployments, each storage type serves distinct roles. Consider a large e-commerce platform. The product images are stored in object storage (e.g., Amazon S3) because they are static, accessed via HTTP, and need to scale to millions of images. The platform uses a CDN to cache these images globally. The database that tracks inventory and user orders runs on block storage (e.g., Amazon EBS with Provisioned IOPS) to ensure low-latency transactions. The application servers mount a shared file storage (e.g., Amazon EFS) to store configuration files and session data that must be consistent across all servers. This architecture uses all three types optimally.

Another scenario: a media production company uses block storage for high-performance video editing workstations. Each editor has a dedicated block volume for the project they are working on. Finished projects are archived to object storage for cost-effective long-term retention. File storage is used for shared assets like fonts and templates that multiple editors need to access simultaneously.

A common misconfiguration is using block storage for a shared file system without clustering. Block volumes can only be attached to one VM at a time (except for multi-attach configurations, which are rare and complex). Trying to attach the same volume to two VMs can cause data corruption. For shared access, file storage or object storage must be used.

Performance considerations: Block storage IOPS and throughput are tied to volume size and type (e.g., gp3 vs. io2). Object storage has higher latency (tens of milliseconds) but can handle massive throughput for large objects. File storage performance depends on the number of clients and file operations. When misconfigured, such as using object storage for a database, the application will experience slow response times. The exam tests your ability to choose the right storage based on these characteristics.

How 220-1101 Actually Tests This

The 220-1101 exam objective 4.2 focuses on summarizing cloud storage concepts. You should expect 1-3 questions on this topic. Key areas tested:

1.

Differentiating storage types: The exam will present a scenario and ask which storage type is best. Common wrong answers: choosing file storage when object storage is needed (because the scenario mentions 'files'), or choosing block storage when file storage is needed (because the scenario mentions 'shared access'). Remember: file storage is for shared hierarchical access; object storage is for HTTP-accessible static data; block storage is for VM disks and databases.

2.

Protocols: The exam may ask which protocol is used for file sharing (NFS or SMB) or for block storage (iSCSI). A trap: confusing iSCSI with SMB. iSCSI is block-level; SMB is file-level.

3.

Use cases: Be able to match specific use cases. For example, 'Which storage type is best for a boot volume of a virtual machine?' Answer: Block storage. 'Which storage type is best for a shared network drive?' Answer: File storage. 'Which storage type is best for a backup archive?' Answer: Object storage.

4.

Performance characteristics: The exam may ask about latency and throughput. Block storage is lowest latency; object storage has higher latency. A trap: assuming object storage is always slow—it's not for large sequential reads, but for random small reads, it's slower than block.

5.

Scalability: Object storage scales best; file storage has limits. The exam might mention 'billions of objects' as a hint for object storage.

6.

Edge cases: Some services blur the lines, like Amazon FSx for Lustre (a file system that uses block storage underneath). But the exam stays with the three basic types. Also, note that some block storage can be shared (e.g., multi-attach EBS), but this is an exception and typically not tested.

To eliminate wrong answers, focus on the access method and performance needs. If the scenario mentions HTTP or REST, it's object storage. If it mentions mounting a drive, it's block or file. If it mentions low latency and high IOPS, it's block. If it mentions multiple users accessing the same files, it's file.

Key Takeaways

Object storage uses a flat namespace and HTTP access; ideal for static assets and backups.

Block storage provides raw disk volumes with low latency; used for VM boot drives and databases.

File storage offers hierarchical shared access via NFS/SMB; used for network file shares.

For the exam, match the storage type to the scenario: HTTP access → object; high IOPS database → block; shared files → file.

Block storage is attached to a single VM; file storage can be mounted by multiple clients simultaneously.

Object storage is the most scalable; file storage has limits on file count; block storage scales by volume size and count.

Common exam protocols: iSCSI (block), NFS/SMB (file), HTTP/HTTPS (object).

Durability: object storage typically offers 99.999999999% durability through replication.

Performance: block > file > object in terms of latency for random small I/O.

Always consider the access method and performance requirements when choosing a storage type.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

Object Storage

Data stored as objects with unique IDs

Accessed via HTTP/HTTPS (REST API)

Highly scalable, virtually unlimited capacity

Higher latency, not suitable for low-latency workloads

Best for static assets, backups, archives

Block Storage

Data stored as fixed-size blocks

Accessed via block-level protocols (iSCSI, NVMe)

Scalable but limited by volume size (max 16 TB per volume)

Low latency, high IOPS, suitable for databases

Best for VM boot volumes, transactional databases

File Storage

Hierarchical file system with directories

Accessed via NFS or SMB protocols

Supports file locking and concurrent access

Moderate scalability (millions of files)

Best for shared file systems, home directories

Object Storage

Flat namespace with objects

Accessed via HTTP/HTTPS (REST API)

Massively scalable (billions of objects)

No file locking, eventual consistency in some cases

Best for static content, big data, backups

Watch Out for These

Mistake

Object storage is just a fancy name for file storage in the cloud.

Correct

Object storage is fundamentally different: it uses a flat namespace with unique IDs, not a hierarchical directory tree. Access is via HTTP/HTTPS APIs, not file system protocols like NFS/SMB. Objects include rich metadata and are designed for massive scalability.

Mistake

Block storage and file storage are the same because both use 'blocks'.

Correct

Block storage provides raw block-level access without a file system; the client OS manages the file system. File storage provides a pre-built file system that multiple clients can access via network protocols. Block storage is typically attached to a single VM, while file storage can be shared.

Mistake

You can use object storage for a database because it's scalable.

Correct

Object storage has high latency and is not optimized for frequent small writes. Databases require low-latency random I/O, which block storage provides. Using object storage for a transactional database would result in terrible performance.

Mistake

File storage is always slower than block storage.

Correct

File storage can be slower due to network overhead and protocol overhead, but modern file storage services (e.g., Amazon EFS with performance modes) can achieve high throughput. The choice depends on the use case, not just speed.

Mistake

All cloud storage is automatically durable and available.

Correct

Durability and availability depend on the storage class and configuration. For example, object storage offers different tiers (e.g., S3 Standard vs. S3 Glacier) with different durability and availability guarantees. Block storage volumes can be replicated via snapshots, but the volume itself is tied to a single availability zone.

Do You Actually Know This?

Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.

Frequently Asked Questions

What is the difference between object storage and block storage?

Object storage treats data as objects with a unique ID and metadata, accessed via HTTP/HTTPS. It's highly scalable but has higher latency. Block storage breaks data into fixed-size blocks and presents them as a raw disk, accessed via protocols like iSCSI. It offers low latency and high IOPS, ideal for databases. The key difference is access method and performance: object for static data, block for transactional workloads.

Can I use file storage for a database?

Generally no. File storage introduces network latency and protocol overhead, and it's not optimized for the frequent small random writes typical of databases. For databases, block storage is recommended because it provides low-latency direct disk access. However, some NoSQL databases like MongoDB can run on file storage, but performance will be worse than on block storage.

What protocol is used for cloud file storage?

The two main protocols are NFS (Network File System) for Linux/Unix systems and SMB (Server Message Block) for Windows systems. Some cloud providers also support other protocols like S3 for object storage. The exam expects you to know that NFS and SMB are for file storage.

Which cloud storage type is best for a boot volume of a virtual machine?

Block storage. The boot volume contains the operating system, which requires low-latency random I/O. Block storage is presented as a local disk to the VM, allowing the OS to manage the file system. Object storage cannot be used as a boot volume because it lacks block-level access.

What is the difference between S3 and EBS?

S3 is Amazon's object storage service; it's accessed via HTTP, scalable, and used for static data. EBS is Amazon's block storage service; it provides persistent disk volumes for EC2 instances, with low latency and high IOPS. The exam might test that S3 is object storage and EBS is block storage.

How does cloud storage achieve durability?

Cloud storage providers replicate data across multiple devices and often across multiple availability zones. For example, Amazon S3 automatically replicates objects across at least three facilities. Block storage (EBS) replicates within an availability zone, and you can take snapshots to back up to another zone. Durability is typically measured in nines (e.g., 11 9's for S3).

What is a use case for object storage?

Object storage is ideal for storing large amounts of unstructured data such as images, videos, backups, and log files. It's also used for static website hosting (e.g., an S3 bucket configured for web hosting). Because it's accessed via HTTP, it integrates well with CDNs and web applications.

Terms Worth Knowing

Ready to put this to the test?

You've just covered Cloud Storage: Object, Block, File — now see how well it sticks with free 220-1101 practice questions. Full explanations included, no account needed.

Done with this chapter?