Lesson 5: Virtualization and Cloud Troubleshooting Challenge

Virtualization and cloud create a dangerous illusion:

If the guest or application looks normal, the infrastructure must be normal too.

No.

A guest can boot while its virtual network is wrong. A legacy application can work while the guest operating system remains a security risk. A snapshot can exist while recovery is still impossible after host-storage failure. A user's laptop can be healthy while the VDI service is down.

The layers changed.

Troubleshooting did not.

Use the responsibility path

Start here:

physical / provider infrastructure
        ↓
host / hypervisor / platform
        ↓
virtual resource or managed service
        ↓
guest / runtime
        ↓
application
        ↓
identity / data / user function

For every case, ask:

1. What is still working?
2. What shared dependency exists?
3. Which layer failed first?
4. Who owns that layer?
5. What correction or escalation is actually possible?
6. What does the retest prove?

Case 1: every VM becomes slow

Evidence:

host RAM use: extremely high
host paging: heavy
VM A: slow
VM B: slow
VM C: slow
symptom began after VM D started

What do the guests share?

The host resource pool.

Four unrelated guest failures occurring at the same moment are possible, but shared host-memory pressure is a much stronger first explanation.

A useful correction may reduce over-allocation or stop or move a workload.

Verification should include:

• host memory pressure reduced;
• paging reduced;
• affected guest performance restored.

Case 2: one VM has no network

Evidence:

host network: healthy
other VMs: healthy
affected VM virtual NIC: disconnected

Stay at the virtual-device boundary.

Do not reboot the physical router.

The shared physical network is already working for other workloads.

Correction:

Reconnect the intended virtual NIC under the approved configuration.

Verification:

• guest sees the interface;
• guest receives expected IP configuration;
• required destination works;
• required isolation boundary still holds.

Case 3: the virtual network is working exactly as configured

Evidence:

VM NIC: connected
VM network mode: host-only
host network: healthy
user expects internet access

Nothing is necessarily broken.

The architecture does not match the requirement.

This is a configuration and design problem.

Change the network mode only if the exercise authorizes external access, then retest both connectivity and isolation.

Case 4: legacy VM works, but the user wants full production exposure

Evidence:

legacy guest: boots
legacy application: works
guest OS: unsupported
current network mode: isolated
request: bridge directly to production network

Virtualization solved the compatibility requirement.

It did not solve the legacy operating system's security risk.

The design question is:

What is the narrowest access this workload actually requires?

Do not turn a compatibility success into an unnecessary exposure problem.

Case 5: VDI login fails after identity succeeds

Evidence:

endpoint OS: healthy
network: healthy
credentials: accepted
VDI broker or access service: unavailable

A total endpoint or local-network failure becomes weak.

The centralized desktop path failed after authentication.

Do not reimage the laptop because the remote desktop infrastructure is unavailable.

Case 6: containerized application cannot find a dependency

Evidence:

container runtime: healthy
container: starts
application dependency: external service unavailable
host network: healthy to other destinations

The container boundary did not remove the application's external dependencies.

A running container proves the runtime started it.

It does not prove every service the application needs is reachable or healthy.

Case 7: snapshot did not survive storage failure

Evidence:

VM disk: host SSD
snapshot: same host SSD
host SSD: failed
independent backup/export: none

The snapshot feature did not fail at its intended job.

The recovery architecture failed to cover the physical-storage failure domain.

A snapshot is useful for rollback.

It is not automatically an off-device backup.

Case 8: synchronized deletion

Evidence:

file deleted on one device
sync service propagates deletion
other devices remove file
independent backup/version recovery: absent in scenario

Synchronization worked.

Recovery did not.

The fix is not "make sync less reliable."

The design needs a recovery mechanism that survives unwanted synchronized changes.

Case 9: provider SaaS outage

Evidence:

local endpoint: healthy
local network: healthy
DNS: working
provider status: service outage

Customer technicians cannot repair provider infrastructure directly.

The professional response is:

• verify scope;
• document impact;
• communicate status;
• use approved contingency where available;
• follow provider recovery status;
• retest when service returns.

Changing unrelated endpoint settings only creates more work.

Case 10: IaaS VM is running, application is broken

Evidence:

provider compute state: running
VM network: reachable
guest OS: healthy
application configuration: invalid

The provider is delivering the infrastructure layer.

The customer-owned application layer is failing.

"Cloud outage" is too broad.

Case 11: PaaS application hits a scaling limit

Evidence:

provider platform: available
application instances: at configured maximum
request rate: above expected peak
new requests: delayed or rejected

The service exists.

The scaling design has reached its allowed boundary.

Investigate quotas, configured elasticity, workload behavior, and cost before treating the provider as universally unavailable.

Case 12: architecture works, bill does not

Evidence:

service availability: normal
application behavior: normal
outbound transfer: unexpectedly high
metered egress cost: far above baseline

This is an operational failure, not an availability failure.

The network is working.

The architecture is moving more billable data than intended.

The next evidence belongs around workload behavior, data path, caching, replication, and transfer design.

Build four incident records

Choose four cases from different architectures and document:

virtualization / cloud model
user-visible symptom
shared dependencies
last proven-good boundary
first failed or uncertain boundary
customer-owned layer
provider-owned layer if applicable
strongest theory
competing theory
controlled correction or escalation
verification
remaining uncertainty

Do not submit four VM networking incidents and call it cloud troubleshooting.

Core 1 closure

The first ten weeks now form one continuous systems model:

hardware
→ firmware
→ storage / power / peripherals
→ mobile systems
→ printers
→ physical network
→ network services
→ network evidence
→ virtualization / cloud

The CompTIA objectives name the technologies you are expected to recognize and support.

The larger skill is seeing the boundaries between them.

Next we move into Core 2 and operating systems, where the same machine gains another set of layers: editions, filesystems, permissions, services, commands, applications, and user state.