How to Master One of the Hardest Parts of the CompTIA Cloud+ Exam: DevOps Fundamentals

DevOps Fundamentals is the smallest domain on the CompTIA Cloud+ exam, but many candidates say it feels like one of the hardest. There are a few reasons. It’s brand new as a standalone domain on CV0-004, so older study materials may barely cover it. Many Cloud+ candidates come from systems or network administration, not software development, so terms like pull request, artifact, and GraphQL can feel foreign. And the domain names nine different tools, several of which overlap in ways that make answer choices look alike.

In this guide, we’ll break down what the domain covers, explain the core concepts in plain language, point out common traps, and walk through two sample scenarios.

What Does DevOps Fundamentals Cover on the Cloud+ Exam?

Domain 5.0 makes up 10% of the exam, which is roughly 9 questions on a 90-question exam. According to the CV0-004 exam objectives, it has four objectives:

  • 5.1 Source control: Version management, code review, pull requests, code push, commit, merge, and branch management.
  • 5.2 CI/CD pipelines: Automation, code integration, code deployment (build, testing, security, workflow), artifacts (VM and container images, RPM, Debian, ZIP, and tar packages, flat files), and public and private repositories.
  • 5.3 System integration: Event-driven architectures and web services, including REST, SOAP, RPC, WebSockets, and GraphQL.
  • 5.4 DevOps tools: Ansible, Docker, ELK stack, Git, GitHub Actions, Grafana, Jenkins, Kubernetes, and Terraform.

Notice the verb in every objective: “explain.” You won’t be asked to write a pipeline from scratch, but you do need to know what each piece does and when to use it.

Core Concepts You Need to Know

Source Control With Git

Source control tracks every change to code and configuration so teams can collaborate and roll back safely. Git is the standard tool.

  • Commit: Saves a snapshot of changes to your local repository, with a message describing what changed.
  • Push: Sends your local commits to a shared remote repository.
  • Branch: An independent line of work, such as a feature branch, that keeps unfinished changes off the main branch.
  • Pull request: A request to merge a branch into another. It’s where code review happens.
  • Merge: Combines the changes from one branch into another, usually after review and automated tests pass.

Keep the order straight: commit, push, open a pull request, review, then merge.

CI/CD Pipelines

A pipeline automates the path from code change to running software.

  • Continuous integration (CI): Developers merge small changes often, and every change is automatically built and tested.
  • Continuous delivery: Every change that passes the pipeline is ready to release, but a person approves the final push to production.
  • Continuous deployment: Every change that passes all stages goes to production automatically, with no manual gate.
  • Security in the pipeline: Automated steps such as code scanning, dependency checks, and secret detection catch problems before release.
  • Artifacts: The build outputs the pipeline produces and stores, such as container images, VM images, and RPM or Debian packages. They live in public or private repositories (registries).

System Integration and APIs

Cloud services communicate through APIs. Know what makes each style distinct:

  • REST: Uses standard HTTP methods (GET, POST, PUT, DELETE) against resource URLs. It’s stateless and usually exchanges JSON.
  • SOAP: A protocol with strict XML message envelopes and formal contracts (WSDL). You’ll often see it in older enterprise and financial systems.
  • RPC: Calls a function on a remote system as if it were local. gRPC is a common modern example.
  • WebSockets: Keeps a persistent, two-way connection open, which is ideal for real-time updates like chat or live dashboards.
  • GraphQL: Uses a single endpoint where the client asks for exactly the fields it needs, which reduces over-fetching.
  • Event-driven architecture: Components react to events, such as a file upload or a queue message, instead of polling. This pairs naturally with serverless functions.

The Nine DevOps Tools

  • Git: Distributed version control.
  • GitHub Actions: CI/CD workflows defined in YAML inside a GitHub repository and triggered by events like a push or pull request.
  • Jenkins: An open-source automation server widely used to run CI/CD pipelines.
  • Terraform: Declarative infrastructure as code. You describe the desired end state, and Terraform plans and applies the changes across many providers while tracking state.
  • Ansible: Agentless configuration management and automation. It connects over SSH (or WinRM for Windows) and runs YAML playbooks.
  • Docker: Builds and runs containers from images.
  • Kubernetes: Orchestrates containers across a cluster, handling scheduling, scaling, and self-healing.
  • ELK stack: Elasticsearch, Logstash, and Kibana, used together to collect, search, and visualize logs.
  • Grafana: Dashboards and visualization for metrics from sources like Prometheus, often with alerting.

Common DevOps Fundamentals Traps

  • Mixing up continuous delivery and continuous deployment. If the stem mentions a manual approval before production, it’s delivery. If nothing stops the release, it’s deployment.
  • Confusing Terraform and Ansible. Both use code, and they overlap. But when the question is about provisioning infrastructure from a declared end state, think Terraform. When it’s about configuring software on existing servers, think Ansible.
  • Treating Docker and Kubernetes as the same thing. Docker builds and runs containers. Kubernetes manages many containers across many hosts.
  • Picking ELK when the question is about metrics dashboards. ELK centers on logs. Grafana centers on visualizing metrics.
  • Assuming REST for everything. Clues like “XML envelope” point to SOAP. “Real-time, bidirectional” points to WebSockets. “Client specifies exact fields” points to GraphQL.
  • Forgetting that secrets don’t belong in source control. Committing passwords or API keys to a repository is a security failure, even if the repository is private.

Sample Scenarios

Scenario 1: Choosing the Right Pipeline Model

Consider a question where a development team wants every change merged to the main branch to be built, tested, and scanned automatically. Compliance rules require a release manager to approve each production release. The question asks which practice the team is using.

Start by naming what’s automated: build, test, and security scanning. That’s continuous integration, but the question is about the full pipeline. Next, find the detail that changes the answer: a human approves production releases. That rules out continuous deployment, which has no manual gate.

The best answer is continuous delivery. An option like “blue-green deployment” might be tempting because it’s a real release strategy, but it describes how traffic shifts between environments, not whether a human approves the release.

Scenario 2: Picking the Right Tool

Now consider a question where an administrator manages 150 Linux VMs that have drifted apart. Some have different package versions, and a few are missing a required security setting. The organization doesn’t want to install extra agent software on the servers. Which tool should the administrator use?

The VMs already exist, so this is a configuration problem, not a provisioning problem. That points away from Terraform. Docker and Kubernetes deal with containers, not VM configuration. Jenkins could run a job, but it isn’t a configuration management tool. Ansible fits best: it’s agentless, connects over SSH, and applies the same YAML playbook to every server so they match the desired configuration.

How DevOps Fundamentals Connects to Other Domains

This domain rarely stands alone. Expect it to overlap with:

  • Deployment (2.0): Objective 2.4 covers infrastructure as code, JSON and YAML, drift detection, and versioning, and 2.2 covers blue-green, canary, and rolling releases. These are what CI/CD pipelines actually run.
  • Cloud Architecture (1.0): Containers, orchestration, and image registries (1.6) and loosely coupled microservices (1.5) are the workloads DevOps teams ship.
  • Operations (3.0): Observability through logging, monitoring, and alerting (3.1) is where ELK and Grafana come in.
  • Security (4.0): Vulnerability scanning, secrets handling, and least privilege for pipeline service accounts all tie back to Domain 4.0.
  • Troubleshooting (6.0): “Outdated definitions,” “deprecation,” and “misconfigurations” in 6.1 often trace back to IaC templates or pipeline changes.

A Focused Study Plan for DevOps Fundamentals

  1. Make a one-line summary for each of the nine tools and quiz yourself until you can name the right tool from a job description.
  2. Get hands-on for an hour or two. Create a Git repository, make a branch, commit, push, and open a pull request. If you can, run a simple GitHub Actions workflow or a basic Terraform file in a free-tier account.
  3. Build a comparison sheet for REST, SOAP, RPC, WebSockets, and GraphQL, and another for continuous integration, delivery, and deployment.
  4. Practice with Pocket Prep. Use Build Your Own Quiz to focus on the DevOps Fundamentals subject, then review your Missed Questions quiz a few days later to confirm the concepts stuck.
  5. Mix it back in. Once you’re scoring well on focused sets, switch to mixed Timed Quizzes so you can spot DevOps concepts when the question doesn’t label them.

Start Preparing for the CompTIA Cloud+ Exam With Pocket Prep

DevOps Fundamentals gets much easier once the tools and terms click. Pocket Prep’s CompTIA Cloud+ practice questions cover all six domains with 630 questions, each with a detailed explanation, and a full-length mock exam for your final check. Use the Weakest Subject quiz to see whether DevOps is still holding you back. Keep at it, because this domain is very learnable.