Cloud Characteristics

Cloud characteristics describe how cloud services are built, priced, and shared so they can scale on demand while staying accessible over a network. For the CompTIA A+ 220-1101 (Core 1) exam, Objective 4.2 matters because these traits show up in everyday support work, even when users never say the word "cloud."

In help desk tickets, you'll see the same patterns: a "slow app" caused by noisy neighbors on shared hardware, a surprise bill tied to metered traffic, or a sync client that keeps duplicating files. You'll also troubleshoot outages, plan around uptime expectations, and explain why a service can grow quickly under load but still hit limits.

This section gives plain definitions, quick examples, and exam-style clues for the exact terms CompTIA tests: shared resources vs. dedicated resources, metered utilization (including ingress and egress), elasticity, availability, file synchronization, and multitenancy. By the end, you'll know what each term means, what it looks like in a ticket, and which keywords often appear in exam questions.

Shared resources vs. dedicated resources, what you get and what you give up

When a cloud provider sells compute or storage, you are not always getting the same kind of "space." Sometimes you share a pool with other customers, and sometimes you reserve hardware for yourself. The exam tests this difference because it affects cost, performance, security, and troubleshooting.

In practice, you will hear users describe symptoms, not architectures. Your job is to map those symptoms to likely causes. Shared setups often explain shifting performance and low pricing. Dedicated setups often explain stable performance and stronger isolation, but with higher bills.

Shared resources, lower cost and flexible capacity, with a few trade-offs

In a shared model, the provider groups CPU, RAM, storage, and network into a common pool, then assigns portions to many customers as needed. This is the core of resource pooling. You might run a virtual machine (VM) on a host that also runs other customers' VMs. Likewise, your storage might live on a shared array, and your network bandwidth might ride on shared uplinks.

Because the provider spreads cost across many customers, shared options are often cheaper and easier to scale. Pricing also commonly follows pay-as-you-go, where you pay for what you use during a billing period.

Still, shared resources come with real trade-offs:

Noisy neighbor risk: Another tenant can spike CPU, disk I/O, or network use, and you may feel the slowdown.
Variable performance: Even if your VM size stays the same, real throughput can vary with host load.
Less control over the underlying host: You usually can't choose the exact physical server, NIC, or storage controller.

Shared environments also highlight the shared responsibility model. The provider manages the physical facility, power, cooling, physical servers, and usually the base virtualization layer. Meanwhile, you control what you deploy and how you secure it, such as OS patching (for IaaS), firewall rules, identities, and data classification. In other words, the provider keeps the "building" running, but you lock your "apartment."

Exam cue: terms like multi-tenant, resource pooling, and pay-as-you-go usually point to shared infrastructure, not dedicated hardware.

Dedicated resources, more predictable performance and stronger isolation

Dedicated options reserve some level of physical capacity for a single customer. Providers may describe this as a dedicated host, dedicated instance, or single-tenant environment. The details vary by vendor, but the theme stays the same: you reduce or eliminate other customers sharing the same underlying hardware.

Teams choose dedicated resources for clear reasons. First, performance becomes more predictable because fewer unknown workloads compete for the same CPU cache, storage I/O, or network path. Second, isolation improves, which can simplify risk reviews and audits. Third, dedicated placement can help with low-latency needs when you want consistent response times.

Common reasons to select dedicated resources include:

Compliance and audit needs: Policies may require single-tenant hosting or strict separation.
Steady workloads: A workload that runs 24/7 may justify reserved capacity.
Performance-sensitive apps: Consistent throughput matters more than elastic growth.

The downsides are practical. Dedicated resources usually cost more, and they can be less flexible. You might wait longer for provisioning, and scaling up can require more planning. In addition, if you over-allocate, you pay for idle capacity.

A simple scenario helps. A small health clinic hosts an app that stores patient records. The clinic's risk team wants stronger isolation and clear control of where data runs. As a result, they choose a single-tenant setup, even though the monthly cost rises. They accept the trade because audit expectations and privacy rules carry more weight than saving money.

How to decide fast on the exam, and in a help desk ticket

On the exam, you often get one paragraph with a few keywords. In a ticket, you may only get a complaint like "it's slow today." Use a short decision checklist to stay consistent.

Start with these five factors:

Performance consistency: If the workload needs stable latency or throughput, lean dedicated. If it can tolerate swings, shared fits.
Isolation needs: If the prompt mentions compliance, single-tenant, or strict separation, lean dedicated.
Budget pressure: If cost is the main driver, shared and pay-as-you-go is the usual match.
Workload spikes: If demand jumps unpredictably, shared pools often scale faster and cheaper.
Management effort: Dedicated can add planning and coordination, while shared options are often simpler to start.

Here are mini "which one fits" examples written like exam stems:

Example 1: A startup runs a web app with uneven traffic, and it wants the lowest monthly cost. The question mentions multi-tenant and pay-as-you-go. The best fit is shared resources.
Example 2: A database supports point-of-sale transactions, and users report inconsistent response times during peak hours. The business wants predictable performance and lower latency. The best fit is dedicated resources.
Example 3: A company states that audit policy requires single-tenant infrastructure for a regulated app. Cost matters less than isolation. The best fit is dedicated resources.

In support work, this mindset keeps you practical. If a user reports "random slowness," ask whether the service runs on shared infrastructure and whether other tenants could affect performance. On the other hand, if a system is dedicated and still slow, focus on the customer-controlled side, such as OS updates, storage saturation, or mis-sized instances.

Metered utilization, how cloud billing tracks what you use

Cloud pricing often feels simple at first because you can start small. However, most cloud services bill like a utility meter. The provider records what you consume, converts it into units, then charges based on time and volume.

For the CompTIA A+ exam and for real support work, the key skill is translation. You take a bill line item, map it to a resource (compute, storage, network, or requests), then explain what behavior caused it. Once you can do that, "mystery charges" usually stop being mysteries.

What "metered" really means, and why it surprises new users

"Metered" means the provider measures usage in defined units, then bills for those units during the billing period. Think of it like an odometer and a clock combined. Some charges track how much you used, while others track how long something stayed active.

Common metered units include:

Compute time: vCPU-hour, instance-hour, or similar time-based measures for running workloads.
Storage: GB-month, which blends capacity and time (more data for more days costs more).
Requests and operations: API calls, database queries, function invocations, or transactions.
Network traffic: data transferred in and out (often measured in GB).

New users often assume the cloud behaves like a one-time purchase. In contrast, metering rewards turning things off when you don't need them. A test virtual machine left running over a weekend can cost more than the same VM used for one hour.

A second surprise comes from "small" items that persist. A stopped workload might still keep a disk, reserved address, snapshot, or load balancer. Those pieces continue to accrue charges because the provider still allocates capacity.

From a help desk view, you can reduce surprises with a few repeatable actions:

Check usage dashboards early, then compare day-over-day trends. Spikes often match a deployment, update, or new feature.
Use tags (labels) for cost grouping, such as department, project, environment (prod/test), and owner. Tags make accountability possible.
Set budgets and alerts so the team gets warned before a bill becomes painful. Alerts work best when tied to both total spend and key services (compute, storage, network).
Review "always on" resources weekly. If no one owns it, it tends to linger.

Support mindset: if a resource exists, the provider can probably meter it. "Turned it on and forgot it" is a common root cause.

Ingress vs. egress, the network traffic that can drive the bill

Cloud networking charges often hinge on direction. Ingress means data moving into the cloud service. Egress means data moving out of the cloud service to users, to the internet, or to another site.

Many providers price ingress and egress differently. Ingress is often free or cheaper, while egress commonly costs more because it consumes outbound bandwidth and edge capacity. The exact pricing varies, so focus on the concept: outbound data can become a steady cost center.

Here are patterns you will see in tickets and billing reviews:

Backups sent to the cloud (ingress): A server uploads nightly backup files to cloud storage. The upload is ingress. Storage growth is a separate meter.
Streaming and downloads (egress): Users download videos, installers, reports, or images hosted in cloud storage. Each download pushes data out, so egress rises with popularity.
Cross-region replication (often egress): Data copied from one region to another leaves the source region. That outbound leg is frequently billed as egress, even though it stays inside the same provider.

A quick round-number example shows how egress adds up. Suppose a team hosts training videos in cloud storage. Each employee downloads 2 GB per week. With 50 employees, that is 100 GB per week, or about 400 GB per month. If egress costs $0.09 per GB, the monthly outbound charge is about $36 (400 × 0.09), before storage and requests. That number grows fast when customers and public users join in.

For exam questions, watch for this clue: "data leaving the cloud" almost always points to egress charges. If the prompt mentions downloads to users, exporting data, or sending results back to an on-premises site, think egress first.

Common metering traps, storage growth, snapshots, and chatty apps

Metering problems often come from resources that quietly multiply. Storage is the classic case. A file share may start small, then grow each day as users add media, backups, and exports. Because many storage charges use GB-month, even a slow increase becomes permanent spend.

Snapshots and backups create a second trap. Teams take a snapshot "just in case" during testing, then forget to remove it. Over time, old snapshots pile up, and so do costs. Duplicate backups can also happen when both an agent and a platform tool back up the same data set. In addition, versioned objects (keeping older copies of files) help with recovery, yet they increase stored data behind the scenes.

Logging can surprise people too.