CompTIA Infrastructure and Cloud Certification Path: A+, Network+, Linux+, Cloud+, and Beyond

 

How to use this roadmap

The useful roadmap is not a stack of exams. It is a sequence of operational questions: can you support a device, understand its network, administer the operating system, and run services reliably in cloud environments? Thinking in layers keeps infrastructure study honest: the endpoint must work, the network must carry the traffic, the operating system must host the service, and the cloud or virtualization layer must keep the workload available and observable. A certification is useful when it strengthens one of those layers and improves troubleshooting across the boundaries between them.

The current references behind this roadmap were checked on September 20, 2026. A+ anchors endpoint and support troubleshooting. Network+ N10-009 builds vendor-neutral networking implementation and troubleshooting. Linux+ deepens operating-system administration, automation and service operations. Cloud+ CV0-004 covers cloud architecture, deployment, operations, security, DevOps fundamentals and troubleshooting. Those facts describe the credential landscape; the sequence proposed here is an editorial learning model, not a set of formal prerequisites.

Infrastructure careers branch quickly. Desktop support, network operations, Linux administration, cloud operations, platform engineering, and infrastructure security share fundamentals, but they do not require identical depth. A candidate should therefore treat A+, Network+, Linux+, and Cloud+ as capability checkpoints that can be entered, skipped, or revisited according to evidence from real work and labs.

A useful outcome is a troubleshooting chain you can carry from a laptop to a distributed service: establish expected state, isolate the failing layer, collect the least ambiguous evidence available, make a bounded change, and verify recovery. That chain is the spine of this article, and it is more durable than any one exam code.

Readers organizing vendor-neutral infrastructure study can also use the CompTIA certification training overview. Use it to locate resources after the capability gaps are clear, rather than letting a catalog decide the order of your learning.

Think in operational layers rather than badge order

Infrastructure work is easiest to understand as layers that depend on one another during diagnosis. Within Think in operational layers rather than badge order, infrastructure competence is cumulative because a failure at one layer often appears as a symptom at another. In think in operational layers rather than badge order, the goal is to make the layer visible enough that you can test it without guessing.

A support problem that looks like an application failure may actually be hardware, operating-system, DNS, routing, authentication, certificate, storage, or cloud-service behavior, so foundational breadth reduces blind spots. Within think in operational layers rather than badge order, translate the concept into an observable infrastructure state: a service is running or stopped, a route exists or does not, a permission grants or denies, a backup restores or fails. Within Think in operational layers rather than badge order, this keeps infrastructure study grounded in systems that can be inspected, changed, and recovered rather than in vague familiarity.

The certifications become more useful when each one expands the layer you can reason about: endpoint, network path, server operating system, virtualization and cloud control plane. The diagnostic payoff in think in operational layers rather than badge order is that the operator knows where to look next. Within Think in operational layers rather than badge order, build a small lab, record expected state, introduce one controlled fault, and use commands, logs, counters, or monitoring data to isolate the layer. Within Think in operational layers rather than badge order, repeating that cycle across endpoint, network, Linux, and cloud work creates a common operating method.

There is no rule that every infrastructure professional must earn every credential; experienced practitioners can use the roadmap to identify missing layers instead of restarting from zero. For the infrastructure path, think in operational layers rather than badge order should end with repeatability. Within Think in operational layers rather than badge order, document the configuration or procedure, verify it after a restart or redeployment, and test a rollback. Within Think in operational layers rather than badge order, a credential is much more credible when the learner can restore service after a deliberate failure than when they can only describe the happy path.

Scenario: A cloud administrator sees intermittent application timeouts; without endpoint, DNS and network reasoning, it is easy to blame the cloud platform before proving where the path actually fails. For think in operational layers rather than badge order, locate the failing layer before replacing components or widening access. Within Think in operational layers rather than badge order, record the expected state, gather one decisive observation, make the smallest reversible change, and verify that service is restored across the relevant dependency chain.

Infrastructure drill for Think in operational layers rather than badge order: diagram the dependency path, establish normal state, break one dependency on purpose, diagnose it from commands or monitoring, restore service, and document rollback. Within Think in operational layers rather than badge order, if you cannot say which layer failed and why the evidence supports that conclusion, repeat the exercise before moving on.

A+ establishes support discipline and endpoint context

A+ is strongest when treated as a troubleshooting foundation rather than a collection of hardware labels. Within A+ establishes support discipline and endpoint context, infrastructure competence is cumulative because a failure at one layer often appears as a symptom at another. In a+ establishes support discipline and endpoint context, the goal is to make the layer visible enough that you can test it without guessing.

Endpoint work joins mobile devices, client hardware, operating systems, basic networking, virtualization/cloud concepts, security hygiene, and operational procedures into one support context. Within a+ establishes support discipline and endpoint context, translate the concept into an observable infrastructure state: a service is running or stopped, a route exists or does not, a permission grants or denies, a backup restores or fails. Within A+ establishes support discipline and endpoint context, this keeps infrastructure study grounded in systems that can be inspected, changed, and recovered rather than in vague familiarity.

Good troubleshooting starts with symptom clarification, change history, scope, reproduction, safety and evidence before replacement or reinstallation; that process remains useful at every later infrastructure layer. The diagnostic payoff in a+ establishes support discipline and endpoint context is that the operator knows where to look next. Within A+ establishes support discipline and endpoint context, build a small lab, record expected state, introduce one controlled fault, and use commands, logs, counters, or monitoring data to isolate the layer. Within A+ establishes support discipline and endpoint context, repeating that cycle across endpoint, network, Linux, and cloud work creates a common operating method.

Support professionals also learn that technical correctness is not enough: documentation, escalation, backups, user communication and change control influence whether a repair is safe and repeatable. For the infrastructure path, a+ establishes support discipline and endpoint context should end with repeatability. Within A+ establishes support discipline and endpoint context, document the configuration or procedure, verify it after a restart or redeployment, and test a rollback. Within A+ establishes support discipline and endpoint context, a credential is much more credible when the learner can restore service after a deliberate failure than when they can only describe the happy path.

Scenario: A laptop cannot reach an internal application after a VPN client update; the support technician should isolate local configuration, name resolution, routing and authentication before wiping the device. For a+ establishes support discipline and endpoint context, locate the failing layer before replacing components or widening access. Within A+ establishes support discipline and endpoint context, record the expected state, gather one decisive observation, make the smallest reversible change, and verify that service is restored across the relevant dependency chain.

Infrastructure drill for A+ establishes support discipline and endpoint context: diagram the dependency path, establish normal state, break one dependency on purpose, diagnose it from commands or monitoring, restore service, and document rollback. Within A+ establishes support discipline and endpoint context, if you cannot say which layer failed and why the evidence supports that conclusion, repeat the exercise before moving on.

Network+ makes the path between systems visible

Networking knowledge turns “the server is down” into a testable sequence of link, addressing, routing, services, security and performance questions. Within Network+ makes the path between systems visible, infrastructure competence is cumulative because a failure at one layer often appears as a symptom at another. In network+ makes the path between systems visible, the goal is to make the layer visible enough that you can test it without guessing.

Network+ should build comfort with topologies, IP addressing, switching and routing concepts, common services, wireless, cloud and virtual networking, monitoring, security hardening and structured troubleshooting. Within network+ makes the path between systems visible, translate the concept into an observable infrastructure state: a service is running or stopped, a route exists or does not, a permission grants or denies, a backup restores or fails. Within Network+ makes the path between systems visible, this keeps infrastructure study grounded in systems that can be inspected, changed, and recovered rather than in vague familiarity.

Vendor-neutral study is valuable because the same reasoning survives a change in switch, firewall or cloud provider: determine intended traffic flow, observe actual state, find the boundary where behavior changes. The diagnostic payoff in network+ makes the path between systems visible is that the operator knows where to look next. Within Network+ makes the path between systems visible, build a small lab, record expected state, introduce one controlled fault, and use commands, logs, counters, or monitoring data to isolate the layer. Within Network+ makes the path between systems visible, repeating that cycle across endpoint, network, Linux, and cloud work creates a common operating method.

Packet captures, route tables, DNS queries, port tests, interface counters and diagrams are more useful readiness evidence than memorizing port numbers without a diagnostic story. For the infrastructure path, network+ makes the path between systems visible should end with repeatability. Within Network+ makes the path between systems visible, document the configuration or procedure, verify it after a restart or redeployment, and test a rollback. Within Network+ makes the path between systems visible, a credential is much more credible when the learner can restore service after a deliberate failure than when they can only describe the happy path.

Scenario: An application works from one subnet but not another; a strong Network+ learner can build a hypothesis around routing, ACLs, name resolution and return path instead of randomly changing firewall rules. For network+ makes the path between systems visible, locate the failing layer before replacing components or widening access. Within Network+ makes the path between systems visible, record the expected state, gather one decisive observation, make the smallest reversible change, and verify that service is restored across the relevant dependency chain.

Infrastructure drill for Network+ makes the path between systems visible: diagram the dependency path, establish normal state, break one dependency on purpose, diagnose it from commands or monitoring, restore service, and document rollback. Within Network+ makes the path between systems visible, if you cannot say which layer failed and why the evidence supports that conclusion, repeat the exercise before moving on.

Linux+ turns a generalist into a stronger systems operator

Linux sits underneath a large share of servers, appliances, containers and cloud workloads, so command-line operational fluency compounds later skills. Within Linux+ turns a generalist into a stronger systems operator, infrastructure competence is cumulative because a failure at one layer often appears as a symptom at another. In linux+ turns a generalist into a stronger systems operator, the goal is to make the layer visible enough that you can test it without guessing.

Practical Linux work includes filesystems, permissions, processes, services, package management, networking, logs, storage, shell tooling, security controls, automation and recovery from misconfiguration. Within linux+ turns a generalist into a stronger systems operator, translate the concept into an observable infrastructure state: a service is running or stopped, a route exists or does not, a permission grants or denies, a backup restores or fails. Within Linux+ turns a generalist into a stronger systems operator, this keeps infrastructure study grounded in systems that can be inspected, changed, and recovered rather than in vague familiarity.

The important transition is from knowing commands to managing state: what should be running, what changed, where configuration is stored, how to verify permissions, and how to roll back safely. The diagnostic payoff in linux+ turns a generalist into a stronger systems operator is that the operator knows where to look next. Within Linux+ turns a generalist into a stronger systems operator, build a small lab, record expected state, introduce one controlled fault, and use commands, logs, counters, or monitoring data to isolate the layer. Within Linux+ turns a generalist into a stronger systems operator, repeating that cycle across endpoint, network, Linux, and cloud work creates a common operating method.

Automation becomes meaningful when scripts are idempotent, observable, version-controlled and bounded by error handling; a fast script that hides failures is not operational maturity. For the infrastructure path, linux+ turns a generalist into a stronger systems operator should end with repeatability. Within Linux+ turns a generalist into a stronger systems operator, document the configuration or procedure, verify it after a restart or redeployment, and test a rollback. Within Linux+ turns a generalist into a stronger systems operator, a credential is much more credible when the learner can restore service after a deliberate failure than when they can only describe the happy path.

Scenario: A service works after a manual restart but fails after every reboot; the administrator needs to inspect service dependencies, enablement, configuration and logs rather than adding an undocumented cron workaround. For linux+ turns a generalist into a stronger systems operator, locate the failing layer before replacing components or widening access. Within Linux+ turns a generalist into a stronger systems operator, record the expected state, gather one decisive observation, make the smallest reversible change, and verify that service is restored across the relevant dependency chain.

Infrastructure drill for Linux+ turns a generalist into a stronger systems operator: diagram the dependency path, establish normal state, break one dependency on purpose, diagnose it from commands or monitoring, restore service, and document rollback. Within Linux+ turns a generalist into a stronger systems operator, if you cannot say which layer failed and why the evidence supports that conclusion, repeat the exercise before moving on.

For networking depth before cloud troubleshooting, the useful companion is foundations of IT networking for Network+ N10-009. That resource is most useful when DNS, addressing, routing, or service behavior is the bottleneck in a cloud-oriented study plan.

Cloud+ broadens operations from hosts to distributed services

Cloud operations add abstraction but they do not remove networking, identity, security, availability or troubleshooting fundamentals. Within Cloud+ broadens operations from hosts to distributed services, infrastructure competence is cumulative because a failure at one layer often appears as a symptom at another. In cloud+ broadens operations from hosts to distributed services, the goal is to make the layer visible enough that you can test it without guessing.

Current Cloud+ coverage spans architecture, deployment, operations, security, DevOps fundamentals and troubleshooting, which makes it useful for people responsible for multi-cloud or hybrid operational outcomes. Within cloud+ broadens operations from hosts to distributed services, translate the concept into an observable infrastructure state: a service is running or stopped, a route exists or does not, a permission grants or denies, a backup restores or fails. Within Cloud+ broadens operations from hosts to distributed services, this keeps infrastructure study grounded in systems that can be inspected, changed, and recovered rather than in vague familiarity.

Cloud architecture decisions should connect workload requirements to resiliency, scaling, data protection, network design, identity, observability and cost; choosing a service by popularity is not architecture. The diagnostic payoff in cloud+ broadens operations from hosts to distributed services is that the operator knows where to look next. Within Cloud+ broadens operations from hosts to distributed services, build a small lab, record expected state, introduce one controlled fault, and use commands, logs, counters, or monitoring data to isolate the layer. Within Cloud+ broadens operations from hosts to distributed services, repeating that cycle across endpoint, network, Linux, and cloud work creates a common operating method.

Operational competence includes deployment repeatability, lifecycle management, monitoring, backup and recovery, security controls, automation and diagnosing failures that cross provider and on-premises boundaries. For the infrastructure path, cloud+ broadens operations from hosts to distributed services should end with repeatability. Within Cloud+ broadens operations from hosts to distributed services, document the configuration or procedure, verify it after a restart or redeployment, and test a rollback. Within Cloud+ broadens operations from hosts to distributed services, a credential is much more credible when the learner can restore service after a deliberate failure than when they can only describe the happy path.

Scenario: A workload scales successfully but loses sessions during a zone failure; the cloud operator must connect application state, load balancing, persistence, data replication and recovery objectives. For cloud+ broadens operations from hosts to distributed services, locate the failing layer before replacing components or widening access. Within Cloud+ broadens operations from hosts to distributed services, record the expected state, gather one decisive observation, make the smallest reversible change, and verify that service is restored across the relevant dependency chain.

Infrastructure drill for Cloud+ broadens operations from hosts to distributed services: diagram the dependency path, establish normal state, break one dependency on purpose, diagnose it from commands or monitoring, restore service, and document rollback. Within Cloud+ broadens operations from hosts to distributed services, if you cannot say which layer failed and why the evidence supports that conclusion, repeat the exercise before moving on.

Hands-on practice should become more integrated at each stage

A good lab progression deliberately reuses earlier skills so later practice feels like operating a system rather than completing isolated tutorials. Within Hands-on practice should become more integrated at each stage, infrastructure competence is cumulative because a failure at one layer often appears as a symptom at another. In hands-on practice should become more integrated at each stage, the goal is to make the layer visible enough that you can test it without guessing.

Start with endpoint and support labs, then add a small routed network, then Linux services, and finally deploy or connect those services in a cloud environment with identity, monitoring and backup controls. Within hands-on practice should become more integrated at each stage, translate the concept into an observable infrastructure state: a service is running or stopped, a route exists or does not, a permission grants or denies, a backup restores or fails. Within Hands-on practice should become more integrated at each stage, this keeps infrastructure study grounded in systems that can be inspected, changed, and recovered rather than in vague familiarity.

Document expected state before changing anything; capture evidence after the change; then inject a failure and diagnose it. That loop teaches more than a “click here, then click there” lab. The diagnostic payoff in hands-on practice should become more integrated at each stage is that the operator knows where to look next. Within Hands-on practice should become more integrated at each stage, build a small lab, record expected state, introduce one controlled fault, and use commands, logs, counters, or monitoring data to isolate the layer. Within Hands-on practice should become more integrated at each stage, repeating that cycle across endpoint, network, Linux, and cloud work creates a common operating method.

Keep the lab lawful and inexpensive: local virtualization, trial accounts and intentionally vulnerable training environments can demonstrate operational reasoning without touching systems you do not own. For the infrastructure path, hands-on practice should become more integrated at each stage should end with repeatability. Within Hands-on practice should become more integrated at each stage, document the configuration or procedure, verify it after a restart or redeployment, and test a rollback. Within Hands-on practice should become more integrated at each stage, a credential is much more credible when the learner can restore service after a deliberate failure than when they can only describe the happy path.

Scenario: A learner builds a web service, places it behind a reverse proxy, restricts network access, adds monitoring and restores it from backup; one project can exercise A+, Network+, Linux+ and Cloud+ concepts together. For hands-on practice should become more integrated at each stage, locate the failing layer before replacing components or widening access. Within Hands-on practice should become more integrated at each stage, record the expected state, gather one decisive observation, make the smallest reversible change, and verify that service is restored across the relevant dependency chain.

Infrastructure drill for Hands-on practice should become more integrated at each stage: diagram the dependency path, establish normal state, break one dependency on purpose, diagnose it from commands or monitoring, restore service, and document rollback. Within Hands-on practice should become more integrated at each stage, if you cannot say which layer failed and why the evidence supports that conclusion, repeat the exercise before moving on.

Use job families to decide how far to go

The “beyond” part of the roadmap depends on role direction: infrastructure generalist, Linux administrator, cloud operator, network engineer, security specialist or automation-focused engineer. Within Use job families to decide how far to go, infrastructure competence is cumulative because a failure at one layer often appears as a symptom at another. In use job families to decide how far to go, the goal is to make the layer visible enough that you can test it without guessing.

A network-heavy role may deepen routing, switching and security sooner; a platform role may emphasize Linux, infrastructure-as-code and observability; a support role may benefit more from endpoint management and service management. Within use job families to decide how far to go, translate the concept into an observable infrastructure state: a service is running or stopped, a route exists or does not, a permission grants or denies, a backup restores or fails. Within Use job families to decide how far to go, this keeps infrastructure study grounded in systems that can be inspected, changed, and recovered rather than in vague familiarity.

Cloud provider certifications can add product-specific depth after the vendor-neutral model is stable, but they should not replace understanding of networking, identity, operating systems and failure analysis. The diagnostic payoff in use job families to decide how far to go is that the operator knows where to look next. Within Use job families to decide how far to go, build a small lab, record expected state, introduce one controlled fault, and use commands, logs, counters, or monitoring data to isolate the layer. Within Use job families to decide how far to go, repeating that cycle across endpoint, network, Linux, and cloud work creates a common operating method.

Security is cross-cutting rather than a final step: every layer should include least privilege, secure configuration, patching, logging, backup protection and recovery testing. For the infrastructure path, use job families to decide how far to go should end with repeatability. Within Use job families to decide how far to go, document the configuration or procedure, verify it after a restart or redeployment, and test a rollback. Within Use job families to decide how far to go, a credential is much more credible when the learner can restore service after a deliberate failure than when they can only describe the happy path.

Scenario: Two people both want “cloud careers”; one administers Kubernetes workloads and the other supports hybrid Microsoft endpoints, so the useful next certification and lab plan are necessarily different. For use job families to decide how far to go, locate the failing layer before replacing components or widening access. Within Use job families to decide how far to go, record the expected state, gather one decisive observation, make the smallest reversible change, and verify that service is restored across the relevant dependency chain.

Infrastructure drill for Use job families to decide how far to go: diagram the dependency path, establish normal state, break one dependency on purpose, diagnose it from commands or monitoring, restore service, and document rollback. Within Use job families to decide how far to go, if you cannot say which layer failed and why the evidence supports that conclusion, repeat the exercise before moving on.

Create a readiness matrix instead of collecting credentials

A readiness matrix converts a broad roadmap into a sequence of measurable capabilities. Within Create a readiness matrix instead of collecting credentials, infrastructure competence is cumulative because a failure at one layer often appears as a symptom at another. In create a readiness matrix instead of collecting credentials, the goal is to make the layer visible enough that you can test it without guessing.

For every layer, rate yourself on explanation, configuration, troubleshooting and recovery; being able to define a concept is weaker evidence than restoring service after a controlled fault. Within create a readiness matrix instead of collecting credentials, translate the concept into an observable infrastructure state: a service is running or stopped, a route exists or does not, a permission grants or denies, a backup restores or fails. Within Create a readiness matrix instead of collecting credentials, this keeps infrastructure study grounded in systems that can be inspected, changed, and recovered rather than in vague familiarity.

Tie each weak row to one study source, one lab and one verification artifact so time is spent closing gaps instead of repeatedly reviewing familiar material. The diagnostic payoff in create a readiness matrix instead of collecting credentials is that the operator knows where to look next. Within Create a readiness matrix instead of collecting credentials, build a small lab, record expected state, introduce one controlled fault, and use commands, logs, counters, or monitoring data to isolate the layer. Within Create a readiness matrix instead of collecting credentials, repeating that cycle across endpoint, network, Linux, and cloud work creates a common operating method.

Reassess after projects and interviews because the role market changes and practical experience can reorder priorities more intelligently than following a static diagram forever. For the infrastructure path, create a readiness matrix instead of collecting credentials should end with repeatability. Within Create a readiness matrix instead of collecting credentials, document the configuration or procedure, verify it after a restart or redeployment, and test a rollback. Within Create a readiness matrix instead of collecting credentials, a credential is much more credible when the learner can restore service after a deliberate failure than when they can only describe the happy path.

Scenario: A candidate who can configure a service but cannot troubleshoot name resolution should not rush to a more advanced cloud badge; the matrix makes that missing dependency visible before it becomes an interview failure. For create a readiness matrix instead of collecting credentials, locate the failing layer before replacing components or widening access. Within Create a readiness matrix instead of collecting credentials, record the expected state, gather one decisive observation, make the smallest reversible change, and verify that service is restored across the relevant dependency chain.

Infrastructure drill for Create a readiness matrix instead of collecting credentials: diagram the dependency path, establish normal state, break one dependency on purpose, diagnose it from commands or monitoring, restore service, and document rollback. Within Create a readiness matrix instead of collecting credentials, if you cannot say which layer failed and why the evidence supports that conclusion, repeat the exercise before moving on.

Putting the roadmap into action

Infrastructure and cloud competence is a chain of dependencies. A+, Network+, Linux+, and Cloud+ can strengthen different links, but the credential order should follow the weakest link in the job you want—not the neatest diagram.

Keep one integrated lab and keep breaking it safely. If you can support the endpoint, trace the network, administer the Linux service, operate the cloud layer, and recover the workload from evidence, the roadmap is producing transferable infrastructure skill.

A 90-day applied development plan

Days 1–30: assemble one small infrastructure environment that has a client, a routed or virtual network, a Linux service, and a backup path. Document the expected state before changing anything: addressing, DNS, service ports, accounts, file permissions, and the application’s dependency chain. Practice A+-style endpoint support and Network+-style path validation until you can isolate a local failure from a network failure without reinstalling or rebooting blindly. The first month should produce a troubleshooting notebook with commands, observations, causes, and verified fixes rather than screenshots of completed tutorials.

Days 31–60: deepen Linux operations and make the service repeatable. Configure the service through files or automation you can version, inspect logs during startup and failure, restrict permissions, schedule or trigger a maintenance task, and restore data from backup. Add one network-control change and prove what traffic is allowed before and after it. If possible, recreate the workload in a low-cost cloud or sandbox and compare what moved from host configuration into the cloud control plane. The goal is to see which responsibilities remain yours even when infrastructure becomes more abstract.

Days 61–90: operate the environment as if another person depends on it. Add monitoring, write a short change procedure, inject a DNS, routing, permission, storage, or service failure, and recover against a target time. Track which step causes the most uncertainty. If the bottleneck is endpoint support, deepen A+ topics; if it is network path reasoning, prioritize Network+; if Linux state is opaque, strengthen Linux+; if distributed deployment, resilience, and cloud lifecycle are the challenge, Cloud+ becomes a more defensible next target.