Cloud Storage Fundamentals Lab

Cloud storage is not one single technology. Different workloads need different storage models, and choosing the wrong one can create performance, availability, security, and cost problems.

Welcome to Lab 07 of the CompTIA Cloud+ practical lab sequence.

In the previous labs, you built:

• cloud compute
• segmented networking
• routing
• internet access
• security controls
• DNS and service naming

Now you will work with one of the most important cloud infrastructure components:

storage.

You will compare and practice the three major cloud-storage models:

Block Storage
vs
File Storage
vs
Object Storage

The objective is not simply:

Create a storage resource.

The objective is:

Understand which storage model fits which workload, how data is accessed, how persistence works, how storage affects performance, and how to troubleshoot common storage problems.

🎯 Mission Information

Item	Details
Lab	07 — Cloud Storage Fundamentals Lab
Difficulty	Beginner → Intermediate
Estimated Time	75–120 Minutes
Certification Alignment	CompTIA Cloud+
Primary Focus	Cloud Storage
Previous Lab	06 — Cloud DNS and Name Resolution
Career Alignment	Cloud Administrator, Cloud Engineer, Cloud Support Engineer
Major Skills	Block, File, Object Storage, Mounting, Capacity, Performance, Troubleshooting
Deliverable	Cloud Storage Comparison + Working Storage Configuration

🏢 Scenario

Your application team now needs storage for three different purposes.

Requirement 1 — Operating System and Application Disk

A Linux VM requires persistent disk storage.

Requirement 2 — Shared Team Files

Multiple workloads need access to the same shared files.

Requirement 3 — Application Objects and Backups

The organization needs scalable storage for:

• documents

• images

• backup files

• application objects

Your manager asks you to evaluate the correct storage model for each requirement.

The target design is:

Cloud Application
     |
     ├── Block Storage
     │      VM Disk
     |
     ├── File Storage
     │      Shared Files
     |
     └── Object Storage
            Documents / Backups / Objects

🎯 Lab Objectives

By completing this lab, you should be able to:

• explain block storage

• explain file storage

• explain object storage

• select storage based on workload requirements

• understand persistent storage

• attach additional block storage to a VM

• identify a new block device

• create or use a filesystem

• mount storage

• validate persistence

• understand shared file-storage concepts

• create and use object storage

• upload and retrieve objects

• understand storage capacity

• explain IOPS

• explain throughput

• explain latency

• understand storage durability and availability concepts

• identify common storage failures

• troubleshoot storage access

• evaluate cost implications

• document cloud storage professionally

🧠 Why This Lab Matters

A common mistake is:

Storage is storage.

But these workloads have very different requirements.

Consider:

Operating System Disk

versus:

Shared Department Folder

versus:

Millions of Images

They should not necessarily use the same storage model.

A cloud engineer needs to ask:

How Will Data Be Accessed?
        ↓
By One Server or Many?
        ↓
Filesystem Required?
        ↓
Performance Requirements?
        ↓
Scale Requirements?
        ↓
Persistence?
        ↓
Cost?

01 — Understand Cloud Storage Models

The three major storage models are:

Block
File
Object

Each solves a different type of problem.

02 — Understand Block Storage

Block storage presents storage as a block device.

Conceptually:

Cloud VM
   ↓
Virtual Disk
   ↓
Blocks

The operating system typically formats the device with a filesystem.

🧠 Common Use Cases

Block storage is commonly suitable for:

• operating-system disks

• application disks

• database storage

• filesystems attached to individual systems

03 — Understand File Storage

File storage provides filesystem-style access to shared files.

Conceptually:

VM 1
   \
    \
Shared File Storage
    /
   /
VM 2

Workloads access files through directories and paths.

🧠 Common Use Cases

File storage may be suitable for:

• shared team files

• application shared directories

• content repositories

• shared application assets

04 — Understand Object Storage

Object storage stores data as objects rather than traditional mounted disk blocks.

Conceptually:

Application
   ↓
Object Storage API
   ↓
Bucket / Container
   ↓
Objects

🧠 Common Use Cases

Object storage is frequently used for:

• images

• documents

• backups

• logs

• static content

• large-scale datasets

05 — Compare the Three Models

Characteristic	Block	File	Object
Access Model	Block Device	Filesystem	API/Object
Common Attachment	VM/Host	Multiple Clients	Applications/Users
Filesystem	Usually created by OS	Provided	Not traditional mounted filesystem
Typical Use	OS/DB Disks	Shared Files	Backups/Media/Data
Scale	High	High	Very High
Shared Access	Depends on architecture	Common	Native via service/API

🧠 Cloud+ Decision Principle

Do not memorize:

Block = this, File = that.

Instead ask:

How does the application need to consume the data?

06 — Review the VM From Previous Labs

Use an existing Linux lab VM if available.

Confirm:

VM Name:

Private IP:

Operating System:

Current Storage:

07 — Inspect Current Block Devices

Connect to your Linux VM.

Run:

lsblk

Observe the existing disk devices.

You may see something conceptually similar to:

disk
└── partition

08 — Check Mounted Filesystems

Run:

df -h

Identify:

• mounted filesystems

• capacity

• used space

• available space

🧠 lsblk vs df

lsblk helps answer:

Which block devices exist?

df -h helps answer:

Which mounted filesystems are consuming capacity?

09 — Create an Additional Block Storage Volume

Using your provider’s supported storage service, create a small additional block volume.

Example name:

cloudplus-lab-block-01

Use a small practical size.

For example:

5–10 GB

where supported and appropriate.

⚠️ Cost Notice

Choose the lowest-cost practical configuration.

Review:

• capacity

• disk type

• performance settings

before creating it.

10 — Apply Tags

Use your standard tags.

Tag	Value
Environment	Lab
Course	CompTIA-CloudPlus
Purpose	BlockStorage
Owner	Student

11 — Review Block Storage Configuration

Record:

Volume Name:

Capacity:

Storage Type:

Region / Zone:

IOPS:

Throughput:

Encryption:

Some values may be managed automatically by your provider.

12 — Understand Storage Location Constraints

Cloud block storage may need to exist in:

• the same region

• the same availability zone/failure domain

as the VM.

Provider implementation varies.

🧠 Troubleshooting Connection

A storage volume that exists but cannot attach may be in:

the wrong infrastructure location.

13 — Attach the Volume to the VM

Attach:

cloudplus-lab-block-01

to your selected VM.

Do not format anything yet.

14 — Validate the Attachment in the Cloud Console

Confirm:

Volume
 ↓
Attached
 ↓
Correct VM

15 — Validate the Device Inside Linux

Run:

lsblk

Compare the output with the previous result.

Identify the new device.

📝 Record

New Device:

Capacity:

Existing Filesystem:
Yes / No

16 — Understand an Unformatted Block Device

A newly attached block device may exist without a filesystem.

Conceptually:

Block Device
      ↓
Filesystem
      ↓
Mount Point
      ↓
Files

🚨 Important

Do not format a device unless you have positively identified it.

Formatting the wrong device can destroy data.

17 — Confirm the Correct Device

Use:

lsblk

and other appropriate inspection commands.

Verify:

• size

• device name

• attachment

before modifying it.

18 — Create a Filesystem

For a new empty training volume only, create a supported filesystem.

For example, on an approved Linux lab device:

sudo mkfs.ext4 <device>

Replace <device> only after identifying the correct new lab disk.

⚠️ Critical Safety Rule

Never run filesystem-creation commands against:

• production disks

• boot disks

• disks containing required data

• devices you have not positively identified

19 — Create a Mount Point

Create:

sudo mkdir -p /cloudplus-data

20 — Mount the Filesystem

Mount your lab device:

sudo mount <device> /cloudplus-data

21 — Validate the Mount

Run:

df -h

You should now see:

/cloudplus-data

with the new filesystem capacity.

22 — Create Test Data

Create a file:

echo "CompTIA Cloud+ Storage Lab" | sudo tee /cloudplus-data/lab.txt

Verify:

cat /cloudplus-data/lab.txt

23 — Understand Persistent Storage

Persistent storage is intended to retain data independently of short-lived compute lifecycle events, depending on the service and deletion settings.

Test the concept carefully.

24 — Restart the VM

Restart the VM using the supported method.

Reconnect afterward.

Check:

lsblk

and:

df -h

25 — Determine Whether the Filesystem Automatically Remounted

You may discover:

Disk Exists

but:

Mount Missing

after restart.

This introduces:

persistent mount configuration.

26 — Understand Persistent Mount Configuration

Linux systems commonly use configuration such as:

/etc/fstab

to define filesystems that should mount during boot.

🚨 Important

Incorrect persistent-mount configuration can cause boot issues.

Make changes only in your disposable lab and verify carefully.

27 — Identify the Filesystem UUID

A safer configuration may use a filesystem UUID rather than a potentially changing device name.

Use appropriate tooling such as:

blkid

Identify the UUID for your new lab filesystem.

28 — Review /etc/fstab

View:

cat /etc/fstab

Understand its role before editing.

29 — Configure the Persistent Mount

If comfortable and using an isolated lab, add the appropriate mount definition for:

/cloudplus-data

using the correct UUID, filesystem type, and options for your environment.

🚨 Safety Recommendation

Before rebooting, validate the configuration using your distribution’s appropriate methods.

Do not blindly copy an fstab entry from another system.

30 — Restart and Validate Persistence

Restart the VM.

Then verify:

df -h

Confirm /cloudplus-data is mounted.

Check:

cat /cloudplus-data/lab.txt

Your test file should still exist.

🧠 Key Lesson

You have now separated:

Compute Lifecycle

from:

Data Persistence

31 — Understand Block Storage Performance

Block-storage performance may involve:

• IOPS

• throughput

• latency

32 — Understand IOPS

IOPS means:

Input/Output Operations Per Second

It represents the number of read/write operations storage can process during a period.

🧠 IOPS Matters For

Workloads such as:

• transactional databases

• high-frequency small read/write activity

33 — Understand Throughput

Throughput represents how much data can be transferred over time.

Often expressed in units such as:

MB/s
GB/s

🧠 Throughput Matters For

Workloads such as:

• large file processing

• backups

• streaming data

34 — Understand Latency

Latency represents:

how long an individual operation takes.

Lower storage latency can improve workloads requiring quick access.

🧠 Performance Model

Use:

IOPS
+
Throughput
+
Latency

rather than assuming one performance metric tells the whole story.

35 — Inspect Basic Disk Activity

Depending on available tools, review system disk usage and activity.

For this lab, you do not need to perform aggressive benchmarking.

Focus on understanding the concepts.

36 — Understand Storage Right-Sizing

Avoid:

Application Needs 10 GB
      ↓
Provision 5 TB

unless growth requirements justify it.

Consider:

• current need

• expected growth

• service limits

• cost

37 — Understand Capacity Monitoring

Suppose:

Filesystem:
95% Full

The application may eventually fail even though the VM is healthy.

🧠 Capacity Troubleshooting

Storage must be monitored separately from:

• CPU

• memory

• networking

38 — Simulate Storage Consumption

In your lab, create only a small harmless test file.

Do not intentionally fill the entire disk.

The goal is to understand:

what high capacity usage would look like.

39 — Review File-System Capacity

Run:

df -h

40 — Review Directory Usage

Run:

du -sh /cloudplus-data

🧠 df vs du

Use:

df
Filesystem Usage

du
Directory/File Usage

41 — Understand File Storage

Now move from:

One VM
      ↓
Attached Disk

to:

Multiple Workloads
      ↓
Shared Filesystem

42 — Identify a Shared File Requirement

Imagine:

Web VM
App VM
Worker VM

all need to access:

/shared-content

A managed file-storage service may fit this requirement better than manually attaching one individual block disk to every system.

43 — Create or Review a Cloud File Storage Service

Where supported and cost-appropriate, create a small test file-storage resource.

Example:

cloudplus-lab-file-01

If your provider’s managed file service creates significant cost, you may perform this portion as an architecture and configuration review rather than keeping it deployed.

44 — Understand File Protocols

Cloud file-storage services may use protocols such as:

• NFS

• SMB

depending on platform and workload.

🧠 Common Alignment

NFS is commonly associated with Unix/Linux environments.

SMB is commonly associated with Windows file-sharing environments.

Both can be used in broader architectures depending on requirements.

45 — Review File Storage Connectivity

Shared file storage may require:

Client
 ↓
Network
 ↓
Security Rule
 ↓
File Storage Endpoint

🧠 Important

File-storage problems can therefore be:

• storage problems

• network problems

• permissions problems

46 — Mount Shared File Storage

If your provider supports a safe low-cost lab configuration, follow its supported procedure to mount the file share to a test VM.

Example conceptual path:

Shared File Storage
      ↓
/cloudplus-share

47 — Validate Shared Access

Where practical, mount the same share from another lab workload.

Create:

shared-test.txt

from one system.

Verify that the other system can read it.

🧠 Key Difference

Block storage example:

VM A
 ↓
Disk A

File storage example:

VM A ─┐
      ├── Shared Files
VM B ─┘

48 — Understand File Permissions

Shared storage still requires authorization.

Ask:

• who can read?

• who can write?

• which workload needs access?

🧠 Storage Security Principle

Shared storage should not mean:

everyone gets full access.

49 — Understand Object Storage

Now move to object storage.

Object storage is typically organized conceptually as:

Storage Service
      ↓
Bucket / Container
      ↓
Objects

50 — Create an Object Storage Container

Using your provider’s object-storage service, create a training container/bucket.

Example name:

cloudplus-lab-objects-<unique-value>

Provider naming requirements may vary.

🚨 Public Access Warning

Do not enable public access unless a specific lab requires it.

Keep the training container private.

51 — Apply Tags Where Supported

Example:

Tag	Value
Environment	Lab
Course	CompTIA-CloudPlus
Purpose	ObjectStorage
Owner	Student

52 — Upload a Test Object

Create a local file such as:

cloudplus-object.txt

containing:

CompTIA Cloud+ Object Storage Lab

Upload it to object storage.

53 — Inspect the Object

Identify information such as:

• object name/key

• size

• upload time

• storage class/tier where visible

54 — Download the Object

Retrieve the file.

Confirm the contents are correct.

🧠 Object Storage Access Model

Notice the difference.

Block storage:

OS
 ↓
Filesystem
 ↓
File

Object storage:

Application / Client
      ↓
Storage API
      ↓
Object

55 — Create a Folder-Like Prefix

Object stores may present folder-like organization.

For example:

backups/
documents/
images/

Understand that object-storage implementations may not use directories exactly like a traditional filesystem.

56 — Upload Multiple Test Objects

Create a structure conceptually like:

cloudplus-lab-objects
│
├── documents/
│   └── guide.txt
│
├── images/
│
└── backups/
    └── test-backup.txt

57 — Understand Object Storage Scale

Object storage is designed for very large numbers of objects and significant data scale.

It is commonly used where traditional filesystem attachment is unnecessary.

58 — Understand Storage Classes / Tiers

Cloud providers may offer different storage tiers based on:

• access frequency

• performance

• retrieval expectations

• cost

Conceptually:

Frequent Access
      ↓
Higher Availability / Immediate Access

Infrequent Access
      ↓
Lower Storage Cost

Archive
      ↓
Long-Term Retention

Exact characteristics vary by provider.

59 — Storage Tier Selection Scenario

Consider:

Frequently Accessed Website Images

Likely need:

frequent-access storage.

Seven-Year Compliance Archive

May be better suited to:

archival storage.

🧠 Cloud Engineer Principle

Choose storage based on:

Access Pattern
+
Performance
+
Retention
+
Recovery Requirement
+
Cost

60 — Understand Durability

Durability relates to the probability of data remaining intact over time.

Cloud providers often design storage systems with redundancy to improve durability.

61 — Understand Availability

Availability relates to:

whether the service/data is accessible when required.

🧠 Durability vs Availability

Do not confuse:

Durability
=
Data Remains Intact

with:

Availability
=
Data Can Be Accessed

62 — Understand Replication Concepts

Cloud storage may maintain data across:

• multiple devices

• multiple failure domains

• multiple geographic locations

depending on the service design.

63 — Understand Storage Encryption

Storage should be evaluated for:

Encryption at Rest

Protect stored data.

Encryption in Transit

Protect data while moving across networks.

🧠 Important

Encryption does not replace:

access control.

A user with excessive permission may still access encrypted data through an authorized service.

64 — Understand Storage Access Control

For every storage service ask:

Who Can Access It?
 ↓
What Can They Do?
 ↓
Which Data?
 ↓
From Where?

You will go deeper into storage security in:

Lab 08 — Secure Cloud Storage

65 — Compare Storage Use Cases

Complete this table:

Requirement	Best-Fit Model	Why
VM Boot Disk	Block
Database Disk	Block
Shared Team Directory	File
Shared Application Files	File
Static Images	Object
Backup Archive	Object
Large Document Repository	Object

66 — Scenario — Database Storage

Requirement:

High-frequency database reads/writes.

Consider:

• block storage

• IOPS

• latency

• throughput

67 — Scenario — Shared Web Content

Requirement:

Five web servers need access to the same shared files.

Consider:

file storage.

68 — Scenario — Millions of Images

Requirement:

Application stores millions of images accessed through an API.

Consider:

object storage.

69 — Scenario — Operating System Disk

Requirement:

A virtual machine requires a boot disk.

Consider:

block storage.

70 — Troubleshooting Scenario — New Disk Not Visible

You attached a volume but Linux does not appear to show it.

Check:

Cloud Attachment
      ↓
Correct VM
      ↓
Location Compatibility
      ↓
OS Device Discovery
      ↓
lsblk

71 — Troubleshooting Scenario — Disk Exists but Cannot Store Files

Possible cause:

Block Device
      ↓
No Filesystem
      ↓
No Mount

Check:

• filesystem

• mount point

• permissions

72 — Troubleshooting Scenario — Mount Missing After Reboot

Likely area:

persistent mount configuration.

Check:

• /etc/fstab

• UUID

• filesystem

• mount point

73 — Troubleshooting Scenario — Filesystem Is Full

Use:

df
 ↓
Identify Full Filesystem
 ↓
du
 ↓
Identify Data Consumption
 ↓
Determine Safe Action

🚨 Do Not

Delete arbitrary files simply to create space.

Understand:

• application data

• logs

• retention

• backup requirements

74 — Troubleshooting Scenario — Shared File Storage Unreachable

Check:

Storage Service
 ↓
Network Path
 ↓
DNS
 ↓
Security Rule
 ↓
Protocol
 ↓
Mount Configuration
 ↓
Permissions

75 — Troubleshooting Scenario — Object Upload Fails

Check:

Identity
 ↓
Permission
 ↓
Storage Container
 ↓
Network / Endpoint
 ↓
Object Operation

76 — Troubleshooting Scenario — Object Exists but User Cannot Download It

This may be:

authorization.

Check:

• identity

• object/bucket permission

• policy

• encryption/key access where applicable

77 — Troubleshooting Scenario — Storage Performance Is Poor

Do not immediately increase storage size.

Review:

IOPS
 ↓
Throughput
 ↓
Latency
 ↓
Workload Pattern
 ↓
Compute / Network

🧠 Storage Troubleshooting Framework

Use:

Storage Exists?
      ↓
Correct Attachment / Endpoint?
      ↓
Network?
      ↓
Filesystem / Protocol?
      ↓
Permissions?
      ↓
Capacity?
      ↓
Performance?
      ↓
Application?

78 — Deliberately Unmount the Lab Block Storage

In your isolated Linux lab, safely unmount:

sudo umount /cloudplus-data

Confirm:

df -h

The filesystem should no longer appear mounted there.

79 — Observe the Failure

Try:

ls /cloudplus-data

The directory may still exist, but your attached filesystem is no longer mounted.

🧠 Important Observation

Mount point directory:

/cloudplus-data

and mounted filesystem are:

not the same thing.

80 — Restore the Mount

Use:

sudo mount <device-or-UUID> /cloudplus-data

or your configured persistent-mount mechanism.

Validate:

cat /cloudplus-data/lab.txt

81 — Document the Troubleshooting Case

Use:

Problem:
Application data unavailable.

Observed:
Mount point exists but expected data is missing.

Investigation:

Root Cause:
Filesystem not mounted.

Corrective Action:

Validation:

82 — Review Cost Characteristics

Storage cost may depend on:

• capacity

• performance

• storage tier

• operations

• retrieval

• data transfer

• snapshots

🧠 Cost Principle

Do not compare cloud-storage services using:

price per GB only.

Consider the entire usage pattern.

83 — Identify Unused Storage

Review your environment for:

• unattached volumes

• abandoned shares

• old objects

• unused snapshots

🧠 Operational Risk

Unused storage can create:

Cost
+
Data Exposure
+
Management Complexity

84 — Update Your Resource Inventory

Add:

Resource	Type	Purpose	Capacity	Status
cloudplus-lab-block-01	Block Storage	VM Data		Active
cloudplus-lab-file-01	File Storage	Shared Files		Review
cloudplus-lab-objects-*	Object Storage	Objects/Backups		Active

85 — Build the Final Storage Architecture

                      Cloud Application
                            |
          +-----------------+-----------------+
          |                 |                 |
          v                 v                 v
   Block Storage       File Storage      Object Storage
          |                 |                 |
          v                 v                 v
   VM / Database       Shared Files      Objects / Backup

86 — Create the Storage Decision Matrix

Requirement	Block	File	Object
VM Boot Disk	✅
DB Volume	✅
Shared Directory		✅
Multiple Clients		✅	✅ depending on app
Static Media			✅
Backup Objects			✅
API-Based Access			✅
Traditional Mounted Disk	✅	✅

87 — Capture Evidence

Capture sanitized evidence of:

• attached block storage

• lsblk

• mounted filesystem

• test file

• shared file-storage architecture/configuration where used

• object-storage container

• uploaded objects

• troubleshooting test

Do not include:

• secrets

• access keys

• account credentials

• sensitive production data

88 — Perform Final Validation

Verify:

Block Storage
      ↓
Attached
      ↓
Filesystem
      ↓
Mounted
      ↓
Persistent Data

Verify:

File Storage
      ↓
Shared Access Concept Understood

Verify:

Object Storage
      ↓
Object Uploaded
      ↓
Object Retrieved

🧪 Final Validation Checklist

Validation	Status
Block storage concept understood
File storage concept understood
Object storage concept understood
Additional block volume created
Volume attached to correct VM
New block device identified
Filesystem created safely
Storage mounted
Test file created
Persistence validated
Persistent mount understood
Capacity reviewed
IOPS understood
Throughput understood
Latency understood
Shared file storage reviewed
Object-storage container created
Object uploaded
Object downloaded
Storage tiers understood
Durability vs availability understood
Troubleshooting exercise completed
Resource inventory updated

89 — Cleanup Decision

If you are continuing immediately to Lab 08, retain the core storage resources because the next lab will secure them.

Recommended to retain:

cloudplus-lab-block-01

cloudplus-lab-objects-*

and your test file-storage environment where cost allows.

Remove:

• unnecessary test data

• temporary storage

• duplicate resources

⚠️ Check Cost Before Leaving

Pay particular attention to:

• managed file services

• high-performance disks

• unused volumes

If a resource creates meaningful idle cost and can easily be recreated:

document it and remove it.

🎯 Certification Connection

A Cloud+ scenario may ask:

A database requires low-latency persistent disk storage.

Think:

Block storage.

Another may ask:

Multiple servers need simultaneous access to a shared directory.

Think:

File storage.

Another:

An application needs highly scalable storage for millions of images.

Think:

Object storage.

🎤 Interview Questions

Practice without notes.

1. What is block storage?

2. What is file storage?

3. What is object storage?

4. Block vs file vs object storage?

5. Which storage model would you use for a VM boot disk?

6. Which would you use for shared files?

7. Which would you use for application images and backups?

8. What is persistent storage?

9. What is a filesystem?

10. What is a mount point?

11. What is IOPS?

12. What is throughput?

13. What is storage latency?

14. IOPS vs throughput?

15. What is storage durability?

16. Durability vs availability?

17. Why use different storage tiers?

18. Why might a block volume fail to attach?

19. How would you troubleshoot a disk that does not appear in Linux?

20. How would you troubleshoot a filesystem that is full?

21. Why use UUIDs for persistent mounts?

22. Why might a shared file system be unreachable?

23. How does object storage differ from a traditional filesystem?

24. Why are unattached volumes a concern?

25. How does storage selection affect cloud cost?

🚨 Scenario Interview Question 1

A VM needs an additional 100 GB persistent application disk.

Strong choice:

Block storage.

Then consider:

• capacity

• performance

• availability location

• encryption

• backup

🚨 Scenario Interview Question 2

Ten Linux servers need access to the same shared application files.

Consider:

managed file storage using an appropriate shared-file protocol.

🚨 Scenario Interview Question 3

An application stores millions of images and retrieves them using an API.

Consider:

object storage.

🚨 Scenario Interview Question 4

A disk was attached successfully, but Linux cannot save files to it.

Check:

Device
 ↓
Filesystem
 ↓
Mount
 ↓
Permissions

🚨 Scenario Interview Question 5

A volume was mounted successfully but disappears after VM reboot.

Check:

persistent mount configuration.

🚨 Scenario Interview Question 6

A database workload has high latency even though CPU and memory are healthy.

Investigate:

• storage latency

• IOPS

• throughput

• workload I/O pattern

🚨 Scenario Interview Question 7

A filesystem reaches 100% capacity.

Do not immediately increase storage.

First identify:

What Consumed Space?
 ↓
Is It Expected?
 ↓
Can Data Be Safely Removed?
 ↓
Does Capacity Need Expansion?

🚨 Scenario Interview Question 8

A VM was deleted, but an attached data volume remains.

This may be intentional if data must survive the compute instance.

But review:

• ownership

• data sensitivity

• cost

• lifecycle requirement

🚨 Scenario Interview Question 9

A shared file service is online, but one VM cannot mount it.

Check:

DNS
 ↓
Network Route
 ↓
Security Rule
 ↓
File Protocol
 ↓
Client Configuration
 ↓
Permissions

🚨 Scenario Interview Question 10

The application team wants to use expensive high-performance storage for every workload.

Do not automatically approve it.

Ask:

• performance requirement

• current metrics

• workload pattern

• cost

Then choose appropriate storage.

🧠 Cloud Storage Interview Framework

Use:

Workload Requirement
      ↓
Access Pattern
      ↓
Storage Model
      ↓
Capacity
      ↓
Performance
      ↓
Availability
      ↓
Security
      ↓
Cost
      ↓
Validation

💬 Interview Tip

Avoid:

“I would use object storage because cloud storage is scalable.”

A stronger answer is:

“I would first determine how the application accesses the data, whether it requires a mounted filesystem, whether multiple workloads need shared access, the performance and latency requirements, expected capacity growth, durability and availability expectations, security controls, and cost. I would then select block, file, or object storage based on those requirements.”

That demonstrates Cloud Engineer thinking.

📁 Portfolio Deliverables

Keep sanitized versions of:

1. Storage Architecture Diagram

Show:

VM → Block
Multiple VMs → File
Application/API → Object

2. Storage Comparison Matrix

Compare:

• access method

• workloads

• performance

• scale

3. Block Storage Deployment Record

Include:

• capacity

• attachment

• filesystem

• mount point

4. Object Storage Evidence

Show:

• container/bucket

• objects

• upload/download validation

5. Troubleshooting Record

Document:

Storage Failure
 ↓
Investigation
 ↓
Root Cause
 ↓
Resolution
 ↓
Validation

📝 Resume Examples

Instead of:

Worked with cloud storage.

Use:

Implemented and compared cloud block, file, and object storage based on workload access patterns, persistence, capacity, performance, shared-access, and cost requirements.

Or:

Attached and configured Linux cloud block storage, created filesystems and persistent mounts, validated data persistence, and troubleshot storage attachment, capacity, and mount issues.

Or:

Created private object-storage resources, uploaded and retrieved application objects, and evaluated storage tiers, durability, availability, and lifecycle requirements.

⭐ Job-Readiness Check

You should now be able to:

• explain block storage

• explain file storage

• explain object storage

• choose storage based on workload needs

• inspect Linux block devices

• understand filesystems

• mount storage

• understand persistent mounts

• validate data persistence

• understand shared file access

• understand object-storage APIs conceptually

• upload and retrieve objects

• explain IOPS

• explain throughput

• explain latency

• distinguish durability from availability

• understand storage tiers

• identify storage-capacity problems

• troubleshoot attachment and mount problems

• understand basic storage cost considerations

🏆 Mission Complete

You have now added the storage layer to your Cloud+ environment.

Your architecture has progressed from:

Compute
+
Networking
+
DNS

to:

Compute
+
Networking
+
DNS
+
Storage

You can now distinguish:

Block
   ↓
VM / Database Disk

File
   ↓
Shared Filesystem

Object
   ↓
Scalable Objects / Backups / Media

The key lesson from this lab is:

The right cloud-storage service is determined by how the workload needs to access, share, scale, protect, and retain its data—not simply by how much storage capacity it needs.

🚀 What’s Next?

You now understand the major cloud-storage models.

The next lab moves from:

How do we store the data?

to:

How do we secure and protect that data?

You will work with:

• object-storage permissions

• public-access controls

• storage IAM

• encryption at rest

• encryption in transit

• storage keys

• versioning

• backup concepts

• lifecycle rules

• accidental deletion protection

• storage logging

• secure access validation

• storage-security troubleshooting

You will transform:

Cloud Storage

into:

Cloud Storage
      ↓
Private Access
      ↓
Least Privilege
      ↓
Encryption
      ↓
Versioning / Protection
      ↓
Logging

➡️ Next: Lab 08 — Secure Cloud Storage