Quick answer
Choose a starting path by the work you want to become able to do-not by the longest certification ladder or the largest service catalog. Pick one primary capability, one anchor cloud, and one small end-to-end artifact that you can deploy, inspect, change, and explain.
Start with cloud concepts and responsibility boundaries if you cannot yet explain compute, storage, networking, identity, service models, or what the customer still controls. Microsoft’s beginner cloud module explicitly covers cloud models and shared responsibility, while AWS organizes training by distinct roles such as practitioner, architect, developer, and DevOps engineer. Microsoft Learn cloud-computing module AWS role-based training
Evidence and scope
- Evidence profile
- E1 – official-source cloud and DevOps learning-path guide
- Information checked
- Primary market
- United States; English-language self-directed technical learning
- Decision covered
- Choosing a first capability path across cloud foundations, operations, development, architecture, DevOps/platform work, and reliability/observability
- Direct evaluation
- Not performed; no paid course, cloud account, lab, certification workflow, production system, support channel, or learner outcome was tested
- Main limitation
- Official role and training pages describe intended scope, not teaching quality, personal fit, completion likelihood, or job outcomes
Key facts
- Cloud operations, cloud development, architecture, DevOps, and reliability are overlapping but distinct capability targets.
- Provider role paths are useful inventories; they are not proof that one sequence fits every learner.
- Linux, version control, identity, networking, and basic scripting remain portable across provider-specific paths.
- Containers, infrastructure as code, CI/CD, orchestration, and observability should be attached to a workload rather than learned as disconnected vocabulary.
- A certificate can be a checkpoint, but it does not replace evidence that you can deploy, inspect, change, and recover a system.
Why “learn cloud” is too broad
A cloud path can mean learning service concepts, operating infrastructure, building applications, designing systems, automating delivery, or improving reliability. Those paths share vocabulary but produce different work. Google’s infrastructure training separates Cloud Engineer and Cloud Architect routes, while its application-development training describes a Cloud Developer as someone who designs, builds, analyzes, and maintains cloud-native applications. Google Cloud infrastructure learning paths Google Cloud application-development learning paths
DevOps is also broader than a tool list. Microsoft describes it as a combination of people, process, and technology across planning, development, delivery, and operations. Its practices include version control, automated testing, CI/CD, infrastructure delivery, monitoring, troubleshooting, and collaboration. A course that teaches only one pipeline product may therefore cover a tool without covering the full operating loop. Microsoft DevOps overview
The practical consequence is simple: choose the first capability you need to demonstrate. Provider, certification, and product decisions should support that capability. They should not define it before you know whether your next task is operating a workload, building an application, designing an architecture, automating change, or diagnosing a service.
Six starting routes
On a small screen, swipe or scroll the table horizontally to compare all columns.
| Route | First observable deliverable | Foundation to verify first | Defer until the deliverable works |
|---|---|---|---|
| Cloud foundations | Explain and deploy one small service with identity, networking, cost, and responsibility notes | Basic IT terms and command-line comfort | Multi-cloud breadth, Kubernetes, and advanced certification prep |
| Cloud operations | Provision, secure, monitor, back up, and remove one workload | Linux, networking, IAM, logging, and change records | Application-framework depth and complex platform engineering |
| Cloud development | Build and deploy a small application, then inspect logs and configuration | One programming language, Git, APIs, and basic cloud services | Fleet operations, advanced networking, and broad architecture catalogs |
| Solutions architecture | Document requirements, tradeoffs, security boundaries, failure modes, and a tested reference workload | One implemented workload plus operations and cost awareness | Memorizing every service or designing systems you have never built |
| DevOps or platform engineering | Move a versioned change through build, test, infrastructure, deployment, and rollback controls | Git, scripting, cloud fundamentals, tests, and one deployable application | Toolchain accumulation without a repeatable delivery loop |
| Reliability and observability | Define service signals, create an alert or dashboard, diagnose a failure, and record recovery | Application and operations basics plus logs and metrics | Abstract SRE vocabulary without a service to observe |
AWS’s official plans illustrate the difference in intended outputs. The architect plan includes security, monitoring, automation, and containers; the developer plan focuses on developing, deploying, and modernizing applications; and the DevOps plan focuses on deploying, managing, and monitoring cloud applications. These are scope signals, not rankings or guarantees. AWS Solutions Architect learning plan AWS Developer learning plan AWS DevOps learning plan
Google’s current Cloud DevOps Engineer scope also shows why a DevOps route is usually not “learn a CI tool.” It includes organization setup, infrastructure management, CI/CD, SRE practices, observability, troubleshooting, performance, and cost. Google Cloud DevOps Engineer scope
How to select one route
1. Write one capability statement
Use an observable verb and object: “deploy and monitor a small web service,” “provision a network and compute workload from versioned configuration,” or “build a tested application delivery pipeline with a rollback step.” Avoid goals such as “master cloud” or “become DevOps-ready”; they are too broad to determine prerequisites or evidence.
2. Audit the portable foundation
Mark each foundation as usable, review needed, or not yet demonstrated: command line, Linux, networking, identity and access, version control, one scripting or programming language, basic testing, and reading logs. The Linux Foundation’s introductory course is explicitly aimed at experienced computer users with limited Linux exposure and covers major distributions, system configuration, and command-line operations. Linux Foundation Introduction to Linux
Version control belongs in the foundation even for infrastructure-focused learners. Git’s official book defines version control as recording file changes over time so specific versions can be recalled, compared, or restored. That capability supports application code, infrastructure configuration, pipeline definitions, and runbooks. Pro Git: About Version Control
3. Choose one anchor cloud for the first project
Use your target environment, employer context, existing account, course availability, or required service as the anchor. The purpose is to reduce simultaneous vocabulary, billing, identity, and console changes-not to declare a universal provider winner. Microsoft’s Azure fundamentals path demonstrates a bounded beginner route through architecture, services, management, governance, and guided projects. Microsoft Learn Azure architecture and services path
4. Map the responsibility boundary
For the chosen service, record what the provider manages and what you still manage: data, identities, access, configuration, operating systems, applications, network controls, backups, or patching. AWS states that customer responsibility varies by selected service and includes tasks such as guest operating-system management, application software, data controls, IAM, and firewall configuration in relevant service models. AWS shared responsibility model
5. Require an end-to-end practice loop
The first project should include a versioned change, an automated or repeatable check, a deployment, an observation, and a cleanup or rollback. GitHub describes continuous deployment as automation that builds and tests code before deployment; the exact controls vary, but the evidence should show what happened before and after the change. GitHub continuous-deployment documentation
6. Set a checkpoint before expanding the stack
Do not add a second provider, orchestration layer, or advanced certification because the first course ended. Add it when the current project exposes a real constraint: repeated manual provisioning, inconsistent environments, deployment risk, missing visibility, scaling needs, or a target role that explicitly requires broader coverage.
Portable foundations and a safer sequence
The sequence below is a diagnostic order, not a universal curriculum. Skip a step only when you can produce the named evidence without following a walkthrough.
Application packaging before orchestration
Docker describes containers as isolated processes for application components. A useful first container artifact therefore shows how an application is packaged, configured, run, inspected, and removed. Docker container concepts
Kubernetes manages containerized workloads and services with declarative configuration and automation. That makes container behavior, configuration, networking, and application health material prerequisite checks before choosing a Kubernetes-first path. Kubernetes concepts
Repeatable infrastructure before tool breadth
HashiCorp defines infrastructure as code as managing infrastructure with configuration files rather than only a graphical interface. Its documented workflow includes authoring configuration, initializing, planning, applying, tracking state, and collaborating through version control. Terraform infrastructure-as-code introduction
The buyer test is not whether a course mentions Terraform. Ask whether you will create, review, change, and remove infrastructure from a versioned configuration and whether state, credentials, drift, and destructive changes are addressed within the authorized practice scope.
Signals before reliability claims
OpenTelemetry distinguishes traces, metrics, logs, and baggage as telemetry signals. A beginner project does not need every observability product, but it should make at least one runtime signal visible and connect it to a question: Is the service available? What failed? How long did the request take? What changed? OpenTelemetry signals
On a small screen, swipe or scroll the table horizontally to compare all columns.
| Layer | Minimum evidence artifact | Stop and review when |
|---|---|---|
| Cloud fundamentals | Service-model and shared-responsibility note tied to one deployment | You cannot explain who manages identity, data, configuration, patching, or cost |
| Operations | Runbook with deploy, inspect, backup or recovery, and cleanup steps | The task works only through copied console clicks |
| Development | Repository with application, configuration, tests, and deployment record | You cannot separate application failure from environment failure |
| Infrastructure as code | Reviewed plan, applied change, state decision, and destroy or rollback record | Credentials or destructive changes are not controlled |
| CI/CD | Pipeline run showing build, test, approval or gate, deployment, and recovery path | A failed change cannot be diagnosed or reversed |
| Containers and orchestration | Containerized application plus health, configuration, networking, and rollout evidence | You are debugging orchestration without understanding the container or application |
| Reliability | Logs, metrics or traces linked to one incident or controlled failure | An alert has no user-impact question or response action |
When to choose a different starting format
- Use a fundamentals path when service models, identity, networking, billing, or responsibility boundaries are still unfamiliar.
- Use a role path when you can name the target output but need a curated inventory of concepts and services.
- Use a project-led path when you already understand the concepts and need evidence across build, deploy, observe, and recover.
- Use a technology-specific path only when the target task requires that technology; do not start with Kubernetes, Terraform, or a CI system merely because it appears in many job descriptions.
- Use certification preparation when the current exam blueprint is itself a required checkpoint; keep hands-on capability evidence separate from exam coverage.
If none of these formats closes a defined gap, defer the purchase. A longer catalog is not useful when you cannot identify which capability it adds to the first project.
Unknowns and limitations
- Official learning paths can change their course order, products, free-access boundaries, labs, and certification alignment.
- This research did not compare teaching quality, support responsiveness, accessibility, device compatibility, lab reliability, or learner completion.
- No paid account, cloud credits, production environment, or provider console was used.
- No route is presented as the fastest route to employment, the highest-paying route, or a universal prerequisite sequence.
- The appropriate provider can depend on employer standards, geography, existing systems, compliance, budget, and account access that were not supplied for an individual reader.
- Advanced role pages and certification guides describe broad scopes; they do not prove that a beginner should attempt the credential or follow every listed topic immediately.
Methodology
This E1 guide was assembled from current official training, documentation, and role-scope pages checked on September 11, 2026. Sources were included to distinguish role intent, cloud responsibility, portable foundations, delivery automation, infrastructure as code, containers, orchestration, and observability. Provider pages were treated as documented scope-not as independent proof of quality, outcomes, or learner fit.
The article uses a capability-first decision framework and a representative learner scenario. It does not use paid access, direct evaluation, weighted scoring, affiliate economics, salary data, or employment claims. The proposed sequence is an editorial diagnostic derived from the approved source set; it is not a tested universal curriculum. See How we test for the site’s evidence profiles and testing boundaries.
Sources
- Microsoft Learn, “Describe cloud computing,” checked September 11, 2026. Official source
- Microsoft Learn, “Introduction to Cloud Infrastructure: Describe Azure architecture and services,” checked September 11, 2026. Official source
- Microsoft Learn, “What is DevOps?,” checked September 11, 2026. Official source
- AWS Training and Certification, “Learning by Role or Solution,” checked September 11, 2026. Official source
- AWS Training, “Solutions Architect,” checked September 11, 2026. Official source
- AWS Training, “Developer,” checked September 11, 2026. Official source
- AWS Training, “DevOps Engineer,” checked September 11, 2026. Official source
- Google Cloud Training, “Cloud Infrastructure & Architecture,” checked September 11, 2026. Official source
- Google Cloud Training, “Build Cloud Applications,” checked September 11, 2026. Official source
- Google Cloud, “Professional Cloud DevOps Engineer,” checked September 11, 2026. Official source
- Linux Foundation Education, “Introduction to Linux (LFS101),” checked September 11, 2026. Official source
- Git, “About Version Control,” checked September 11, 2026. Official source
- GitHub Docs, “Continuous deployment,” checked September 11, 2026. Official source
- Docker Docs, “What is a container?,” checked September 11, 2026. Official source
- HashiCorp Developer, “What is Infrastructure as Code with Terraform?,” checked September 11, 2026. Official source
- Kubernetes Documentation, “Concepts,” checked September 11, 2026. Official source
- OpenTelemetry, “Signals,” checked September 11, 2026. Official source
- AWS, “Shared Responsibility Model,” checked September 11, 2026. Official source