A quick dip into the world of cloud computing, framed around the Cloud + domains, and designed for the average IT professional! This blog explains Cloud + in easy language, delivering high level content in an easy to understand and hopefully interesting way. This blog is here to help you, and me, stay fresh on these core concepts we use in our profession or for fun.
Reference notes for blog series on CompTIA certifications. Source: CompTIA Cloud+ CV0-004 Certification Exam Objectives, Version 2.0 (© CompTIA, Inc.). Exam launched September 24, 2024, replacing CV0-003 (retired ~March/April 2025). Estimated retirement for CV0-004: ~2027.
Covers how to design and reason about cloud environments at a high level.
Service models & shared responsibility: IaaS, PaaS, SaaS, and FaaS, plus understanding what the provider vs. the customer is responsible for securing.
Service availability & DR: Regions, availability zones, cloud bursting, edge computing, and disaster recovery concepts like RTO/RPO and hot/warm/cold sites; also multicloud tenancy.
Networking fundamentals: VPNs, dedicated connections, load balancers, gateways, CDNs, firewalls, VPC peering/transit gateways, subnetting, VLANs, SDN, and routing (BGP, static routes, route tables).
Storage: Tiered storage (hot/warm/cold/archive), SSD vs. HDD, and object/block/file storage, including performance and cost tradeoffs.
Cloud-native design: Managed services, microservices, loosely coupled architecture, fan-out patterns, service discovery.
Containers & virtualization: Orchestration, port mapping, persistent vs. ephemeral storage, image registries, clustering, cloning, host affinity, and virtual networking/storage types.
Cost management: Billing models (dedicated host, reserved, pay-as-you-go, spot), resource metering, tagging, rightsizing.
Databases: Relational vs. non-relational, self-managed vs. provider-managed.
Workload optimization: Compute types (VM, container, serverless), orchestration, network latency/throughput, storage IOPS.
Emerging tech: AI/ML use cases (text/voice recognition, generative AI, sentiment analysis) and IoT (sensors, gateways, transmission protocols).
Covers how resources actually get built and rolled out.
Deployment models: Public, private (including on-prem), hybrid, community.
Deployment strategies: Blue-green, canary, rolling, in-place.
Migration: Migration directions (on-prem-to-cloud, cloud-to-cloud, etc.), key considerations (cost, compliance, vendor lock-in, environmental factors), and application migration strategies (rehost, replatform, re-architect, retain, retire, refactor).
Infrastructure/Configuration as Code: Scripting logic (variables, conditionals, functions), drift detection, versioning, testing, documentation, and formats like JSON/YAML.
Provisioning: Matching resources to storage, performance, security, cost, availability, compliance, network, and compute requirements.
Covers day-to-day running and maintenance of cloud environments.
Observability: Logging (collection, aggregation, retention), tracing, monitoring/metrics, and alerting/triage.
Scaling: Triggered (trend, load, event-based), scheduled, or manual scaling; horizontal vs. vertical.
Backup & recovery: Incremental/full/differential backups, on-site vs. off-site storage, retention, replication, encryption, recoverability/integrity testing, and recovery types (in-place, parallel, bulk, granular).
Lifecycle management: Patches, major/minor updates, ephemeral vs. persistent data, decommissioning (end of life/support).
Covers securing the environment end to end.
Vulnerability management: Scanning scope, identification, assessment, remediation, CVEs.
Compliance: Data sovereignty, ownership, locality, classification, retention; standards like SOC 2, PCI DSS, ISO 27001, Cloud Security Alliance.
IAM: Secure access methods (API, SDK, CLI, web portal, SSH, RDP, bastion hosts), authentication models (federation/SAML, token-based, MFA, OpenID Connect), authorization models (RBAC, group-based, OAuth 2.0), and audit trails.
Security best practices: Zero Trust, CIS benchmarks, hardening, patching, encryption (in transit/at rest), secrets management, API security, least privilege, container security, storage security.
Security controls: Endpoint protection, DLP, IPS/IDS, DDoS protection, IAM policies, firewalls (ACLs, WAF, network security groups).
Threat monitoring: Baseline deviation, unnecessary open ports, and attack types (phishing, ransomware, DDoS, cryptojacking, zombie instances, metadata attacks).
The newest domain, added in CV0-004.
Source control: Version management, code review, pull requests, commits/merges, branch management.
CI/CD pipelines: Automation, build/test/deploy workflows, security integration, artifacts (VM/container images, RPM/Debian packages), public vs. private repositories.
Systems integration: Event-driven architectures, REST/SOAP/RPC web services, WebSockets, GraphQL.
DevOps tooling: Ansible, Docker, the ELK stack, Git, GitHub Actions, Grafana, Jenkins, Kubernetes, Terraform.
Covers diagnosing and resolving problems across the stack.
Deployment issues: Incompatibility, misconfigurations, sizing/permission issues, deprecated components, outages, API throttling, regional service limits.
Network issues: DHCP/DNS/NTP/NAT failures, latency, bandwidth bottlenecks, misconfigured devices, IP addressing/routing/switching problems (including VLAN tagging and trunk port issues).
Security issues: Deprecated ciphers, privilege escalation, unauthorized access, leaked credentials, software vulnerabilities, unauthorized software.
Exam details: Max 90 questions (multiple-choice + performance-based), 90-minute time limit, passing score 750 (scale of 100–900). Recommended experience: 2–3 years as a systems administrator or cloud engineer, plus Network+/Server+ level knowledge.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 4. Security. (Published July, 2026)
Last month we talked about finding and fixing vulnerabilities. This month we talk about a topic that rarely gets anyone excited in an interview, but shows up in real contracts constantly, compliance. If you have ever seen a vendor questionnaire asking whether your company is SOC 2 certified, or watched a deal stall out because nobody could confirm PCI DSS compliance, this subdomain explains why that paperwork matters as much as it does.
Before getting into named standards, CompTIA wants you comfortable with a handful of underlying concepts that most compliance requirements are actually built around.
Data sovereignty refers to the idea that data is subject to the laws of the country where it is physically stored, which matters enormously in the cloud since your data might be sitting in a data center on a different continent than you expect.
Ownership covers who actually retains legal rights and control over data, which in nearly every cloud service model remains the customer, not the provider, no matter how much infrastructure the provider is managing.
Locality is closely related to sovereignty, referring to the specific geographic location where data physically resides, which some regulations require you to control or restrict directly.
Classification means categorizing data based on its sensitivity, like public, internal, confidential, or restricted, so that appropriate protections get applied based on how sensitive something actually is rather than treating every piece of data identically.
Retention determines how long data must legally be kept, or in some cases, how long it must not be kept past a certain point, since some regulations mandate deletion after a defined period just as firmly as others mandate preservation.
SOC 2 is a framework focused on how a service organization handles customer data, evaluated across categories like security, availability, and confidentiality. A SOC 2 report is often what a business customer asks for before trusting a cloud vendor with their data, since it provides independent verification that the vendor's controls actually hold up under scrutiny.
PCI DSS, the Payment Card Industry Data Security Standard, applies to any organization handling credit card information. It lays out specific technical and procedural requirements for protecting cardholder data, and noncompliance can mean losing the ability to process card payments at all, which tends to get an organization's attention quickly.
ISO 27001 is an international standard for information security management systems, covering the broader organizational processes around identifying risks and managing security systematically, rather than focusing on one narrow type of data like PCI DSS does.
Cloud Security Alliance, often referenced through its Cloud Controls Matrix, provides a cloud-specific framework of security controls, built specifically around the unique risks of cloud environments rather than adapting a framework that was originally designed for traditional data centers.
It might seem redundant to have this many overlapping frameworks, but each one exists because it answers a slightly different question for a slightly different audience. PCI DSS exists because payment processors needed a very specific, narrow standard focused entirely on card data. SOC 2 exists because business customers needed a general way to evaluate any vendor's data handling practices, regardless of industry. ISO 27001 exists because organizations needed a comprehensive management framework, not just a narrow checklist. Cloud Security Alliance exists because none of the earlier standards were originally designed with cloud specific risks in mind.
Think of it like different types of home inspections. A general home inspection checks the overall structure. A separate pest inspection focuses narrowly on termites. A pool inspection focuses specifically on pool safety. Each one is genuinely useful, and none of them fully replaces the others, because each is answering a different, more specific question.
Compliance is often dismissed as pure paperwork, and to be fair, a lot of it genuinely is paperwork. But the underlying purpose is real. These frameworks exist because trusting a vendor with sensitive data based purely on their word has a long, well documented history of going badly. Compliance certifications give customers, regulators, and business partners an independently verified reason to actually trust that a company's security claims hold up, rather than just taking their word for it.
Next month we stay in Domain 4 and revisit identity and access management, this time through the lens of the current exam, covering secure access methods, authentication models, and authorization models in more depth than we did back under CV0-003.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 4. Security. (Published June, 2026)
Domain 3 is behind us, and we move into Domain 4, Security, which makes up 19 percent of the exam. If you have been following this series since the CV0-003 days, some of this domain will feel like familiar ground revisited with a slightly different lens. We start where any good security program starts, with actually finding the weaknesses before someone else does.
Before you can find vulnerabilities, you have to decide what you are actually looking at. Scanning scope defines the boundaries of a vulnerability assessment, whether that covers a single application, an entire network segment, or the whole cloud environment end to end. Scope matters more than it sounds like it should, because a scan that is too narrow gives a false sense of security, while a scan that is too broad without proper planning can produce so much noise that nothing meaningful stands out.
Identification is the process of actually detecting vulnerabilities, typically using automated scanning tools that check systems against known issues, misconfigurations, and outdated software. This is the stage most people picture when they think of vulnerability management, the scanner running overnight and producing a long list of findings by morning.
Not every vulnerability identified in a scan deserves the same level of urgency, and assessment is the step where each finding gets evaluated for real world risk. A vulnerability sitting on a system with no internet exposure and no sensitive data is a very different concern than the same vulnerability sitting on a public facing server handling customer payment information. Assessment takes the raw list from identification and turns it into something prioritized and actually actionable.
Remediation is where the vulnerability actually gets addressed, whether that means applying a patch, changing a misconfiguration, or in some cases retiring a system entirely if fixing it properly is not realistic. This ties directly back to the patching and lifecycle concepts we covered last month. Identifying a problem and never actually fixing it provides exactly zero security benefit, no matter how thorough the scanning process looked on paper.
CVE stands for Common Vulnerabilities and Exposures, and it is essentially a standardized catalog of publicly known security vulnerabilities, each with its own unique identifier. Instead of every vendor and security tool describing the same vulnerability with different names, a CVE gives everyone a shared reference point. When a scanning tool flags a finding tied to a specific CVE, you can look up exactly what that vulnerability is, how serious it is generally considered, and whether a fix already exists, without needing to reverse engineer the problem from scratch every time.
Think of CVEs like a shared numbering system for recalled products. Instead of every manufacturer, retailer, and news outlet describing the same faulty product differently, everyone references the same recall number, and anyone can quickly confirm whether the thing sitting in their own garage is actually affected.
Vulnerability management is not a project with a finish line. New vulnerabilities get discovered constantly, environments change constantly, and yesterday's clean scan does not guarantee today's environment is still in the same shape. This is why scanning, identification, assessment, and remediation form an ongoing cycle rather than a one-time checklist. An organization that scans once a year and calls it done is really just hoping nothing changes in the other eleven months, which is not a security strategy so much as a wish.
Vulnerability management is the practice of staying honest with yourself about the actual state of your environment, rather than assuming things are fine because nothing has gone wrong yet. The organizations that get breached badly are rarely the ones with zero vulnerabilities. They are usually the ones with vulnerabilities that were identified, sitting in a report somewhere, and never actually got prioritized or fixed before someone else found them first.
Next month we stay in Domain 4 and talk about compliance, covering the alphabet soup of standards like SOC 2, PCI DSS, and ISO 27001 that show up constantly in real world cloud contracts.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 3. Operations. (Published May, 2026)
Last month we talked about making sure your data survives a disaster. This month closes out Domain 3 with lifecycle management, the ongoing responsibility of keeping systems current while they are in service, and eventually making the harder call to retire them when their time is actually up.
Patches are small updates, usually addressing a specific bug or security vulnerability, rather than delivering new features. They tend to arrive frequently and are meant to be applied quickly, since a known vulnerability sitting unpatched is exactly the kind of thing attackers actively scan for. The challenge with patching is rarely technical. It is organizational, since applying patches promptly requires a process that does not depend on someone remembering to do it manually every single week.
Minor updates typically bring small improvements or fixes without changing how a system fundamentally behaves, and they generally carry a low risk of breaking anything that depends on it. Major updates can introduce significant changes, sometimes including new requirements, deprecated features, or behavior that is genuinely different from before. Treating a major update with the same casual confidence as a minor one is a common way engineers get burned, since a major update deserves testing that a routine minor patch usually does not need.
We touched on this back when we covered containers, and it resurfaces here because lifecycle management has to account for both types of data differently. Ephemeral data is temporary and disappears once its associated resource is destroyed, which is fine as long as nothing important was relying on it sticking around. Persistent data is meant to survive independently of any single resource's lifecycle, and lifecycle management has to make sure that data actually gets backed up, migrated, or preserved correctly whenever the systems around it get updated, replaced, or retired.
Eventually, every system reaches the end of its useful life, and decommissioning is the deliberate process of retiring it rather than just letting it quietly rot in place. This usually happens around two milestones. End of life means the vendor or provider is no longer developing or improving a product, though some support may still exist for a while longer. End of support means even that support has stopped, and any vulnerabilities discovered after that point will simply never get patched, no matter how serious they turn out to be.
Running something past its end of support date is one of the most common ways organizations end up with a serious, well known vulnerability sitting quietly in production, not because anyone made a bad decision, but because nobody made a decision at all. The system kept working, so nobody circled back to it, right up until it became the exact system an attacker chose to target.
Decommissioning sounds simple in theory and turns out to be one of the more emotionally and organizationally difficult parts of lifecycle management in practice. Systems accumulate dependencies nobody fully mapped out. That old server might be running one small script that three other teams quietly rely on without anyone remembering it exists. Properly decommissioning something means actually tracing out what depends on it first, rather than just shutting it off and waiting to see who complains.
Think of it like finally cleaning out a garage that has been slowly filling up for a decade. Some things are obviously fine to throw away. Others turn out to be holding up a shelf you did not realize was structural. The only way to find out safely is to actually check before you start removing things, not after something falls.
Lifecycle management is really about accepting that nothing in a cloud environment is a one-time build-and-forget project. Patches need to keep flowing. Updates need honest risk assessment rather than blind trust. And eventually, difficult conversations need to happen about whether an aging system still earns its place in production, or whether it is quietly becoming the biggest risk in the environment simply because nobody wanted to deal with retiring it.
With that, Domain 3, Operations, is complete. Next month we move into Domain 4, Security, starting with vulnerability management, or how you actually find the cracks in your environment before someone else does.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 3. Operations. (Published April, 2026)
Last month we talked about scaling resources up and down to match demand. This month we talk about the subdomain everyone agrees is important and almost nobody actually tests thoroughly until it is too late, backup and recovery. Every engineer has a story about a backup that turned out not to actually work when it mattered, and this subdomain exists specifically to keep that story from becoming yours.
CompTIA wants you comfortable with three backup types, and the differences come down to how much gets copied each time.
Full backups copy everything, every single time. This is the most complete and the simplest to restore from, but it also takes the longest to run and consumes the most storage.
Incremental backups only copy what has changed since the last backup, whatever type that previous backup was. This is fast and storage efficient, but restoring means applying the last full backup and then every incremental backup after it, in order, which takes longer and adds more room for something to go wrong along the chain.
Differential backups copy everything that has changed since the last full backup, regardless of how many backups have happened in between. This lands in the middle. Restoring only requires the last full backup plus the most recent differential, without needing every single incremental step in between.
A backup that lives in the exact same location as the data it is protecting is vulnerable to the exact same disaster that could take out the original. On-site backups are fast to access and restore from, which is genuinely useful for routine, everyday recovery needs. Off-site backups live somewhere physically separate, protecting against scenarios where the entire original location becomes unavailable, whether that is a fire, a flood, or simply a very bad day for a data center.
Retention determines how long backups actually stick around before getting deleted, balancing the value of having historical recovery points against the cost of storing them indefinitely. Replication means keeping copies of data synchronized across multiple locations, which blurs the line between backup and high availability, since a well replicated system can sometimes recover almost instantly rather than requiring a formal restore process. Encryption protects backup data itself, since an unencrypted backup sitting somewhere off-site is just as much of a security risk as the original data would be if it were exposed.
Here is the uncomfortable truth this subdomain is really built around. A backup that has never actually been tested is a backup you are simply hoping works. Recoverability testing means periodically actually restoring from a backup to confirm the process works end to end, not just assuming it does because the backup job reported success. Integrity testing verifies the backed up data itself is not corrupted, incomplete, or silently damaged in some way that would only surface the moment you desperately needed it.
Skipping this step is like buying a fire extinguisher, storing it in the garage, and never checking whether it is actually charged. Everyone feels safer having it there. Only some of those people find out the hard way that it would not have helped.
In-place recovery restores data directly back to its original location, overwriting whatever is currently there. Parallel recovery restores data to a separate location alongside the original, useful when you want to verify the restored data before fully cutting over. Bulk recovery restores a large volume of data all at once, often used for full system restores. Granular recovery restores a much smaller, specific piece of data, like recovering a single accidentally deleted file rather than restoring an entire system just to get it back.
Backup and recovery is one of the few IT disciplines where being right ninety nine percent of the time is not actually good enough, because the one percent where it fails is usually the exact moment you needed it the most. The organizations that handle disasters gracefully are the ones that already tested their restore process long before disaster struck, not the ones that simply assumed the backup job's green checkmark meant everything was fine.
Next month we close out Domain 3 with lifecycle management, covering patches, updates, and the surprisingly difficult decision of finally letting something old get decommissioned.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 3. Operations. (Published March, 2026)
Last month we talked about actually knowing what your environment is doing. This month we talk about what you do with that knowledge, specifically when it tells you demand is climbing and your current setup is not going to cut it much longer. Scaling is the practice of adjusting the amount of resources available to a workload, and CompTIA wants you comfortable with a few different ways that adjustment can actually get triggered.
Triggered scaling means the system automatically adjusts resources based on real-time conditions, without a human manually stepping in each time. There are a few flavors worth knowing.
Trend-based scaling looks at patterns over time, gradually adjusting resources as usage trends upward or downward across days or weeks, rather than reacting to a single spike.
Load-based scaling reacts directly to current resource usage, like CPU or memory hitting a certain threshold, and adds or removes capacity in response almost immediately.
Event-based scaling reacts to a specific occurrence rather than an ongoing metric, like a scheduled product launch triggering a temporary burst of additional capacity the moment traffic starts flowing in.
Think of triggered scaling like a restaurant automatically calling in extra staff the moment the dining room starts filling up, rather than waiting for a manager to notice and make a phone call.
Scheduled scaling does not wait for a trigger at all. Instead, it adjusts capacity based on a known, predictable pattern, like scaling up every weekday morning when employees log in, and scaling back down every evening when they log off. If a business already knows its busy periods in advance, there is no reason to wait for a metric to cross a threshold before reacting. You just tell the system ahead of time.
This is the restaurant equivalent of already knowing Friday and Saturday nights are busy, and simply scheduling extra staff for those shifts every week without waiting to see how busy it actually gets first.
Manual scaling is exactly what it sounds like. A person decides resources need to change and makes that change directly, without any automated trigger or schedule involved. This still has its place, particularly for unusual situations that do not fit a predictable pattern and were not anticipated by any automated rule, like an unplanned marketing mention that suddenly spikes traffic somewhere nobody expected.
Beyond the question of what triggers scaling, there is also the question of how the scaling actually happens.
Horizontal scaling adds more instances of a resource, like spinning up additional servers to share the load. This is often the more flexible option in cloud environments, since it plays well with load balancing and lets you add or remove capacity in smaller increments.
Vertical scaling makes an existing resource bigger, like upgrading a server to have more CPU and memory rather than adding more servers. This can be simpler for certain workloads, particularly ones that were not designed to run across multiple instances, but it usually has a hard ceiling. Eventually you run out of bigger machine to upgrade to.
Think of horizontal scaling as adding more checkout lanes at a grocery store, and vertical scaling as replacing one checkout lane with a much faster one. Both approaches can handle more customers, but they solve the problem in genuinely different ways, and one of them runs out of room to keep improving a lot sooner than the other.
Picking the right scaling approach is really about matching the shape of your traffic to the shape of your response. A workload with wildly unpredictable spikes benefits enormously from triggered, load-based scaling. A workload with steady, well known daily patterns might do just fine on a schedule, saving the overhead of constantly reacting to metrics that were always going to follow the same predictable curve anyway. Getting this wrong in either direction is expensive. Over-provision for a spike that never comes and you are paying for capacity nobody used. Under-provision for a spike that does come and you are the one explaining to customers why the checkout page would not load during your biggest sale of the year.
Next month we cover the subdomain that exists specifically so that last sentence never has to be an actual conversation, backup and recovery.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 3. Operations. (Published February, 2026)
Domain 2 is finally behind us. This month we move into Domain 3, Operations, which covers the day-to-day running and maintenance of a cloud environment rather than the one-time work of designing or deploying it. We start with observability, which sounds like a fancy word for "did anyone notice the thing before it broke," and honestly, that is not far off.
Logging is the practice of recording events as they happen, whether that is a user logging in, an application throwing an error, or a server restarting unexpectedly. On its own, a single log entry is not particularly useful. The value shows up once you have enough of them, organized well enough, to actually spot a pattern.
Collection is the process of actually gathering logs from every source producing them, whether that is a handful of servers or thousands of containers spinning up and down constantly. Aggregation takes all those scattered logs and pulls them into one central place, so nobody has to log into fifty different servers individually to piece together what happened. Retention covers how long you actually keep those logs around, balancing the very real value of historical data against the very real cost of storing mountains of text nobody may ever read again.
Logging tells you what happened at a given point. Tracing follows a single request as it travels through an entire system, often touching multiple microservices along the way. If a user's checkout request passes through an authentication service, an inventory service, a payment service, and a shipping service, tracing stitches all of that together so you can see the full journey in one place, rather than trying to manually correlate four separate sets of logs after the fact.
This matters enormously in a microservices architecture, the kind we talked about back in Domain 1. When a request is slow, tracing tells you exactly which service in that chain is the bottleneck, instead of leaving you to guess.
Monitoring involves continuously tracking the health and performance of a system through metrics, meaning numerical measurements like CPU usage, memory consumption, request rates, and error counts. Where logs tell a detailed story about individual events, metrics give you a quick, numerical pulse check on how the whole system is doing right now.
Good monitoring means knowing what normal looks like for your environment, so you can actually recognize when something has drifted away from it. A server running at eighty percent CPU might be perfectly normal for one application and a five alarm fire for another.
Collecting all this data does nothing if nobody gets told when something goes wrong. Alerting is the practice of automatically notifying the right people when a metric crosses a concerning threshold or a specific error pattern shows up in the logs. Triage is what happens next, the process of quickly assessing how serious an alert actually is and deciding what to do about it first.
Not every alert deserves the same urgency. A single failed login attempt is very different from an entire service returning errors to every user. Good triage separates genuine emergencies from noise, which also protects against something called alert fatigue, where too many low priority notifications train people to start ignoring alerts altogether, right up until the one that actually mattered gets missed in the pile.
Logging, tracing, monitoring, and alerting are not four separate tools competing for attention. They are four layers of the same underlying goal, actually knowing what is happening inside a system rather than finding out from an angry customer. Monitoring tells you something is wrong. Metrics and alerting tell you how urgent it is. Logs and traces tell you why it happened and where to look. Skip any one layer, and you either find out too late, or you find out in time but have no way to actually diagnose the problem.
Observability is the difference between an operations team that reacts to outages after customers start complaining, and one that catches a problem quietly before it ever reaches that point. A well instrumented environment feels almost boring from the outside, because problems get caught and fixed before anyone notices. That boring, uneventful experience is actually the entire goal, and it does not happen by accident.
Next month we stay in Domain 3 and talk about scaling, meaning how an environment actually grows and shrinks to match real demand instead of sitting stuck at whatever size it happened to launch with.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 2. Deployment. (Published January, 2026)
Happy New Year, and welcome to the last stop in Domain 2. We have spent the last few months talking about deployment models, deployment strategies, migration, and infrastructure as code. Provisioning ties all of that together into the actual decision making process of matching a set of requirements to the resources that will satisfy them. If solution design analysis, back in Domain 1's ancestor subdomain, was about asking the right questions early, provisioning is about actually answering them with real infrastructure.
It would be easy to think of provisioning as simply picking resources off a menu. In practice, it is closer to solving a puzzle with several interlocking pieces, where getting one piece wrong throws off several others. CompTIA wants you comfortable matching resources against eight separate categories of requirements, and treating each one as its own consideration rather than an afterthought.
Storage requirements cover how much space something needs, and just as importantly, what kind of storage performance it needs, tying directly back to the tiered storage and IOPS concepts we covered back in Domain 1.
Performance requirements cover raw compute power, memory, and throughput needed to keep an application responsive under real load rather than just a demo.
Security requirements cover what protections need to be built in from the start, rather than bolted on afterward, echoing the same lesson from solution design analysis.
Cost requirements cover the budget reality of what an organization can actually afford to run long term, not just what would be nice to have.
Availability requirements cover how much downtime is genuinely tolerable, which determines whether a workload needs to be spread across multiple availability zones or regions.
Compliance requirements cover whatever regulations apply to the data or industry involved, which can dictate where resources are allowed to physically live.
Network requirements cover bandwidth, latency, and connectivity needs, making sure the digital plumbing can actually handle what is about to run through it.
Compute requirements cover which compute type, virtual machine, container, or serverless function, actually fits the shape of the workload, tying back to workload optimization from a few months ago.
These eight categories rarely exist in isolation. A workload with strict compliance requirements might limit which regions you can provision in, which then affects availability options, which then affects cost. A workload with high performance requirements might need expensive, high IOPS storage, which changes the budget conversation entirely. Provisioning done well means holding all of these tradeoffs in your head at once, rather than optimizing for one category while quietly ignoring the rest.
Think of it like furnishing a house you are renting for a specific purpose. If you are hosting frequent large family gatherings, you provision a big dining table and extra seating. If you are running a home office, you provision good lighting and a reliable desk instead. Buying the same furniture regardless of what the house is actually for usually means overspending on things you do not need while somehow still missing something essential.
It is tempting to treat provisioning as something that happens once, at launch, and then never gets revisited. In reality, requirements change. A workload that started small might outgrow its original storage tier. A compliance requirement might shift after a company expands into a new region. Revisiting provisioning decisions periodically, rather than treating the original setup as permanent, is what keeps an environment matched to what it actually needs rather than what it needed eighteen months ago.
Provisioning is really the practical, hands-on version of everything Domain 1 and the rest of Domain 2 have been building toward. Understanding storage tiers, compute types, deployment models, and cost management does not help much if nobody actually applies that knowledge when it is time to build something real. Get provisioning right, and infrastructure quietly does its job without anyone downstream noticing the thought that went into it. Get it wrong, and you end up either overpaying for capacity nobody uses, or scrambling to fix a workload that was undersized from the start.
With that, Domain 2, Deployment, is officially complete. Next month we move into Domain 3, Operations, starting with observability, or how you actually know what your environment is doing once it is up and running.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 2. Deployment. (Published December, 2025)
Last month we talked about moving workloads from one place to another. This month we talk about the practice that makes migrations, deployments, and just about everything else in this series actually repeatable instead of a one-time act of heroics performed by whoever remembers the steps. That practice is infrastructure as code, often shortened to IaC, and configuration as code alongside it.
Infrastructure as code means defining your servers, networks, storage, and other resources in text files rather than manually clicking through a web console every time you need something built. Instead of remembering the fifteen steps it takes to spin up a properly configured virtual machine, you write those fifteen steps down once, in a file, and let a tool execute them consistently every single time.
Configuration as code applies the same philosophy to the software and settings running on top of that infrastructure, like ensuring a server always has the right packages installed or the right security settings applied. Together, these practices turn infrastructure from something built by hand into something built from a recipe anyone on the team can read, run, and trust.
CompTIA wants you familiar with the basic scripting concepts that make these definition files actually useful rather than just a static list of settings. Variables let you swap out values, like an environment name or a server size, without rewriting the whole script. Conditionals let the script make decisions, like only creating a certain resource if a specific environment is being built. Functions let you package up a chunk of logic once and reuse it repeatedly instead of copying and pasting the same block everywhere. None of this is exotic programming. It is the same basic logic found in most scripting languages, just applied to describing infrastructure instead of an application.
Even in a well run environment, someone eventually logs into the console and manually changes a setting outside of the defined script, usually during an emergency at two in the morning. Drift detection is the practice of comparing the actual state of your environment against what the code says it should be, flagging any differences. Without drift detection, that midnight emergency fix quietly becomes an undocumented exception that nobody remembers exists until it causes a mysterious problem months later.
Versioning means tracking changes to your infrastructure code over time, the same way you would track changes to application code, so you can see exactly what changed, when, and roll back if a change causes problems. Testing means validating that a change to your infrastructure definitions actually works as intended before it touches anything real, rather than finding out in production. Documentation means making sure the reasoning behind a given configuration is written down somewhere, so the next person, or future you, does not have to reverse engineer why a setting exists.
None of these three practices are unique to infrastructure as code, but skipping them here causes exactly the same problems it causes in application development. Untested changes break things. Undocumented decisions get accidentally undone by someone who did not know why they existed in the first place.
Most infrastructure as code tools describe resources using structured text formats, and JSON and YAML are the two the exam wants you comfortable recognizing. JSON uses curly braces and is common in APIs and many cloud provider templates. YAML uses indentation instead of brackets and tends to read a little more like plain English once you get used to it, which is part of why a lot of configuration management tools default to it. Neither format is inherently better. They are just different ways of writing down the same structured information, and plenty of tools support both.
Infrastructure as code turns environment setup from tribal knowledge living in one engineer's head into something the entire team can read, review, and trust. It makes disaster recovery dramatically less terrifying, since rebuilding an environment from scratch becomes running a script instead of trying to remember every manual step from two years ago. Skip it, and you end up with what people in the industry sometimes call a snowflake environment, a system so uniquely and manually configured that nobody fully understands it and nobody wants to touch it.
Next month we close out Domain 2 with provisioning, the practice of actually matching what you build to what a workload really needs.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 2. Deployment. (Published November, 2025)
Last month we talked about how new code ships into an already running environment. This month we talk about something a little more dramatic, moving an entire workload from one place to another. Migration is one of those topics that sounds simple in a slide deck and then turns into a multi-month project the moment anyone actually starts the work.
The exam wants you comfortable with the fact that migration is not just "moving to the cloud." There are several directions a migration can actually take. On-prem to cloud is the classic version, moving a workload out of a company's own data center and into a public or private cloud environment. Cloud to cloud happens when a company moves workloads from one provider to another, often after a merger, a pricing change, or simply a change of heart about which provider fits best. There is also the less glamorous but very real direction of cloud back to on-prem, sometimes called repatriation, when a company decides a workload actually belongs back in their own data center after all.
Before any migration actually happens, there is a list of considerations that determine whether the move goes smoothly or turns into a nightmare. Cost is the obvious one, covering not just the destination environment but the migration process itself, which is rarely free. Compliance matters just as much, since moving data across borders or between providers can trigger regulatory requirements that did not apply before. Vendor lock-in is the quiet risk of designing a migration so tightly around one provider's specific tools that leaving later becomes painfully expensive. Environmental factors round this out, covering things like data center energy usage and sustainability commitments that some organizations genuinely weigh as part of the decision.
This is the part of the subdomain most worth memorizing, since CompTIA loves testing scenario questions around which strategy fits a given situation.
Rehost means moving an application as-is, with minimal changes, often called lift and shift. It is the fastest option, but it does not take advantage of anything the new environment offers beyond just hosting the same thing somewhere else.
Replatform makes small optimizations during the move, like swapping a self-managed database for a managed one, without fully redesigning the application itself.
Re-architect goes further, redesigning the application to actually take advantage of cloud-native features, like breaking a monolith into microservices. This is the most work, but it is also the option that gets the most long-term value out of the move.
Retain means deciding not to migrate a particular application at all, at least for now, usually because it is too risky, too costly, or simply not worth the effort relative to what it delivers.
Retire means the application gets shut down entirely instead of migrated, often because nobody actually uses it anymore, or because its functionality has been absorbed into something else.
Refactor means rewriting the application from the ground up. This overlaps conceptually with re-architecting but usually implies an even more significant rebuild, sometimes changing the underlying code and technology stack almost entirely.
Think of these six options like moving out of an old house. Rehosting is packing every box exactly as it sits and unpacking it the same way in the new place. Replatforming is taking the opportunity to swap out that one appliance you always hated while you are at it. Re-architecting is redesigning the whole layout to actually fit how you live now. Retaining is deciding a piece of furniture just is not coming with you this time. Retiring is finally throwing out the thing you have been meaning to get rid of for years. Refactoring is building custom furniture from scratch because nothing you already own fits the new space.
Migration decisions rarely get revisited once they are made, which is exactly why picking the right strategy matters so much upfront. Rehosting everything because it is fast and easy might save time today, while quietly setting up a more expensive and more painful re-architecture project two years down the road. Retiring an application nobody actually needs anymore can save more money than any clever technical migration ever would. The skill here is not memorizing six vocabulary words. It is honestly assessing what each specific application actually needs, rather than defaulting to whichever strategy feels the least intimidating in the moment, or the one that happened to work out well for a completely different application last time.
Next month we talk about the practice that makes repeatable, predictable migrations and deployments possible in the first place, infrastructure as code.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 2. Deployment. (Published October, 2025)
Last month we covered where your infrastructure lives. This month we cover how new code actually gets pushed out into it without taking the whole application down in the process. Anyone who has ever pushed a Friday afternoon update and immediately regretted it will appreciate why this subdomain exists.
The simplest approach is in-place deployment, where you update the existing environment directly. The old version gets replaced with the new one on the same servers, with no parallel environment running alongside it. This is fast and does not require extra infrastructure, but it also means if something goes wrong, users are immediately affected, and rolling back means undoing the update on the same system that just broke.
Blue-green deployment keeps two identical production environments running side by side, conventionally labeled blue and green. At any given time, one is live and handling real traffic while the other sits ready with the new version fully deployed and tested. When you are confident the new version works, you flip traffic over to it, essentially like flipping a light switch.
The advantage here is that rolling back is nearly instant. If something goes wrong with the new version, you just flip traffic back to the old environment, which never stopped running in the background. The tradeoff is cost, since you are effectively paying for two full production environments, even if one of them is only actively serving traffic part of the time.
Canary deployment gets its name from the old coal mining practice of bringing a canary down into the mine to detect dangerous gas before it affected the miners. In a cloud context, a canary deployment rolls out a new version to a small subset of users or servers first, while the majority of traffic keeps hitting the old version.
If the canary group experiences problems, you catch it early, affecting only a small slice of your user base rather than everyone at once. If things look healthy, you gradually expand the rollout to more users until the new version handles all traffic. This strikes a middle ground between the speed of in-place deployment and the safety net of blue-green.
Rolling deployment updates servers in a cluster gradually, a portion at a time, rather than all at once or through a single instant switch. If you have ten servers running an application, a rolling deployment might update two at a time, waiting for those to come back healthy before moving on to the next batch.
This avoids the cost of maintaining a full duplicate environment like blue-green does, while still avoiding the all-or-nothing risk of a pure in-place deployment. The tradeoff is that during the rollout, some users are hitting the old version while others are hitting the new one, which means your application needs to tolerate both versions running simultaneously for a while.
None of these four strategies is universally correct, and the exam wants you comfortable recognizing which situation favors which approach. A small internal tool with low stakes might reasonably use in-place deployment, since the cost of occasional downtime is minor. A payment processing system handling real money probably wants blue-green or canary, since the cost of a bad rollout affecting everyone at once is a lot higher than the cost of running extra infrastructure temporarily.
Think of it like renovating a restaurant. In-place is closing the whole restaurant for a weekend to remodel everything at once. Blue-green is building an entirely new restaurant next door and only opening it once everything is ready, then redirecting customers over. Canary is quietly testing the new menu on a handful of regular customers before rolling it out to everyone. Rolling is remodeling one section of the dining room at a time while the rest stays open for business.
Deployment strategy is really a conversation about risk tolerance dressed up as a technical decision. How much downtime can you actually accept? How quickly do you need to be able to roll back if something goes wrong? How much are you willing to pay in extra infrastructure to reduce that risk? Answering those questions honestly, before you pick a strategy, saves you from discovering the hard way that your deployment approach did not match what your business could actually tolerate.
Next month we talk about the process of actually getting workloads from one environment to another in the first place, covering cloud migration strategies and the very real headaches that come with moving something that was never built to move.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 2. Deployment. (Published September, 2025)
Domain 1 is officially in the books, all ten subdomains of it. This month we move into Domain 2, Deployment, which makes up 19 percent of the exam and covers how resources actually get built and rolled out rather than how they are conceptually architected. We start with deployment models, a topic long time readers of this series will recognize, since we covered a version of this all the way back in our very first post under the old exam.
The good news is that the underlying concepts have not changed. The slight difference is that CV0-004 trims this subdomain down to four core models instead of the seven terms CV0-003 wanted you comfortable with. So consider this both a refresher and a tighter, more exam-focused version of that original post.
A public cloud is infrastructure owned and operated by a provider like AWS, Azure, or Google Cloud, and that provider rents out slices of it to anyone willing to pay. You do not own the servers or the building they sit in. You log in and use what you need.
Think of it like renting an apartment in a large building. The landlord owns the property and maintains it. You have your own space, but you are sharing the building's plumbing, electrical systems, and elevators with a lot of other tenants you will never meet.
A private cloud flips that model so one organization gets the whole thing to itself. This can mean the company owns and runs its own data center on-premises, or it can mean a provider sets aside dedicated hardware just for that one client, even if it is technically housed somewhere else. Either version counts as private, since the defining feature is exclusivity, not physical location.
This is the difference between renting an apartment and owning a house. You get full control, and you are the only one with a key. The tradeoff is that you are also the one responsible for the roof, the plumbing, and the electrical bill.
Most real organizations do not pick one model and stick with it forever. A hybrid cloud combines public and private cloud resources, letting data and applications move between them as needed. A company might keep sensitive customer records in a private cloud for tighter control, while running its public-facing website on a public cloud where it is cheap and easy to scale up during a busy sales event.
The point of hybrid is not indecision. It is using each environment for what it does best.
A community cloud is shared, but not shared with random businesses. It is built for a specific group of organizations that have something in common, usually a shared industry, shared compliance requirements, or a shared mission. Think of a group of hospitals in the same region pooling resources into a cloud environment that is built around healthcare data regulations. They are not competitors sharing a public cloud with strangers. They are peers sharing an environment tailored to their specific needs.
If you remember our original post on this topic, you might notice cloud-within-a-cloud, multicloud, and multitenancy are missing here. That is intentional. CV0-004 folds those ideas into other subdomains rather than testing them as standalone deployment models. Multicloud tenancy, for example, shows up under service availability and DR, since it is really a resilience strategy more than a deployment choice on its own. The concepts have not disappeared. They just got reorganized into the places CompTIA thinks they fit better.
None of these four models exist just to make exam questions harder. Choosing public over private is not just about cost. It is about compliance requirements, control, performance needs, and risk tolerance. A hospital system choosing a community cloud is making a very different bet than a startup defaulting to public cloud because it is fast and cheap to get started. Understanding why an organization landed on the model it did tells you a lot about what that organization actually cares about most.
Next month we move from what kind of environment you deploy into to how new code actually gets shipped into it, covering blue-green, canary, rolling, and in-place deployment strategies.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 1. Cloud Architecture. (Published August, 2025)
Last month we wrapped up the compute side of workload optimization. This month closes out Domain 1 entirely with the subdomain that reads the most like a list of conference buzzwords, emerging tech. Do not let the marketing language scare you off though. Underneath the hype, AI, ML, and IoT are just tools with specific jobs, and the exam mostly wants you to recognize what those jobs actually are.
Artificial intelligence and machine learning get thrown around interchangeably in casual conversation, but for exam purposes it helps to think of ML as one of the main tools that makes AI systems actually work. Machine learning is the process of feeding a system a large pile of data and letting it find patterns on its own, rather than programming every rule by hand. CompTIA wants you familiar with a handful of specific use cases rather than the theory behind how any of this actually trains under the hood.
Text and voice recognition covers systems that can take spoken or written language and turn it into something a computer can act on. Every time you dictate a text message or ask a smart speaker to set a timer, this is the category doing the work.
Generative AI refers to systems that produce new content rather than just analyzing existing content. Text, images, code, and audio can all get generated this way. Think of it less like a search engine finding an existing answer and more like a very well read assistant drafting something new based on everything it has absorbed.
Sentiment analysis looks at text, usually things like reviews, support tickets, or social media posts, and tries to determine whether the tone behind it is positive, negative, or neutral. A company scanning thousands of customer reviews to spot an angry trend before it becomes a PR problem is a textbook use case here.
None of these use cases require you to build a model from scratch. Cloud providers offer these as managed services you can plug into, which fits the broader theme of this entire domain. You are not expected to become a data scientist. You are expected to know what these tools are good for and when reaching for one actually makes sense.
Internet of Things, or IoT, covers the growing category of physical devices that collect data and communicate over a network, often with very little human involvement. Think of sensors monitoring temperature in a warehouse, a fleet of delivery trucks reporting their location every few seconds, or a factory floor covered in devices tracking vibration and wear on machinery.
Sensors are the devices actually collecting raw data out in the physical world, whether that is temperature, motion, moisture, or something else entirely.
Gateways sit between those sensors and the wider network, often aggregating data from many sensors before forwarding it along, since it usually is not practical or efficient for every single sensor to talk directly to a cloud service on its own.
Transmission protocols are the languages IoT devices use to actually send that data along. Many of these devices are small, battery powered, and physically remote, so the protocols involved often prioritize low power consumption and reliability over raw speed. A sensor buried in a farm field checking soil moisture does not need blazing bandwidth. It needs to sip battery power for months at a time and still get its reading through.
Two exam versions ago, none of this would have earned its own subdomain. AI, ML, and IoT existed, but they were niche enough that testing them in depth did not make much sense for a general cloud certification. CV0-004 reflects how mainstream these tools have become in ordinary cloud architecture decisions. A retail company forecasting inventory, a hospital monitoring equipment remotely, or a customer service team triaging support tickets by sentiment are not exotic edge cases anymore. They are Tuesday.
The real skill here is not memorizing what AI or IoT technically means. It is recognizing when a given business problem is actually a good fit for one of these tools instead of reaching for them because they sound impressive in a meeting. Sentiment analysis on customer feedback is useful. Sentiment analysis on a spreadsheet of sales numbers is not, because that is not what it is built for. Matching the tool to the actual problem is the skill CompTIA is really testing, dressed up in trendier vocabulary than the rest of the exam.
With that, Domain 1 is finally, completely done. Next month we start fresh in Domain 2, Deployment, beginning with a topic we have technically touched on before but never fully unpacked, deployment models.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 1. Cloud Architecture. (Published July, 2025)
Last month we talked about databases and the tradeoffs between relational structure and NoSQL flexibility. This month wraps up the compute side of that same conversation with workload optimization, which is really just a fancy way of asking one question. Given everything this application actually needs to do, what is the smartest way to actually run it?
By now in this series we have already introduced the three compute types the exam wants you comfortable choosing between, so this month is about actually deciding among them rather than defining them from scratch.
Virtual machines make sense when a workload needs full control over its operating system, has predictable, steady resource needs, or is running legacy software that was never built with containers or serverless functions in mind. VMs are the reliable, familiar option, and sometimes familiar is exactly what a workload needs.
Containers make sense for applications built with microservices in mind, where you need fast startup times, efficient resource usage, and the ability to scale individual pieces of an application independently. If you read our post on containers a few months back, this is where all of that pays off in practice.
Serverless, or FaaS, makes sense for event-driven, intermittent workloads where paying for idle capacity would be wasteful. A function that only runs when a file gets uploaded, or when an API request comes in, is a poor fit for a VM that sits there costing money around the clock waiting for something to happen.
The exam wants you to recognize that picking a compute type is not about which one is objectively the best. It is about matching the shape of the workload to the shape of the compute option, the same way you would not rent a moving truck to pick up a single sandwich, and you would not try to move a house's worth of furniture in a compact car either.
Orchestration ties directly back into optimization, since having the right compute type does not matter much if you are running too much or too little of it. Automatically scaling container clusters up during peak demand and back down overnight, or automatically spinning down VMs that are not being used, is what keeps workload optimization from being a one time decision made at launch and then forgotten about forever.
Even a perfectly sized compute resource can feel slow if the network around it is not cooperating. Latency measures how long it takes for a piece of data to travel from one point to another, while throughput measures how much data can move through that connection in a given amount of time. A workload that is chatty, meaning it sends lots of small, frequent requests back and forth, cares enormously about latency. A workload that moves large files, like video processing, cares more about throughput. Optimizing compute without considering the network it depends on is like buying a sports car and then complaining that traffic is slow.
IOPS, input output operations per second, measures how many read and write operations a storage system can handle in a given time frame. A database handling constant, rapid transactions needs high IOPS to keep up. A system storing rarely accessed archival files does not need nearly as much. Pairing a high-IOPS workload with storage that cannot keep up creates a bottleneck no amount of extra compute power can fix, since the application ends up waiting on the disk instead of the processor.
Workload optimization is really the exam's way of tying compute, orchestration, networking, and storage back together into one coherent decision instead of treating each one in isolation. A workload can be running on perfectly good hardware and still perform badly if the compute type does not match the job, if scaling never adjusts to actual demand, or if storage cannot keep pace with what the application is asking of it. Getting this right is less about chasing the fanciest new compute option available and more about honestly assessing what a given workload actually needs, then building toward that instead of toward whatever felt impressive in a planning meeting.
That wraps up the compute-focused half of Domain 1. Next month we close out Domain 1 entirely with emerging tech, covering AI, ML, and IoT, and why CompTIA finally decided these buzzwords deserved their own section of the exam.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 1. Cloud Architecture. (Published June, 2025)
Last month we talked about the cloud bill, and how easy it is to rack up charges nobody remembers approving. This month we cover a topic that is smaller on the exam than you might expect given how much real world weight it carries, databases. CompTIA keeps this one relatively brief, but do not mistake brevity for unimportance. Choosing the wrong database shape or the wrong management model is the kind of decision that quietly haunts a company for years.
A relational database organizes data into tables, with clearly defined rows and columns, and strict relationships between those tables enforced through structure. Think of it like a very well organized spreadsheet, where every column has a defined data type and every table knows exactly how it connects to every other table. MySQL, PostgreSQL, and SQL Server are the classic examples. Relational databases shine when your data has a clear, consistent structure and when relationships between pieces of data genuinely matter, like an orders table linking back to a customers table.
A non-relational database, often called NoSQL, throws out that rigid structure in favor of flexibility. Data might be stored as documents, key-value pairs, wide columns, or graphs, depending on the specific type of non-relational database you are using. MongoDB, DynamoDB, and Cassandra fall into this category. Think of it less like a spreadsheet and more like a junk drawer that is actually well organized on purpose, where not every item needs to look exactly like the one next to it, and new kinds of items can get added without redesigning the whole drawer.
Neither option is universally better. Relational databases win when structure and consistency matter more than raw flexibility, like financial transactions where you absolutely need every number to add up correctly. Non-relational databases win when your data does not fit neatly into rows and columns, or when you need to scale out horizontally across a huge number of servers without the overhead that strict relational structure can introduce. Plenty of real world systems end up using both at once, storing structured transaction records in a relational database while dumping session data or activity logs into something non-relational, simply because different parts of the same application have genuinely different needs.
The second half of this subdomain is really just an extension of the shared responsibility conversation we covered back when we talked about service models. A self-managed database means you are running the database software yourself, typically on a virtual machine you control. You handle patching, backups, scaling, and troubleshooting when something breaks at an inconvenient hour. This gives you maximum control, along with maximum responsibility.
A provider-managed database, sometimes called Database as a Service, hands most of that operational burden to the cloud provider. Automated backups, patching, and failover are typically handled for you. You still own your data and your access controls, but the provider is the one getting paged when the underlying hardware has a bad night.
Think of the difference like owning a car versus using a ride share service. Owning gives you total control over exactly how everything runs, along with full responsibility for the oil changes and the check engine light. Ride sharing means someone else worries about the maintenance, and you just show up expecting it to work when you need it. Plenty of teams start with self-managed databases because it feels cheaper on paper, then quietly migrate to a managed option once they realize how much staff time actually goes into keeping a database healthy around the clock.
The decision between relational and non-relational, and between self-managed and provider-managed, rarely gets revisited once an application is built around it. Migrating a mature application from one database model to another is genuinely painful, often requiring significant rewrites rather than a simple configuration change. That makes this one of those quiet, unglamorous decisions early in a project's life that ends up shaping how flexible, scalable, and maintainable that system remains years down the road. Get it right early, and nobody ever thinks twice about it. Get it wrong, and it becomes the migration project nobody wants to own.
Next month we look at workload optimization, meaning how to actually pick the right compute type for the job instead of defaulting to whatever felt familiar at the time.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 1. Cloud Architecture. (Published May, 2025)
Last month we talked about containers and clusters. This month we talk about the topic that eventually humbles every engineer who ever said "the cloud is basically free to experiment with." It is not free. It is pay as you go, which sounds friendly right up until you forget to turn something off and it goes for three weeks straight.
Cloud providers offer several different ways to pay for compute resources, and picking the wrong one is a surprisingly common way to overspend without doing anything technically wrong.
Dedicated host billing gives you an entire physical server reserved just for you, rather than sharing hardware with other tenants. This costs more, but it satisfies compliance requirements that demand physical isolation, and it can also help with licensing models tied to physical cores rather than virtual ones.
Reserved instances trade flexibility for savings. You commit to using a certain amount of compute for a set period, usually a year or three, in exchange for a meaningfully lower price than paying moment to moment. This works well for predictable, steady workloads that are not going anywhere.
Pay-as-you-go is the default most people picture when they think of cloud billing. You use what you need, when you need it, and pay only for that. Flexible, but the most expensive option per unit of compute if your usage is steady and predictable rather than sporadic.
Spot instances let you buy unused capacity at a steep discount, with the catch that the provider can reclaim that capacity with little notice if someone else needs it at full price. This works great for workloads that can tolerate interruption, like batch processing jobs, and terribly for anything that needs to stay online no matter what. Think of it like standby airline tickets. Wonderfully cheap, as long as you are not the person who absolutely has to make that specific flight.
Metering is simply the practice of tracking exactly how much of each resource got consumed, whether that is compute hours, storage capacity, or data transferred out to the internet. Without accurate metering, none of the billing models above mean anything, since you would have no way of knowing whether you actually need reserved capacity or whether pay-as-you-go pricing is quietly draining the budget every month.
Tagging attaches metadata labels to cloud resources, things like which department created it, which project it supports, or which environment it belongs to. This sounds like busywork until the day someone asks which team is responsible for a mysterious three thousand dollar charge, and tagging is the only reason anyone can answer that question without launching a full investigation.
Think of tagging like labeling boxes when you move. Nobody enjoys doing it in the moment, but future you, standing in a new apartment surrounded by identical unlabeled boxes, will have strong feelings about whether past you bothered.
Rightsizing means matching the actual size of a resource to what a workload genuinely needs, rather than defaulting to whatever size sounded safely oversized when someone first set it up. It is shockingly common for a virtual machine to sit provisioned at a size handling a fraction of its actual capacity, quietly burning money the entire time.
This is the cloud equivalent of renting a five bedroom house because you once imagined a big family, and then living in it alone for six years. Rightsizing is the practice of periodically checking whether your actual usage still matches what you are paying for, and adjusting when it clearly does not.
Cost management does not usually show up as an exciting exam topic, and it does not usually show up as an exciting meeting either, right up until it does. A poorly tagged, over-provisioned, badly billed cloud environment can rack up costs that dwarf the actual engineering effort that went into the application itself. The organizations that treat cost management as an ongoing discipline, not a one time setup task, are the ones that get to keep saying yes to new projects instead of explaining to finance why last quarter's bill tripled for reasons nobody can quite pin down.
Next month we talk about databases, and the surprisingly consequential decision of whether your data belongs in rows and columns or somewhere a little less rigid.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 1. Cloud Architecture. (Published April, 2025)
Last month we talked about microservices, the idea of breaking an application into small independent pieces instead of one giant tangled monolith. This month we talk about the technology that made running dozens or hundreds of those small pieces actually practical, containers, along with the virtualization concepts that sit underneath them.
A virtual machine emulates an entire computer, complete with its own operating system, running on top of a hypervisor. A container is much lighter weight. It packages up an application and everything it needs to run, but shares the host machine's operating system kernel instead of bringing its own. Think of a virtual machine as building a separate house for every tenant, and a container as an apartment unit inside a building that already has plumbing and electrical installed. Containers start faster and use fewer resources precisely because they are not dragging around a full operating system every time.
Running one container is easy. Running hundreds of them, scaling them up and down, restarting the ones that crash, and making sure they can find each other, is not something you want to do by hand. That is where orchestration comes in, with tools like Kubernetes handling the scheduling, scaling, and health checking automatically.
Think of orchestration as the building superintendent who nobody interacts with directly, but who is constantly making sure units get maintained, new tenants get placed in available space, and nothing sits broken for very long without someone noticing.
Since containers often share the same host machine, port mapping is what lets multiple containers avoid stepping on each other's traffic. A container might listen internally on one port, while the host maps that to a different external port so multiple containers running the same kind of service do not collide. It is the difference between everyone in an apartment building sharing one mailbox versus each unit getting its own numbered slot, even though the mail carrier is still just one person walking down the same hallway.
This is one of the more important distinctions on the exam, and also one of the more common ways people get burned in real production environments. Containers are, by default, ephemeral. When a container gets destroyed and replaced, whatever it wrote to its own local storage disappears with it, like a whiteboard getting erased at the end of a meeting.
Persistent storage solves this by attaching storage that exists independently of any single container's lifecycle. A database container, for example, absolutely should not store its actual data on ephemeral storage, or you will lose everything the moment that container restarts. Knowing which workloads need persistent storage and which ones are fine being purely ephemeral is a real architectural decision, not just a technical detail.
A container image is essentially a snapshot, a packaged set of instructions describing exactly what should run inside a container. An image registry is where those images live, get versioned, and get pulled from whenever a new container needs to spin up. Think of it like a shared recipe book in a restaurant kitchen chain. Every location pulls from the same standardized recipes, so a burger tastes the same whether you order it across town or across the country.
Clustering groups multiple machines together so they behave as one larger, more resilient pool of resources, spreading workloads across them and tolerating individual failures gracefully. Cloning creates an exact copy of an existing container or virtual machine, useful for quickly scaling out identical instances without building each one from scratch.
Host affinity, and its opposite, host anti-affinity, controls whether related workloads should run on the same physical host or deliberately be spread across different ones. Affinity might make sense when two services talk to each other constantly and benefit from low latency. Anti-affinity makes sense when you want redundancy, so that a single host failure does not take down every copy of a critical service at once.
Finally, containers and virtual machines both rely on virtualized versions of networking and storage rather than direct physical hardware access. Virtual networking lets containers and VMs communicate as though they have their own dedicated network interfaces, even while sharing the same physical hardware underneath. Virtual storage works the same way, presenting what looks like a dedicated disk while actually drawing from a shared underlying storage pool.
Containers made the microservices conversation from last month actually workable at scale, but only if you get the fundamentals right. Treat persistent data like it is ephemeral, and you will eventually lose something important. Skip orchestration and try to manage a fleet of containers by hand, and you will spend your nights babysitting things a scheduler should be handling automatically. Get comfortable with these building blocks, and container based architecture stops feeling like a black box and starts feeling like a well organized apartment building instead.
Next month we talk about the number that eventually shows up in every meeting regardless of how well the architecture is designed, the cloud bill itself.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 1. Cloud Architecture. (Published March, 2025)
Last month we talked about where your data physically lives. This month we take a step back and talk about how an application is actually put together, because there is a real difference between an app that was designed for the cloud from day one and an app that got picked up from an old data center and dropped onto a virtual machine somewhere. Both technically run in the cloud. Only one of them is actually taking advantage of it.
A managed service is any piece of infrastructure the cloud provider runs and maintains on your behalf, rather than something you install and babysit yourself. A managed database, for instance, still gives you a database to use, but you are not the one patching it, backing it up, or getting paged at two in the morning when the disk fills up.
This matters for cloud-native design because leaning on managed services frees up your team to focus on the actual application instead of reinventing infrastructure that a thousand other companies already need too. Think of it like ordering food instead of running your own farm. You could grow your own vegetables, but unless that is genuinely your business, your time is usually better spent elsewhere.
Traditional applications are often built as one large, tightly interwoven codebase, sometimes called a monolith, where every part of the system depends heavily on every other part. Change one thing, and you risk breaking three things you did not expect.
Microservices take the opposite approach, breaking an application into small, independent services that each handle one specific job and communicate with each other over the network. A shopping app, for example, might have a separate service for inventory, another for payments, and another for shipping, each one built, deployed, and scaled independently.
Think of the difference between one giant kitchen where every cook has to coordinate around the same three burners, versus a food hall where each vendor runs their own stall. If the taco stand has a bad night, the ramen stand keeps operating just fine.
Loosely coupled architecture is the underlying philosophy that makes microservices actually work well instead of just being a monolith cut into smaller, equally tangled pieces. Loosely coupled services know as little as possible about each other's internal workings. They communicate through defined interfaces, usually APIs, rather than reaching directly into each other's code or database.
The benefit is that you can update, replace, or even completely rewrite one service without the rest of the system falling over, as long as that defined interface stays consistent. It is the difference between a marriage where both partners can function independently and one where neither person can find their car keys without the other one's help.
A fan-out pattern is what happens when a single event triggers multiple independent processes to run in parallel, rather than one long sequential chain of steps. Imagine an order gets placed on an e-commerce site. Instead of one giant process handling inventory, payment, shipping, and email confirmation one after another, a fan-out pattern lets all of those things kick off independently and simultaneously the moment the order event fires.
This matters because it keeps the system responsive. The customer does not have to wait for the shipping label to print before they get their confirmation email. Everything that can happen at the same time, does.
In a system built from dozens of small, independent services, hardcoding the exact address of every other service quickly becomes a nightmare, especially since services in the cloud get created, destroyed, and rescaled constantly. Service discovery solves this by letting services find each other dynamically, checking in with a central directory that always knows the current location of every active service.
Think of it like calling a company's main switchboard instead of memorizing everyone's personal extension. As long as the switchboard stays updated, it does not matter that half the employees moved desks last week.
Cloud-native design is really about accepting that the cloud rewards a different way of building software than the data center did. Managed services, microservices, loose coupling, fan-out patterns, and service discovery all point toward the same goal, building systems that can scale, fail, and recover in small pieces instead of all at once. An application that was simply lifted onto a virtual machine and left alone might technically run in the cloud, but it is not built to survive the cloud's chaos gracefully, and eventually that difference shows up during an outage nobody planned for.
Next month we go one level deeper and talk about containers, the technology that made a lot of this microservices talk actually practical instead of purely theoretical.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 1. Cloud Architecture. (Published February, 2025)
Last month we talked about how traffic gets from one place to another in the cloud. This month we talk about where things actually sit once they get there. Storage sounds like the most boring topic on the exam right up until your monthly cloud bill shows up and you realize you have been paying premium prices to store files nobody has opened since the Obama administration.
Cloud providers do not treat all your data the same way, and honestly, neither should you. Tiered storage is built around a simple idea. Data you access constantly should live somewhere fast and expensive. Data you almost never touch should live somewhere cheap, even if that means it takes a little longer to retrieve.
Hot storage is for data you are actively using right now. Think of it like keeping your everyday dishes in the kitchen cabinet closest to the stove. Fast to grab, and you pay for that convenience.
Warm storage is for data you need occasionally but not constantly. This is more like the dishes you only pull out for holidays, still reasonably accessible, just not sitting front and center.
Cold storage is for data you rarely touch but still need to keep around, maybe for compliance reasons or historical records. This is the stuff in the garage. It exists, you can get to it, but it takes some effort.
Archive storage is the deep freeze. This is for data you are required to retain but almost certainly will never look at again unless something goes very wrong. Retrieval can take hours instead of milliseconds, but the storage cost is a fraction of hot storage. Think of it as a storage unit three towns over that you pay ten dollars a month for, just in case.
The exam wants you comfortable moving between these categories and understanding that the right answer usually is not "just keep everything in hot storage forever," even though that would technically work. It would also technically bankrupt you slowly.
Underneath all that tiering sits actual physical hardware, and the exam wants you to understand the tradeoff between solid state drives and traditional spinning hard disk drives. SSDs have no moving parts, which means faster read and write speeds and better reliability under heavy, random access patterns. HDDs are mechanical, with an actual spinning platter and a read head moving across it, which makes them slower but considerably cheaper per gigabyte.
This is why a lot of hot storage tiers run on SSDs, while colder tiers lean on cheaper HDD based systems. You are not just choosing a temperature category. Underneath it, you are also choosing a physical technology that matches the speed you actually need.
The exam also wants you to know the three major storage types, and the differences matter more than they might seem at first glance.
Block storage splits data into fixed size chunks, called blocks, and each block can be accessed independently. This is the storage type behind most virtual machine disks, since operating systems expect the kind of low level, high performance access that block storage provides. Think of it as a wall of identical numbered lockers. Fast, direct access to any locker, but you need something managing which locker holds what.
File storage organizes data in a familiar folder and file hierarchy, the same way you probably think about files on your own computer. It is simple to understand and works well for shared access across multiple systems, like a shared drive at the office.
Object storage ditches the folder hierarchy entirely and instead stores each piece of data as a self-contained object with metadata attached to it, accessed through a unique identifier rather than a file path. This is what services like Amazon S3 are built on, and it scales enormously well for things like backups, media files, and static website content. Think of it less like a filing cabinet and more like a warehouse where every box has its own barcode and you never actually need to know which shelf it is sitting on.
Choosing the right storage type and tier is not a one time decision you make and forget. It is an ongoing balancing act between performance, cost, and how often data actually gets accessed. Companies that never revisit this end up either paying hot storage prices for cold data, or worse, discovering during an audit that critical data got quietly moved somewhere too slow to be useful in an emergency. Get the tiering and storage type right, and it becomes invisible. Get it wrong, and it becomes either a surprise on the invoice or a surprise during a crisis.
Next month we move up a level and talk about cloud-native design, meaning the difference between an application that was built for the cloud and one that was just dragged there kicking and screaming.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 1. Cloud Architecture. (Published January, 2025)
Happy New Year, and welcome to the topic that trips up more experienced IT folks than almost anything else on this exam. Not because networking is new to you. If you have any background in IT at all, you already know what a firewall does and roughly what a VPN is for. The tricky part is that cloud networking borrows a lot of familiar vocabulary and then quietly changes the furniture around. Your on-prem instincts will get you most of the way there, and occasionally lead you somewhere slightly wrong.
A VPN in the cloud world does the same basic job it always has. It creates an encrypted tunnel between two points so traffic can travel over the public internet without anyone in between reading it. Site-to-site VPNs connect two networks, like your office and your cloud environment, while point-to-site connects a single device into that same environment.
Dedicated connections skip the public internet entirely. Instead of tunneling encrypted traffic over the same internet everyone else uses, you get a private, physical connection straight into the cloud provider's network. Think of the difference between mailing a letter through the regular postal system versus hiring a courier who drives your package directly there in a locked van. Both arrive, but one avoids the shared infrastructure altogether, usually at a higher cost and with more consistent performance.
Load balancers spread incoming traffic across multiple servers so no single machine gets overwhelmed while its neighbors sit idle. It is the cloud equivalent of a restaurant host directing customers to open tables instead of letting one poor server get slammed while three other tables sit empty.
Gateways act as the entry and exit points for traffic moving between networks, whether that is an internet gateway letting your VPC talk to the outside world, or an API gateway managing requests headed toward your application's backend.
CDNs, or content delivery networks, cache copies of your content on servers physically closer to your users. Instead of every request traveling all the way back to your origin server, a nearby cached copy answers most of the traffic instead. This is why a video loads instantly whether you are streaming it from across town or across an ocean.
Firewalls in the cloud work conceptually the same way they always have, deciding what traffic gets allowed in or out. What changes is that cloud firewalls are often defined as software rules attached to a virtual network rather than a physical box sitting in a rack somewhere.
VPC peering connects two separate virtual private clouds so they can communicate as if they were on the same network, without routing traffic over the public internet. Transit gateways take this further, acting as a central hub that lets many VPCs connect to each other without needing a direct peering connection between every single pair. Without a transit gateway, connecting ten VPCs to each other directly would require forty five separate peering connections. With one, you just connect everything to the hub instead.
Subnetting divides a larger network into smaller, more manageable chunks, which helps with both organization and security. VLANs do something similar at a logical level, letting devices that are not even on the same physical network behave as though they are part of the same local network segment, or letting devices on the same physical hardware behave as though they are completely separate.
SDN, or software defined networking, separates the decision making part of networking from the actual hardware moving the packets. Traditional networking hardware makes routing decisions locally, baked into the device itself. SDN centralizes that decision making into software, which can reconfigure the entire network's behavior without anyone physically touching a switch. This is a big part of what makes cloud networks so flexible. Spinning up a new virtual network takes seconds, not a truck roll to a data center.
Finally, routing determines the actual path traffic takes to get from one place to another. Static routes are manually defined and never change unless someone edits them. BGP, Border Gateway Protocol, dynamically shares routing information between networks so that the internet as a whole can figure out the best path automatically, even as conditions change. Route tables are simply the rulebooks that decide, for a given piece of traffic, which direction it should head next.
Cloud networking fundamentals are the plumbing nobody thinks about until it backs up. Get the segmentation, routing, and traffic management right, and applications feel fast and reliable without anyone downstream ever noticing the work that went into it. Get it wrong, and you get the kind of mysterious latency issues that eat an entire afternoon before someone finally traces it back to a misconfigured route table.
Next month we move from how traffic gets around to where your data actually lives, covering storage tiers and the tradeoffs between speed and cost.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 1. Cloud Architecture. (Published December, 2024)
Last month we talked about service models and where the line of responsibility sits between you and your cloud provider. This month we look at what happens when something on that provider's side actually fails, because eventually, something always does. A data center loses power. A network link gets cut by a backhoe that had no idea what it was digging into. A whole region goes sideways for reasons nobody fully explains in the post mortem. Service availability and disaster recovery is the subdomain that asks whether your application shrugs this off or falls over completely.
Cloud providers organize their infrastructure into regions, which are large geographic areas, and availability zones, which are physically separate data centers within a region. Think of a region as a city, and availability zones as separate buildings scattered around that city, each with its own power, cooling, and networking. If a single building loses power, the others down the street keep humming along just fine.
Designing across multiple availability zones means a failure in one zone does not take your whole application down with it. Designing across multiple regions goes a step further, protecting you even if an entire city sized chunk of infrastructure has a bad day. Whether you actually need multi-region redundancy depends on how much downtime your business can tolerate and how much you are willing to pay for the insurance policy of running duplicate infrastructure somewhere else.
Cloud bursting is what happens when your normal environment, whether that is on-prem or a private cloud, hits its capacity ceiling and temporarily spills extra workload out into a public cloud to handle the overflow. Picture a small local bakery that normally handles its own foot traffic just fine, but on the one day a year a food blogger mentions them, they call in extra staff from a temp agency to handle the rush. Once the surge passes, everything scales back down to normal.
Edge computing takes the opposite approach to distance. Instead of centralizing everything in a handful of massive data centers, processing happens physically closer to where the data is generated, cutting down on latency for things like IoT sensors, video streaming, or anything else where a round trip to a distant data center is simply too slow to be useful.
If you remember one pair of acronyms from this entire subdomain, make it these two.
RTO, Recovery Time Objective, is how long you can tolerate being down before it becomes a real business problem. RPO, Recovery Point Objective, is how much data you can afford to lose, measured in time, if something fails right now. An RPO of one hour means you are fine losing up to an hour's worth of data, but not more.
These numbers are not something a cloud engineer gets to decide alone in a vacuum. They come from a conversation with the business about actual tolerance for downtime and data loss, and then the technical team designs backups, replication, and failover systems to actually hit those targets. Promising a fifteen minute RTO and then never testing your failover process is the cloud equivalent of buying a fire extinguisher and leaving the pin in.
When it comes to disaster recovery sites, the exam wants you comfortable with three flavors, and the temperature naming is actually pretty intuitive once you sit with it.
A hot site is a fully running duplicate environment, ready to take over almost instantly. It is expensive to maintain because you are essentially paying for two of everything all the time, but the tradeoff is minimal downtime if disaster strikes.
A warm site sits somewhere in the middle. Some infrastructure is already in place and some data may already be synced, but it needs a bit of spinning up before it is fully operational. Recovery is faster than starting from scratch, but slower than a hot site.
A cold site is closer to an empty shell. The basic infrastructure might exist, but little to nothing is actively running or synced. It is the cheapest option by far, and also the slowest to actually bring online when you need it.
This subdomain also touches on multicloud tenancy, which builds on the multicloud concept we covered back in our very first post. Running workloads across multiple cloud providers is not just about avoiding vendor lock-in. It is also a resilience strategy. If one provider has a bad day, or even a bad month, your entire business is not hostage to a single company's uptime record.
Nobody plans for downtime because they enjoy it. They plan for it because outages are not a hypothetical, they are a when, not an if. The organizations that handle outages gracefully are the ones that already knew their RTO and RPO numbers ahead of time, already tested their failover process instead of just assuming it would work, and already decided in advance whether they needed a hot site standing by or could live with something colder and cheaper. Skipping this planning does not prevent the outage. It just guarantees you find out how bad it is at the worst possible moment.
Next month we head into the digital plumbing itself and talk about cloud networking fundamentals, including why your on-prem networking knowledge both helps you and occasionally leads you astray.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-004), Domain 1. Cloud Architecture. (Published November, 2024)
Welcome to the CV0-004 era of this series. Last month we walked through everything that changed between the old exam and the new one. This month we get back to actual content, and it feels fitting to start with service models, since that is the topic that got the most obvious upgrade in the new version. If you read our April post on IaaS, PaaS, and SaaS under the old exam, most of this will feel familiar. The difference is that serverless finally gets promoted from a footnote to a full member of the club.
Think of cloud service models like different levels of help you can hire when moving into a new house.
IaaS, Infrastructure as a Service, is like renting an empty house. You get the walls, the plumbing, and the electricity. The provider hands you virtual machines, storage, and networking. You bring your own furniture, meaning the operating system, the applications, and the configuration. Think EC2 instances or Azure VMs.
PaaS, Platform as a Service, is like renting a furnished house. The provider handles the OS, the runtime, and the underlying infrastructure. You just move in your stuff, meaning your code, and get to work. Think Heroku or Azure App Service.
SaaS, Software as a Service, is like staying at a hotel. Everything is handled for you. You just use the service. Gmail, Salesforce, and Microsoft 365 fall into this category. You log in, you work, and someone else worries about the rest.
Here is where CV0-004 makes its move. FaaS, Function as a Service, now stands on its own instead of being lumped in with other advanced services. If PaaS is a furnished house, FaaS is more like ordering exactly one specific chore done, and only paying for the moment someone actually shows up to do it. You upload a small piece of code, a function, and it runs only when triggered by some event. A file gets uploaded, an API gets called, a message lands in a queue, and your function wakes up, does its job, and goes back to sleep.
You never provision a server. You never patch an operating system. There absolutely is a server involved somewhere, sitting in a data center, but it is entirely the provider's problem to manage. You are billed in tiny slices, often measured in milliseconds of execution time, rather than paying for a machine sitting idle around the clock. AWS Lambda, Azure Functions, and Google Cloud Functions are the household names here.
Why does this deserve its own category instead of just being an extension of PaaS? Because the operating model is genuinely different. PaaS still expects something resembling a running application, even if the provider manages the platform underneath it. FaaS expects nothing running at all until the exact moment it is needed. That distinction matters enough that CompTIA decided it was worth testing separately.
The shared responsibility model has not changed conceptually. It is still the same dividing line between what the provider secures and what you secure, and that line still moves depending on which service model you are using. Adding FaaS just adds one more position along that spectrum.
With IaaS, you are responsible for almost everything above the hypervisor. With PaaS, the provider takes over the OS and runtime, leaving you responsible mainly for your application code and data. With SaaS, the provider handles nearly everything except your data and who has access to it.
FaaS pushes the line even further toward the provider than PaaS does. You are not responsible for an operating system, because there effectively is not one from your perspective. You are not managing a runtime environment in any traditional sense either. What you are responsible for narrows down to your function's code itself, how it handles the data it touches, and making sure it does not have permissions broader than it actually needs. That last part trips people up constantly. A serverless function with overly generous permissions is still a security hole, even if there is no server for you to log into and misconfigure.
Whether you are counting three service models or four, the underlying lesson has not moved an inch. Moving up the stack, from IaaS toward FaaS, means the provider takes on more operational burden, and in exchange, you give up a certain amount of control. Neither end of that tradeoff is automatically the right answer. It depends on what you are building, how much you want to manage yourself, and how quickly things need to scale up or down. FaaS earning its own name in the exam is really just CompTIA acknowledging that this tradeoff has become common enough, and different enough from PaaS, to deserve its own conversation.
Next month we stay in Domain 1 and talk about what happens when a region goes down, and why the phrase "it's fine, we have a backup" is doing a lot of heavy lifting if nobody ever actually tested that backup.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-003 to CV0-004), Domain 1. Cloud Architecture. (Published October, 2024)
Here is a plot twist nobody asked for. Right around the time we were finishing up our tour of CV0-003, CompTIA quietly retired it out from under us. CV0-004 officially launched on September 24, 2024, and CV0-003 is being phased out, with an expected retirement window around March or April of 2025. If you have been following along and studying for the exam alongside this series, this is the month where we stop and figure out what actually changed before charging ahead.
The good news is that none of the last seven months were wasted. Cloud fundamentals do not get reinvented every time CompTIA updates an exam number. The bad news, if you want to call it that, is that Domain 1 got a serious remodel, and it is worth understanding exactly what moved before we start treating CV0-004 as the only exam that matters going forward.
CV0-003 called its first domain Cloud Architecture and Design, and it made up 13 percent of the exam. CV0-004 shortened the name to just Cloud Architecture, and nearly doubled its importance, now sitting at 23 percent. That is the single biggest jump of any domain across both versions of the exam. CompTIA is essentially saying that architecture knowledge matters more now than it did two years ago, which tracks with how much more complicated cloud environments have gotten in that time.
Back in April, when we covered service models, we mentioned that CV0-003 treated serverless computing as an advanced service tacked onto the core three models of IaaS, PaaS, and SaaS. CV0-004 promotes it to a full fourth service model, Function as a Service, or FaaS, standing right alongside the other three. If you already understood serverless computing conceptually, nothing about how it works has changed. What changed is that the exam now expects you to name it as its own distinct category rather than treating it as a footnote.
This is really where the bulk of the change lives. CV0-003 kept Domain 1 fairly lean, focused mostly on cloud models, service models, capacity planning, high availability, and solution design analysis. CV0-004 folded in several topics that used to live elsewhere or did not exist as named subdomains at all.
Networking fundamentals now live here, covering VPNs, load balancers, CDNs, VPC peering, subnetting, and routing concepts like BGP. Storage gets its own subdomain too, covering tiered storage and the tradeoffs between object, block, and file storage. Cost management shows up as a named topic, covering billing models like reserved instances and spot pricing. Databases get a subdomain of their own, distinguishing relational from non-relational and self-managed from provider-managed. Workload optimization covers matching compute types to the job at hand. And emerging tech rounds it out, covering AI and ML use cases along with IoT concepts.
None of this content is brand new to the world of cloud computing. Most of it existed somewhere in the old exam, scattered across other domains, or simply was not tested at all. CV0-004 gathered it up and decided it all belongs under the architecture umbrella, which honestly makes a reasonable amount of sense. Deciding what storage tier to use or how much a workload will cost you is an architecture decision just as much as picking public versus private cloud.
If you started studying with CV0-003 materials and are wondering whether to switch horses mid-stream, the practical answer is that CV0-004 is now the only version you can actually schedule and sit for, so there is not really a choice to make anymore. The concepts you already learned are not wasted. Cloud models, service models, and shared responsibility have not changed in any meaningful way. You are just going to see them tested alongside a wider set of architecture topics than before.
Starting next month, this series moves to CV0-004 exclusively, and we will follow its domain structure in order: Cloud Architecture, Deployment, Operations, Security, DevOps Fundamentals, and Troubleshooting. Some subdomains will feel like familiar ground covered again with more detail. Others, like networking fundamentals and databases, are genuinely new territory for this series. Either way, consider this the bridge between where we have been and where we are headed.
Next month we pick back up with service models, this time with FaaS getting the spotlight it did not have before.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-003), Domain 2. Security. (Published September, 2024)
Last month we talked about who gets to walk through the front door and how you prove they are actually who they say they are. This month we stay in Domain 2 and move past the front door entirely. Once someone, or something, is inside your cloud environment, the network itself needs its own set of locks, cameras, and nosy neighbors watching the hallway. That is network security, and it is a big enough topic that CompTIA gives it its own chunk of Domain 2.
The first idea here is segmentation, which is really just a fancy word for not letting every system talk to every other system just because they happen to live in the same cloud account. VLANs, VXLANs, and GENEVE are all different flavors of the same basic concept. They carve a shared network into logical sections so that your public facing web server and your internal database do not end up as next door neighbors sharing a wall with no insulation.
Micro-segmentation takes this a step further, getting granular enough that individual workloads get their own tightly controlled rules instead of relying on one big perimeter. Think of it as the difference between locking the front door of an apartment building versus giving every single unit its own separate lock, deadbolt, and doorbell camera. If one apartment gets broken into, the burglar still cannot just wander into every other unit on the floor.
Tiering works alongside this, separating environments into layers, like a web tier, an application tier, and a database tier, each with its own rules about who is allowed to talk to whom.
The exam wants you familiar with a long list of protocols, and honestly the easiest way to think about most of them is that they come in pairs. There is the older, less secure version, and the newer version that fixed the obvious problem everyone eventually noticed.
DNS is the classic example. Plain DNS happily hands out answers to anyone who asks, with no real way to verify those answers were not tampered with along the way. DNSSEC adds a layer of cryptographic proof that the answer you got back is legitimate. DoH and DoT go a step further and encrypt the DNS query itself, so nobody snooping on the network can see what site you were even asking about.
NTP keeps clocks synchronized across a network, which sounds boring until you realize that certificates, logs, and authentication tokens all depend on accurate timestamps to function correctly. NTS is the more secure, authenticated version of the same idea.
Then there are the tunneling and transport protocols. IPSec, TLS, and HTTPS all focus on encrypting traffic as it travels. SSH, L2TP, PPTP, and GRE are more about creating secure or at least structured tunnels between two points. PPTP in particular is the protocol equivalent of that one relative who still insists on paying by check. It works, technically, but nobody serious relies on it anymore because of well known weaknesses.
Firewalls, both stateful and stateless, decide what traffic gets in and what gets turned away at the door. Stateless firewalls check each packet in isolation, like a bouncer with no memory of who just walked in five minutes ago. Stateful firewalls actually remember the conversation, which lets them make smarter decisions.
A web application firewall, or WAF, specifically watches traffic aimed at web applications, looking for the kind of malicious input that regular firewalls are not built to catch. IPS and IDS, intrusion prevention and intrusion detection systems, watch for suspicious patterns of behavior. The difference between the two is basically the difference between a security camera that just records footage and one wired up to actually slam a door shut when it sees trouble.
DLP, data loss prevention, keeps an eye out for sensitive data trying to leave the network somewhere it should not. NAC, network access control, checks devices before letting them join the network at all, kind of like a bouncer checking ID before anyone even gets past the velvet rope. Packet brokers sit quietly in the background, distributing copies of network traffic to whatever monitoring tools actually need to inspect it.
Hardening is the practice of shrinking your attack surface by getting rid of anything unnecessary. Disable ports and services nobody is actually using. Retire weak protocols and outdated ciphers before an attacker finds them first. Keep firmware up to date, because a lot of real world breaches trace back to some forgotten device running software from several years ago that nobody ever patched. DDoS protection rounds this out, defending against attacks designed to simply overwhelm a system with traffic until it falls over.
None of this works in isolation. Segmentation without monitoring is just walls with no cameras. Monitoring without hardening means you will see the break in happening in real time and still not know how they got past the unlocked side door. Real world network security is about layering these pieces together so that no single failure takes down the whole environment.
Next month wraps up a busy year of CV0-003 coverage before we shift gears entirely and look at what actually changed when CompTIA rolled out the newer version of this exam.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-003), Domain 2. Security. (Published August, 2024)
Domain 1 is finally behind us. We spent five months talking about what kind of cloud you are using, what someone else is responsible for versus what you are responsible for, and how to plan before you build. Now we move into Domain 2, Security, which makes up a full 20 percent of the exam. That is the single largest chunk of any domain, and it starts with a topic that sounds simple until you actually try to do it well: identity and access management, or IAM.
At its core, IAM answers one question. Who is allowed to do what, and how do you prove it is actually them? Get this wrong and it does not matter how well you configured your network or how many firewalls you stacked up. Someone will just log in the front door with a stolen password and walk right past all of it.
Not every account needs the same level of trust. A regular employee logging into email is logical access. Someone with the ability to spin up production servers or touch billing settings is privileged access, and that distinction matters a lot. Privileged accounts are the ones attackers actually want, since compromising one is worth more than compromising a hundred regular ones combined. This is also why the exam cares so much about account lifecycle management, meaning provisioning access when someone joins and, just as importantly, deprovisioning it the moment they leave or change roles. A surprising number of breaches trace back to an old account nobody ever bothered to shut off.
CompTIA wants you to know the difference between several access control philosophies, and honestly they are easier to remember with an analogy than a definition.
Role-based access control (RBAC). Access is tied to a job title, not a person. If you are on the finance team, you get finance permissions. Change roles, and your access changes with you.
Discretionary access control (DAC). The owner of a resource decides who else gets in, like you deciding who gets a spare key to your apartment.
Non-discretionary access control. Access is assigned by policy or a central authority rather than left up to individual owners.
Mandatory access control (MAC). The strictest of the bunch. A central system enforces access based on classification levels, and even the resource owner cannot override it. Think government and military systems, where a document marked top secret stays that way no matter who asks nicely.
This is where directory services, federation, and authentication protocols come in. LDAP is one of the oldest ways of organizing who exists in an environment and what they belong to, and plenty of modern identity systems still lean on it under the hood. Federation lets one identity work across multiple systems without creating a separate login for each one, which is the whole point of SSO, or single sign on. SAML is one of the common languages that makes federation and SSO actually talk to each other behind the scenes.
Then there is multifactor authentication, or MFA, which by now most people have run into whether they work in IT or not. Something you know, like a password, paired with something you have, like a phone generating a code, or something you are, like a fingerprint. The idea is simple. A stolen password alone should not be enough to get in the door.
Public key infrastructure, or PKI, is the system behind digital certificates, and digital certificates are how systems prove their identity to each other, not just to humans. Your browser trusting a website's HTTPS certificate is PKI quietly doing its job in the background. Certificate management covers issuing, renewing, and revoking those certificates, and letting one expire unnoticed has taken down more production systems than most engineers like to admit.
Secret and key management rounds this out. API keys, database passwords, and encryption keys all need somewhere safe to live, and that somewhere is not a text file sitting in a code repository. Secrets managers and vaults exist specifically so that sensitive credentials are not scattered across scripts, configuration files, and sticky notes on a monitor.
IAM is the digital version of deciding who gets which key to which door in a building, and then actually remembering to collect the key when someone moves out. Get the access control model right, keep account lifecycles tight, layer in MFA, and treat certificates and secrets like the sensitive material they are, and you have covered most of what actually stops real world breaches. Miss any one of these pieces, and everything else you built in Domain 1 is sitting behind a door that was never really locked.
Next month we stay in Domain 2 and move from who gets in the building to what happens to the network itself once they are inside.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-003), Domain 1. Cloud Architecture. (Published July, 2024)
By now in this series we have covered the different flavors of cloud, the different ways you can rent someone else's computer, and how to plan for enough capacity that your app does not fall over during a product launch. This month wraps up Domain 1 with the part of the exam that sounds the most like homework: solution design analysis.
Here is the good news. This subdomain is not really new information. It is more like a checklist that ties everything else in Domain 1 together. Before you deploy anything in the cloud, someone has to sit down and actually think it through. That thinking process is what solution design analysis covers, and CompTIA breaks it into two big buckets: requirement analysis and environments and testing.
Every cloud project starts with someone excited to build something. Requirement analysis is the part where a more cautious voice in the room asks a bunch of unglamorous questions before anyone touches a keyboard. Skip this step and you end up finding out the hard way, usually during a Friday afternoon outage.
The exam wants you to know these requirement categories:
Software requirements. What applications, licenses, and dependencies actually need to run here.
Hardware requirements. How much compute, memory, and storage this thing realistically needs, not just what sounds impressive in a meeting.
Integration requirements. How the new system needs to talk to everything else already in place.
Budgetary requirements. The number that eventually makes everyone in the meeting go quiet.
Compliance requirements. Whatever regulations apply to your industry, because the cloud does not make HIPAA or PCI DSS disappear, it just moves where the paperwork lives.
SLA requirements. How much downtime is actually acceptable, in writing, not just in someone's head.
Security requirements. Baked in from the start, not bolted on after something goes wrong.
Network sizing, subnetting, and routing requirements. Making sure the digital plumbing can actually handle the traffic you are about to send through it.
None of this is thrilling. It is the cloud equivalent of a home inspection before you buy the house. Nobody enjoys the inspection, but everyone is glad they had one when the foundation turns out to be fine, or when it does not.
The second half of this subdomain covers environments, meaning the different stages a piece of software passes through before real customers ever see it. CompTIA wants you familiar with these:
Development. Where code is actively being written and things are allowed to be a little messy.
QA. Where testers try to break what development just built, ideally before your customers do it for free.
Staging. A near mirror of production, used as a final rehearsal.
Blue-green. Two identical production environments where traffic can be flipped from one to the other, which we will dig into more when we cover deployment strategies later in this series.
Production. The real deal, where actual users and actual money are on the line.
Disaster recovery. The environment that sits quietly in the background, hoping it never has to be useful.
Think of it like a school play. Development is rehearsing lines alone in your room. QA is the awkward table read where everyone points out your mistakes. Staging is dress rehearsal, costumes and all. Production is opening night in front of a paying audience. And disaster recovery is the understudy, memorized and ready, praying they never actually have to go on stage.
Rounding out the subdomain is testing, and the exam expects you to recognize several distinct types rather than treating testing as one generic activity.
Vulnerability testing looks for known weaknesses that an attacker could exploit.
Penetration testing goes a step further and actually tries to exploit them, with permission, before someone without permission tries first.
Performance testing checks whether the system holds up under real load instead of just looking fine in a demo.
Regression testing confirms that fixing one thing did not quietly break three other things.
Functional testing verifies the system actually does what it is supposed to do.
Usability testing checks whether real humans can actually use the thing without getting frustrated and giving up.
Each type answers a different question, and a mature deployment process runs several of them before anything reaches production, not just whichever one someone remembered to schedule.
Solution design analysis is really the exam's way of saying that architecture is not just about picking public versus private cloud or sizing out your compute. It is about the discipline of planning before building, and confirming before trusting. Every other domain on this exam, security, deployment, operations, troubleshooting, assumes that this kind of upfront thinking already happened. Skip it, and you are debugging problems in production that a decent requirements conversation would have caught months earlier.
With that, Domain 1 is officially in the books. Next month we move into Domain 2, Security, starting with identity and access management, or as most of us just call it, figuring out who gets a key to which door.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-003), Domain 1. Cloud Architecture. (Published June, 2024)
High availability, often shortened to HA, is the practice of designing systems so that no single failure takes everything down. The exam focuses on this specifically for network functions: switches, routers, load balancers, and firewalls. These are the unglamorous pieces of infrastructure that everything else depends on, kind of like the electrical panel in your house. Nobody brags about their electrical panel at a dinner party, but try living without one for a day.
The general strategy is redundancy. If you have one router and it dies, your network dies with it. If you have two routers configured so one can take over instantly if the other fails, you have HA. The same logic applies to switches, load balancers, and firewalls. Pairs, clusters, and failover configurations exist so that a hardware failure becomes a non event instead of a resume generating event.
Load balancers deserve a special mention here because they often serve double duty. Not only do they distribute traffic across multiple servers, but the load balancer itself needs to be highly available too. If your load balancer goes down, it does not matter how many redundant servers are sitting behind it. Nobody can reach any of them.
This is really the philosophy underneath everything else in this domain. A single point of failure, often abbreviated SPOF, is any one component that, if it fails, takes down the whole system. It could be a switch, a power supply, a database, or even a person who is the only one who knows how the backup script works.
Good architecture hunts down single points of failure and eliminates them, one at a time. This is why cloud environments lean so heavily on things like multiple availability zones, redundant power feeds, and duplicate network paths. It is not paranoia. It is just accepting that hardware fails, connections drop, and data centers occasionally have bad days, and building around that reality instead of hoping it never happens.
Here is a quick way to think about SPOF hunting during exam prep or on the job. Ask yourself, if this one thing broke right now, would anything stop working? If the answer is yes, you have found a SPOF, and now you get to go fix it.
Once you have made sure nothing falls over when something breaks, the next question is what happens when things get busy. That is where scalability comes in, and Cloud+ breaks this into a few flavors.
Auto scaling is the cloud automatically adding or removing resources based on demand, without a human manually spinning up servers at two in the morning. If traffic spikes, more capacity appears. If traffic drops, that capacity quietly goes away, and so does the bill for it.
Horizontal scaling means adding more machines to share the load. Think of it like opening more checkout lanes at a grocery store. Same amount of work per lane, just more lanes running at once.
Vertical scaling means making an existing machine bigger and beefier instead of adding more of them. This is more like replacing one slow cashier with someone who scans groceries at superhuman speed. Same number of lanes, just a lot more horsepower behind the one you have.
Cloud bursting is a specific hybrid strategy where a private cloud or on prem environment normally handles the workload, but overflow traffic gets sent out to a public cloud provider during unusually high demand. It is the IT equivalent of a restaurant that normally seats everyone inside, but sets up a few extra tables on the sidewalk during a busy Friday night rush.
It is tempting to file this section away as exam trivia, but this stuff shows up constantly in the real world. Every outage postmortem you have ever read from a major tech company eventually traces back to one of two things. Either something failed that should have had a backup, or something got overwhelmed that should have been able to scale. High availability and scalability are basically insurance policies against both of those failure modes.
For anyone studying Cloud+, the key is understanding that these concepts are not separate from each other. HA keeps things running when something breaks. Scalability keeps things running when everything is working perfectly, just under more pressure than usual. Together, they are what separates an infrastructure that survives its busiest day from one that becomes a very awkward incident report.
Next up in this series, we will keep working through Domain 1 with solution design analysis, where all of this planning finally turns into an actual blueprint.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-003), Domain 1. Cloud Architecture and Design. (Published May 2024)
Picture this. You throw a dinner party. You know roughly how many people are coming, so you buy roughly enough food. Except you didn't account for your cousin who eats like he's storing up for hibernation, or the fact that three people canceled last minute and now you've got a fridge full of lasagna nobody wants. That, in a nutshell, is capacity planning. It's the art of guessing how much stuff you're going to need before you actually need it, and trying not to be wildly wrong in either direction.
In the cloud world, getting this wrong doesn't just mean leftover lasagna. It means either paying for a small country's worth of unused servers, or watching your app crawl to a halt the one day it actually goes viral. Cloud+ spends a good chunk of Domain 1 on this because capacity planning touches almost everything else you'll do as a cloud professional.
Before you provision anything, you have to ask some very unglamorous questions. What hardware do we need. What software licenses does that hardware require. What's the budget. And, maybe most importantly, what does the business actually need this thing to do. This is called business need analysis, and it exists because a shocking number of IT projects have historically been built based on vibes rather than actual requirements.
This is also where standard templates come in. Instead of reinventing the wheel every time someone spins up a new server, organizations build out templates for common configurations. Need a web server. There's a template for that. Need a database server with specific memory and storage settings. Also a template. Templates save time and prevent the classic scenario where five different admins configure five nearly identical servers five slightly different ways, and then nobody can figure out why one of them is misbehaving.
Licensing sounds boring, and that's exactly why it trips people up. There are several flavors you'll run into.
Per-user licensing: You pay based on how many humans are using the software, not how many machines it's installed on.
Socket-based licensing: You pay per physical CPU socket, which matters a lot if you're running big multi-socket servers.
Volume licensing: Buying in bulk, usually at a discount, the software equivalent of a Costco membership.
Core-based licensing: Priced per CPU core, which gets complicated fast once virtualization enters the picture.
Subscription licensing: You pay on an ongoing basis, usually monthly or annually, instead of one big upfront cost.
Get the licensing model wrong and you either overpay dramatically or end up out of compliance, which is a nice way of saying "the software vendor is about to send you a very unpleasant email."
User density is just a fancy way of asking how many people are going to be hammering on this system at once. System load is how much work that system is actually doing at any given moment. Together, they help you figure out whether you're building for a quiet internal tool used by twelve accountants, or a public facing app that might get slammed by twelve thousand people the moment it gets mentioned on social media.
This is where trend analysis earns its keep. By establishing a baseline, meaning what's normal, you can spot patterns, like traffic always spiking on Monday mornings, and catch anomalies, like traffic spiking at 3am for no discernible reason other than something is very wrong. Baselines are the reason monitoring tools can tell you "hey, this is weird" instead of just shrugging.
Hypervisor affinity and anti-affinity rules decide which virtual machines are allowed to hang out together on the same physical host, and which ones absolutely should not. Affinity keeps certain VMs together, maybe for performance reasons. Anti-affinity keeps them apart, usually for redundancy, so that if one physical host goes down, you don't lose both halves of a critical system at the same time. It's basically deciding which roommates can share an apartment without it ending in a small war.
Oversubscription is when a provider allocates more resources on paper than physically exist, betting that not everyone will use their full allocation at the same time. This happens with compute, network, and storage. It's the exact same logic airlines use when they overbook flights, assuming a few people won't show up. Most of the time it works out fine. Occasionally, everyone shows up at once, and things get uncomfortable fast.
Finally, capacity planning has to account for geography. Regions are large, distinct geographic areas a cloud provider operates in. Availability zones are isolated locations within those regions, each with its own power and networking, so a failure in one zone doesn't necessarily take down the others. Planning around regions and zones is how you build systems that survive a single data center having a very bad day.
None of this is exciting in the way that, say, AI chatbots are exciting. But capacity planning is the difference between a cloud environment that quietly does its job and one that either bleeds money or falls over under pressure. Get it right, and nobody notices. Get it wrong, and everybody notices, usually at the worst possible time.
Next up in this series: high availability and scaling, where we talk about what happens after your capacity plan meets reality.
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-003), Domain 1. Cloud Architecture and Design.
If you're studying for Cloud+, or just trying to make sense of "the cloud" as a working IT pro, this is the concept everything else builds on. Before you can talk about networking, storage, or security in the cloud, you need to understand who's renting what. And just as importantly, who's responsible for locking the doors.
Think of cloud service models like different levels of help you can hire when moving into a new house.
IaaS (Infrastructure as a Service) is like renting an empty house. You get the walls, the plumbing, and the electricity. The provider (AWS, Azure, GCP) hands you virtual machines, storage, and networking. You bring your own furniture. That means the operating system, the applications, and the configuration. You're doing the setup work, but you skip building the house from scratch. Think EC2 instances or Azure VMs.
PaaS (Platform as a Service) is like renting a furnished house. The provider handles the OS, the runtime, and the underlying infrastructure. You just move in your stuff, meaning your code, and get to work. You're not patching servers or managing an operating system. You're focused purely on building and deploying your application. Think Heroku, or Azure App Service.
SaaS (Software as a Service) is like staying at a hotel. Everything is handled for you. You just use the service. Gmail, Salesforce, and Microsoft 365 are good examples. You log in, you work, and someone else worries about servers, updates, and infrastructure entirely.
CV0-003 also groups these three core models in with what it calls advanced services. Things like serverless computing, IoT, and AI/ML fall under this umbrella. Serverless, for example, lets you upload a small piece of code that only runs, and only costs you money, when triggered by an event. There's no server for you to think about, even though there's still a server somewhere. It just isn't your problem anymore. The exam treats these as an extension of the service model conversation rather than a fourth category of their own, which is worth knowing if you're comparing notes with someone studying the newer version of this exam.
Here's where a lot of people get tripped up, and where Cloud+ Domain 1 (and real world cloud security) really lives. Just because you moved to the cloud doesn't mean security became someone else's problem.
The shared responsibility model is exactly what it sounds like. It's a dividing line between what the cloud provider secures and what you, the customer, secure. That line moves depending on which service model you're using.
Here's a simple way to think about it. The more the provider manages, the more they're responsible for. But you never get to zero responsibility.
With IaaS, the provider is responsible for the physical hardware, the hypervisor, and the data centers themselves. That includes power, cooling, physical security, and network infrastructure. You're responsible for almost everything running on top of that. That means the OS, patching, firewall configuration, application security, and your data. If you spin up a VM and never patch it, that's on you, not AWS.
With PaaS, the provider takes on more. They manage the OS and runtime, so patching that layer is their job. You're now responsible mainly for your application code, your data, and how you configure access to it.
With SaaS, the provider handles almost everything under the hood. That includes infrastructure, OS, application code, and even most security controls. But this is the part that catches people constantly. You are still responsible for your data and who has access to it. If an employee reuses a weak password and someone breaks into your company's SaaS CRM, that's not the provider's failure. Identity and access management is always the customer's job, no matter which service model you're using.
This is why "we moved to the cloud so it's more secure now" is one of the most dangerous myths in IT. The cloud provider secures the cloud. You secure what's in the cloud. Misconfigured storage buckets, over permissive access controls, and exposed databases aren't provider failures. They show up in breach reports year after year precisely because someone assumed the responsibility line was somewhere it wasn't.
This concept sits in Domain 1, Cloud Architecture and Design, which makes up 13% of the CV0-003 exam. It might not be the heaviest weighted domain on this version of the test, but it's still foundational. Every other domain, from security to deployment to troubleshooting, assumes you already understand where the provider's job ends and yours begins. Get this concept solid, and a lot of exam scenario questions, and real production incidents, start making a lot more sense.
Worth noting, CV0-003 has been retired and replaced by CV0-004, so if you're actually sitting for the current exam, the newer version reorganizes some of this material and adds FaaS as its own named service model. But the underlying concepts here haven't changed. They're the same fundamentals either way.
Service models describe how much of the stack you manage. The shared responsibility model describes who's on the hook when something goes wrong. These are two sides of the same coin. Understanding both is really the foundation of thinking like a cloud engineer, instead of just someone who knows how to click "launch instance."
Part of an ongoing series breaking down CompTIA certifications in plain English. First up: Cloud+ (CV0-003), Domain 1. Cloud Architecture.
If you've ever sat through a vendor pitch and heard someone say "we're moving to a hybrid multicloud strategy," you probably nodded along and had no real idea what that meant. You're not alone. CompTIA Cloud+ opens its very first domain with exactly this topic, because before you can talk about anything else in the cloud, you need to know what kind of cloud you're actually talking about.
There are seven terms worth knowing here: public, private, hybrid, community, cloud-within-a-cloud, multicloud, and multitenancy. None of them are complicated once you strip away the jargon. Let's go through them one at a time.
This is the one most people already picture when they hear "the cloud." Amazon Web Services, Microsoft Azure, Google Cloud. A public cloud is infrastructure owned and operated by a provider, and that provider rents out slices of it to anyone who wants to pay. You don't own the servers. You don't own the building they sit in. You just log in and use what you need.
Think of it like renting an apartment in a large building. The landlord owns the property and maintains it. You have your own space, but you're sharing the building's plumbing, electrical systems, and elevators with a lot of other tenants you'll never meet.
A private cloud flips that model. Instead of sharing infrastructure with strangers, one organization gets the whole thing to itself. Sometimes that means the company owns and runs its own data center. Sometimes it means a provider sets aside dedicated hardware just for that one client, even if it's technically housed somewhere else.
This is the difference between renting an apartment and owning a house. You get full control, and you're the only one with a key. The tradeoff is that you're also the one responsible for the roof, the plumbing, and the electrical bill.
Most real organizations don't pick one model and stick with it forever. A hybrid cloud combines public and private cloud resources, letting data and applications move between them as needed. A company might keep sensitive customer records in a private cloud for tighter control, while running its public-facing website on a public cloud where it's cheap and easy to scale up during a busy sales event.
The point of hybrid isn't indecision. It's using each environment for what it does best.
A community cloud is shared, but not shared with just anyone. It's built for a specific group of organizations that have something in common, usually a shared industry, shared compliance requirements, or a shared mission. Think of a group of hospitals in the same region pooling resources into a cloud environment that's built around healthcare data regulations. They're not competitors sharing a public cloud with random businesses. They're peers sharing an environment tailored to their specific needs.
This one sounds more confusing than it is. Cloud-within-a-cloud describes a setup where a provider builds and operates their own cloud service on top of infrastructure that actually belongs to a different, larger cloud provider. A smaller SaaS company, for example, might build its entire product on top of AWS infrastructure. Their customers experience it as its own distinct service, but underneath the hood, it's running on someone else's cloud.
It's a bit like a restaurant that operates inside a shopping mall. Customers walk in thinking of it as its own place. But the mall owns the building, the utilities, and a lot of what makes that restaurant possible in the first place.
Multicloud means using more than one public cloud provider at the same time. A company might run part of its operations on AWS and another part on Google Cloud, either by choice or by accident of history, like after a merger between two companies that each had their own setup already.
The reasons for going multicloud vary. Sometimes it's about avoiding vendor lock-in. Sometimes different providers are simply better at different things. Sometimes it's about redundancy, so that if one provider has an outage, the business isn't completely dead in the water.
Don't confuse multicloud with hybrid cloud. Hybrid is about mixing public and private. Multicloud is about mixing multiple public providers.
Multitenancy isn't really a cloud model on its own. It's more of a description of how public cloud works underneath the surface. It means multiple customers, or tenants, share the same underlying physical infrastructure while their individual data and applications stay logically separated from each other.
Going back to the apartment building example from earlier, multitenancy is what makes that whole analogy work in the first place. Everyone shares the same building, but nobody can wander into someone else's unit. The cloud provider is responsible for making sure those walls stay solid, even though you're all technically living under the same roof.
None of these terms exist just to make exam questions harder. They shape real decisions that IT teams have to make. Choosing public over private isn't just about cost. It's about compliance requirements, control, performance needs, and risk tolerance. Understanding the difference between hybrid and multicloud helps you understand why a company's architecture looks the way it does, and why migrating away from one setup is often a lot harder than it sounds.
If you're studying for Cloud+, this is the foundation everything else gets built on. And if you're just trying to understand what your company's IT department keeps talking about in meetings, this is the vocabulary that makes those conversations finally make sense.
