CV0-004 — CompTIA Cloud+ Cheat Sheet

CV0-004 questions often test best-fit choices, not definitions alone. When reading a scenario, identify:

1. Workload requirement: latency, availability, compliance, cost, performance, scale.

2. Operational model: self-managed, provider-managed, automated, outsourced.

3. Risk constraint: security, data loss, vendor lock-in, downtime, skills gap.

4. Most appropriate control: preventive, detective, corrective, compensating.

5. Troubleshooting signal: metric, log, trace, alert, dependency, recent change.

6. Skim the tables first. Mark any row where you hesitate.

7. Drill weak topics immediately. Use topic drills for networking, IAM, storage, monitoring, or troubleshooting rather than taking only full mock exams.

8. Practice decision-making, not memorization. CV0-004 scenarios often ask for the best action, most likely cause, or most appropriate design control.

9. Read detailed explanations. The explanation is where you learn why tempting distractors are wrong.

10. Retake mixed questions. Cloud architecture, security, and operations overlap heavily; mixed practice exposes gaps better than isolated review alone.

Exam reminder: Always verify the current CompTIA exam objectives for CompTIA Cloud+ (CV0-004). This page is an IT Mastery quick-review support and does not claim affiliation with CompTIA.

Service Models and Responsibility

Trap: “Cloud provider manages security” is incomplete. The provider secures the cloud infrastructure; the customer still secures identities, data, configurations, and workload access.

Service Models

Deployment Models

Shared Responsibility Traps

Compute Selection Matrix

Common Architecture Traps

Performance Troubleshooting Cues

Scaling Rules

Common mistake: Scaling the web tier when the real bottleneck is the database, storage, DNS, or external API.

Load Balancer Selection

Network Security Distinctions

CIDR Quick Table

Network Troubleshooting Cues

Core Cloud Networking Concepts

CIDR Review

Number of addresses in an IPv4 CIDR block:

Provider-reserved addresses may reduce usable host addresses. On the exam, focus on whether the subnet is large enough, whether routes are correct, and whether public/private exposure matches the design.

Network Troubleshooting Decision Points

Common Networking Traps

• Confusing authentication failure with network failure.
• Opening security groups too broadly instead of fixing the precise source/port rule.
• Forgetting return traffic behavior for stateless network controls.
• Creating overlapping CIDR ranges in hybrid or multi-cloud designs.
• Assuming a private subnet is private just because it has a private IP; routing determines exposure.
• Forgetting that load balancers need healthy targets and correct listener-to-target mappings.

Data Protection Concepts

Storage Performance Cues

Storage Types

Data Protection Controls

Database Selection

Common mistake: choosing a database because it is “cloud-native” without matching consistency, latency, query pattern, operational skill, backup, and recovery requirements.

Access Control Models

Security Control Selection

Encryption and Key Management

Shared Responsibility Traps

IAM Concepts

Security Control Categories

Encryption and Key Management

Cloud Security Mistakes

Deployment Strategies

Terraform-Style IaC Workflow

terraform init
terraform fmt -check
terraform validate
terraform plan -out=tfplan
terraform apply tfplan
terraform state list

High-yield points:

• Plan before apply to review intended changes.
• State files are sensitive because they can contain resource details and secrets.
• Use remote state locking in teams to prevent concurrent changes.
• Do not manually change cloud resources if IaC owns them; this creates drift.

Kubernetes Operations Snippets

kubectl get nodes
kubectl get pods -A
kubectl describe pod <pod-name>
kubectl logs <pod-name>
kubectl exec -it <pod-name> -- /bin/sh
kubectl rollout status deployment/<deployment-name>
kubectl rollout undo deployment/<deployment-name>

Common Kubernetes distinctions:

Minimal deployment concept:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: example/web:stable
          ports:
            - containerPort: 8080

Infrastructure as Code

CI/CD Pipeline Review

Deployment Strategies

Common trap: A canary release is not useful unless monitoring can detect bad behavior quickly and rollback is prepared.

SLI, SLO, and SLA

Troubleshooting Method

1. Identify symptoms and scope.
2. Determine what changed recently.
3. Check health dashboards, logs, metrics, and alerts.
4. Test dependencies: DNS, network path, IAM, storage, database, external services.
5. Form and test one hypothesis at a time.
6. Apply least-risk fix first when production is affected.
7. Validate service recovery.
8. Document root cause and preventive action.

Symptom-to-Cause Table

Metrics, Logs, and Traces

Monitoring Priorities

Alerting Mistakes

• Alerting on every event instead of actionable symptoms.
• No escalation path or runbook.
• Thresholds that are too static for elastic workloads.
• Missing synthetic checks for user-facing availability.
• Ignoring deployment events when diagnosing new incidents.
• No suppression or maintenance window plan, causing alert fatigue.

Troubleshooting Method for CV0-004 Scenarios

Use a disciplined sequence instead of jumping to the most dramatic fix.

1. Identify the symptom. What is broken: access, performance, deployment, security, cost, or availability?
2. Confirm scope. One user, one subnet, one region, one service, or global?
3. Check recent changes. Deployments, policy changes, certificate rotations, scaling events, route updates.
4. Review evidence. Logs, metrics, traces, health checks, audit events.
5. Test the simplest likely layer. DNS, identity, routing, firewall, service health, dependency status.
6. Apply least-disruptive fix. Prefer targeted rollback, rule correction, or scaling action over broad access changes.
7. Validate resolution. Confirm user impact and monitoring.
8. Document and prevent recurrence. Update runbooks, automation, alerts, or controls.

Scenario-to-Cause Quick Table

Trap: Low RPO does not automatically mean low RTO. Replicated data can still take time to promote, reconnect, validate, and secure.

Backup Types

DR Strategy Selection

Resilience Design Checklist

DR Patterns

Backup Review Checklist

• Define RPO and RTO before selecting technology.
• Back up data, configuration, IaC templates, keys, and critical metadata where appropriate.
• Protect backups from deletion or encryption by attackers.
• Store backups separately from the primary failure domain.
• Test restoration, not just backup completion.
• Monitor failed backup jobs and replication lag.
• Document who can declare disaster recovery and who can execute failover.

Migration Planning Reference

Data Migration Options

Governance Controls

Cost Optimization Traps

Final Review Checklist

Before you move into full mock exams, confirm that you can explain:

• The shared responsibility differences among IaaS, PaaS, SaaS, containers, and serverless.
• When to use public, private, hybrid, and multi-cloud models.
• How load balancing, health checks, autoscaling, and redundancy support availability.
• The difference between RTO and RPO.
• Object vs. block vs. file vs. archive storage.
• How IAM roles, federation, MFA, secrets management, and least privilege work together.
• How routing, NAT, VPN, DNS, security groups, and network ACLs affect connectivity.
• How CI/CD, IaC, immutable deployment, and drift detection reduce operational risk.
• How to interpret metrics, logs, traces, and audit events.
• How to troubleshoot performance, access, deployment, security, and cost scenarios.
• How tagging, lifecycle policies, budgets, and rightsizing support cost management.
• How backups, replication, and restore testing support resilience.

Availability Calculations to Remember

For serial dependencies, combined availability is the product of component availability:

For redundant parallel components where either component can keep the service running:

High-yield point: do not add availability percentages. A design with multiple required components can have lower end-to-end availability than any single component unless redundancy is built correctly.

RTO vs. RPO

Common trap: A low RTO does not automatically mean a low RPO. You can restore quickly and still lose too much data if replication or backup frequency is inadequate.

Placement Decision Rules

Container Exam Traps

Serverless Review Points

• Functions should be stateless; durable state belongs in managed storage or databases.
• Permissions should be least privilege; avoid broad function roles.
• Event source, retry behavior, dead-letter queues, and idempotency matter.
• Cold starts affect latency-sensitive workloads.
• Logs, traces, and correlation IDs are important because there is no traditional server to inspect.

Cost Optimization Decision Points

Trap: Cheapest unit price is not always lowest total cost. Factor operations, data transfer, resilience, performance, and licensing.

Avoid broad “allow all,” shared admin accounts, hardcoded secrets, disabling controls, or relying on one layer.

When the Question Asks for Availability

Prefer answers that include:

• Multi-zone or multi-region design where justified
• Load balancing and health checks
• Autoscaling
• Replication
• Backup and restore testing
• Removal of single points of failure
• Documented failover runbooks

Avoid answers that only increase instance size if the issue is fault tolerance.

When the Question Asks for Performance

Prefer first identifying the bottleneck:

• Compute saturation
• Memory pressure
• Storage IOPS/latency
• Database query or locking issue
• Network latency
• DNS or external dependency
• Queue backlog
• Rate limiting

Avoid scaling everything at once unless the scenario clearly indicates broad capacity exhaustion.

When the Question Asks for Cost

Prefer:

• Rightsizing
• Autoscaling
• Scheduling nonproduction resources
• Lifecycle policies
• Reserved/committed capacity for predictable workloads
• Tagging and budgets
• Removing orphaned resources

Avoid reducing redundancy or disabling security unless the question explicitly frames a nonproduction or low-risk case and provides adequate controls.