CV0-004 — CompTIA Cloud+ (CV0-004) Exam Quick Reference

Compact reference for CompTIA Cloud+ (CV0-004) cloud architecture, security, networking, automation, resilience, operations, and troubleshooting.

How to Use This Quick Reference

This Quick Reference supports independent preparation for the CompTIA Cloud+ (CV0-004) exam. Use it to review high-yield decision points, compare cloud technologies, and practice scenario reasoning.

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.

Cloud Models and Responsibility

Deployment Models

ModelUse WhenWatch For
Public cloudElastic demand, fast provisioning, managed services, global reachShared responsibility, network egress cost, provider dependency
Private cloudStrong control, internal governance, predictable workloads, custom compliance needsHigher operations burden, capacity planning, slower elasticity
Hybrid cloudGradual migration, data locality, burst capacity, legacy integrationIdentity federation, routing, latency, consistent security policy
MulticloudAvoid provider concentration, use best-of-breed services, regional availabilityOperational complexity, inconsistent IAM/networking, data portability
Community cloudShared sector-specific requirementsGovernance agreements, limited provider choice

Service Models and Responsibility

ModelYou Manage MoreProvider Manages MoreExam Cue
IaaSOS, middleware, runtime, data, apps, security configPhysical facilities, hardware, virtualization layerNeed OS-level control or lift-and-shift
PaaSApp code, data, identity, app configRuntime, middleware, OS, scaling platformDevelopers need speed without server management
SaaSUsers, data governance, access policies, configurationApplication stack and infrastructureBusiness function needed quickly
FaaS/serverlessFunction code, events, permissions, dataRuntime scaling and infrastructureEvent-driven bursts, short-lived tasks
Containers/KubernetesImages, manifests, orchestration config, app networkingDepends on self-managed vs managed clusterPortability and microservices

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

Workload Placement Decision Path

    flowchart TD
	    A[New or migrating workload] --> B{Strict data locality or legacy dependency?}
	    B -->|Yes| C[Hybrid or private placement]
	    B -->|No| D{Need OS/kernel customization?}
	    D -->|Yes| E[IaaS VM or bare metal]
	    D -->|No| F{Containerized microservice?}
	    F -->|Yes| G[Managed Kubernetes or container platform]
	    F -->|No| H{Event-driven short task?}
	    H -->|Yes| I[FaaS/serverless]
	    H -->|No| J{Standard business application?}
	    J -->|Yes| K[SaaS if fit exists]
	    J -->|No| L[PaaS or managed service]

Architecture and Design Reference

Cloud Design Qualities

QualityMeaningDesign Techniques
ScalabilityAbility to handle growthHorizontal scaling, vertical scaling, partitioning, autoscaling
ElasticityAutomatic scale up/down with demandAutoscaling groups, queues, serverless, policies
High availabilityService remains accessible despite failuresRedundancy, load balancing, health checks, fault domains
ResilienceAbility to recover and continueRetries, failover, backups, chaos testing, DR plans
PortabilityAbility to move workloadsContainers, standard APIs, IaC, data export plans
ObservabilityAbility to understand system stateMetrics, logs, traces, events, dashboards
MaintainabilityEasy to patch and changeImmutable infrastructure, automation, CI/CD
Security by designControls built into architectureLeast privilege, segmentation, encryption, logging

Compute Selection Matrix

OptionBest FitAdvantagesTradeoffs
Virtual machinesLift-and-shift, custom OS, long-running servicesFamiliar admin model, full OS controlPatch burden, slower scaling than serverless
Bare metalSpecialized hardware, licensing, high performance isolationNo hypervisor overhead, hardware controlLess elasticity, more operational responsibility
ContainersMicroservices, portability, consistent runtimeFast startup, efficient density, image-based deploymentRequires image security and orchestration knowledge
Managed KubernetesComplex container platforms, service discovery, scalingPortable orchestration, declarative operationsCluster complexity, networking and RBAC learning curve
PaaS application platformWeb/API apps without server managementFaster deployment, built-in scalingLess OS/runtime control
Serverless functionsEvent-driven workflows, intermittent tasksNo server management, scales to eventsExecution/runtime constraints, cold starts, stateless design
Batch/spot/preemptible computeNon-urgent processing, analytics, renderingCost-efficient for interruptible jobsMust tolerate termination and retries

Common Architecture Traps

TrapCorrect Thinking
“Autoscaling equals high availability”Autoscaling handles demand; HA requires redundancy across failure domains.
“Snapshot equals backup”A snapshot can support backup, but backups need retention, isolation, recovery testing, and access controls.
“Serverless means no operations”You still manage code, IAM, events, secrets, observability, and costs.
“Multicloud automatically improves resilience”It can, but adds identity, networking, data synchronization, and operations complexity.
“More regions always means better design”Use regions when requirements justify latency, availability, residency, or DR complexity.

Availability, Capacity, and Performance Formulas

Use formulas for relative reasoning; provider-specific SLAs and limits vary.

Availability of Dependent Components

For components that must all work:

\[ A_{series}=A_1 \times A_2 \times \cdots \times A_n \]

For redundant alternatives where either component can serve traffic:

\[ A_{parallel}=1-\left((1-A_1)\times(1-A_2)\times\cdots\times(1-A_n)\right) \]

IPv4 Subnet Size

\[ \text{Total addresses}=2^{(32-\text{prefix length})} \]

Cloud providers may reserve addresses in a subnet, so do not assume every address is usable.

High-Yield Metrics

MetricMeasuresUse For
CPU utilizationProcessor demandRightsizing, scaling, noisy neighbor investigation
Memory utilizationRAM pressureOOM troubleshooting, cache sizing
IOPSStorage operations per secondDatabase and transactional workload planning
ThroughputData transfer rateBackups, analytics, streaming, file transfer
LatencyTime to complete requestUser experience, database response, network path
Queue depthWaiting operationsBottleneck detection, autoscaling signal
Error rateFailed requestsReliability and incident triage
SaturationResource near limitCapacity planning and alert thresholds

Networking Quick Reference

Core Network Components

ComponentRoleExam Decision Cue
VPC/VNet/virtual networkIsolated logical network boundaryNeed segmentation and private addressing
SubnetAddress range inside a virtual networkSeparate tiers, route domains, or availability zones
Route tableDetermines next hopDiagnose unreachable networks or wrong path
Internet gatewayPublic internet connectivityPublic-facing resources need controlled ingress/egress
NAT gateway/instancePrivate subnet outbound internetInstances need updates without public inbound access
VPNEncrypted tunnel over internetHybrid connectivity with moderate setup time/cost
Dedicated private connectionPrivate circuit to providerPredictable latency, bandwidth, or compliance-driven connectivity
Load balancerDistributes trafficHA, scaling, TLS offload, health checks
DNSName resolutionCutovers, service discovery, failover
CDNEdge caching and accelerationStatic content, global users, DDoS absorption
WAFLayer 7 filteringProtect HTTP/S apps from web attacks
Firewall/security groupTraffic allow/denyEnforce least-privilege network access

Load Balancer Selection

TypeLayerUse WhenCommon Trap
Layer 4TransportNeed fast TCP/UDP distributionCannot inspect HTTP paths or headers
Layer 7ApplicationNeed host/path routing, HTTP headers, TLS featuresHigher processing overhead than L4
InternalPrivateService-to-service trafficNot reachable from internet
External/publicPublicInternet-facing applicationMust combine with WAF, TLS, and least-privilege rules
Global traffic managerDNS/edgeMulti-region routing or failoverDNS caching can delay cutover

Network Security Distinctions

ControlStateful?ScopeUse For
Security group / instance firewallUsually statefulWorkload or interfaceLeast-privilege inbound/outbound per app
Network ACLOften statelessSubnet boundaryBroad subnet-level allow/deny
Host firewallStateful or rule-basedOS instanceDefense in depth and local policy
WAFApplication-awareHTTP/SSQL injection, XSS, bot filtering
IDSDetectionNetwork/hostAlert on suspicious activity
IPSPreventionNetwork/hostBlock known malicious patterns
DDoS protectionProvider/edgeNetwork/applicationAbsorb or filter volumetric attacks

CIDR Quick Table

PrefixTotal IPv4 AddressesCommon Use
/1665,536Large virtual network
/204,096Large subnet range
/24256Common subnet size
/25128Smaller subnet
/2664Smaller app tier
/2732Small service segment
/2816Very small subnet

Network Troubleshooting Cues

SymptomLikely AreaCheck First
Private VM cannot reach internetNAT, route table, DNS, firewallDefault route and NAT path
Internet users cannot reach appPublic IP, DNS, security rules, load balancerDNS target and inbound allow rule
One subnet cannot reach anotherRoute table, NACL, peering, firewallRoutes and bidirectional rules
TLS errorsCertificate, hostname, cipher, expirationCertificate chain and CN/SAN
Intermittent failuresHealth checks, scaling events, DNS TTL, overloaded backendLoad balancer target health
High latencyRegion distance, routing, saturation, DNS, databaseTrace path and service metrics

Storage and Data Services

Storage Selection Matrix

Storage TypeAccess PatternBest ForAvoid When
Object storageAPI over HTTP, whole-object operationsBackups, logs, static assets, data lakesNeed low-latency block semantics
Block storageAttached disk volumesDatabases, VM boot disks, transactional workloadsNeed shared multi-client file semantics
File storageShared filesystemLift-and-shift apps, shared content, home directoriesNeed massive object-scale metadata model
Archive/cold storageRare retrievalLong-term retention, compliance archivesNeed immediate restore
Ephemeral storageTemporary local storageCache, scratch dataData must survive instance loss
Managed relational DBSQL, transactions, schemaOLTP, referential integrityHighly variable unstructured data
NoSQL/key-value/documentFlexible schema, scale-outLow-latency lookups, high scale, semi-structured dataComplex joins and strict relational constraints
CacheIn-memory readsSession acceleration, read-heavy appsSource of truth data
Data warehouseAnalytical queriesBI and reportingHigh-frequency transactional writes
Stream/message serviceEvent ingestionDecoupling, buffering, async processingSynchronous request/response only

Data Protection Concepts

ConceptMeaningExam Cue
SnapshotPoint-in-time copy of volume/object stateFast restore or clone
BackupManaged copy with retention and recovery processRecover from deletion, corruption, ransomware
ReplicationCopy data to another locationHA, read locality, DR
Synchronous replicationWrite confirmed after remote copyLower RPO, higher latency
Asynchronous replicationRemote copy happens after local writeBetter latency, possible data loss window
VersioningPreserve object/file versionsProtect against overwrite/delete
Immutability/WORMPrevent modification for retention periodTamper resistance
Lifecycle policyMove/delete data by age or classCost optimization and retention governance
Encryption at restProtect stored dataDisks, objects, databases, backups
Encryption in transitProtect network trafficTLS, VPN, encrypted service endpoints

Storage Performance Cues

RequirementLikely Choice
Low-latency database writesProvisioned or performance-oriented block storage
Shared POSIX-style accessManaged file storage
Static website contentObject storage plus CDN
Long-term low-access retentionArchive storage with lifecycle policy
High read repetitionCache layer or CDN
Decouple producers and consumersQueue or stream service
Analytics over large filesObject storage data lake plus analytics engine

Identity, Security, and Governance

IAM Terms That Drive Scenario Answers

TermMeaningBest Practice
PrincipalUser, service, workload, or federated identityAssign only required access
RoleAssumable identity with permissionsPrefer roles for workloads and temporary access
PolicyPermission definitionScope actions, resources, and conditions
GroupCollection of usersAssign permissions to groups, not individuals
FederationTrust external identity providerUse for SSO and centralized identity
MFAAdditional authentication factorEnforce for privileged and remote access
Least privilegeMinimum required accessStart narrow and expand only with justification
Separation of dutiesSplit conflicting responsibilitiesReduce fraud and admin misuse
Just-in-time accessTemporary privilege elevationLimit standing admin rights
Break-glass accountEmergency accessProtect, monitor, and test carefully

Access Control Models

ModelBasisUse When
RBACJob roleStandard enterprise permissions
ABACAttributes such as department, tag, locationDynamic, large-scale policy decisions
DACOwner-defined permissionsCollaborative file/resource ownership
MACCentral classification labelsHigh-control environments
Policy-based accessRules and conditionsCloud IAM, network policy, zero trust

Security Control Selection

NeedPrefer
Prevent public object exposureResource policy, block public access, least privilege
Protect secrets in automationSecrets manager or vault, not hardcoded variables
Encrypt disks and backupsManaged keys or customer-managed keys
Protect keys with stronger isolationHSM-backed key management
Detect unauthorized changesConfiguration monitoring and audit logs
Prevent drift from approved configsPolicy-as-code and IaC enforcement
Segment application tiersSubnets, security groups, microsegmentation
Protect web applicationWAF, secure coding, TLS, logging
Protect admin accessMFA, bastion or privileged access workflow, JIT
Investigate incidentPreserve logs, snapshots, timelines, and chain of custody procedures

Encryption and Key Management

ConceptHigh-Yield Point
Symmetric encryptionSame key encrypts/decrypts; efficient for bulk data
Asymmetric encryptionPublic/private key pair; useful for exchange and signatures
HashingOne-way integrity check; not encryption
SaltingAdds randomness to password hashes
TLSProtects data in transit and authenticates endpoint identity
KMSCentral service for creating, storing, rotating, and auditing keys
HSMHardware-backed key protection for stronger isolation
BYOKCustomer supplies key material to provider-managed KMS
Key rotationLimits exposure period; plan app compatibility
Envelope encryptionData key encrypts data; master key encrypts data key

Shared Responsibility Traps

Scenario PhraseLikely Responsibility
Misconfigured public storage bucketCustomer
Unpatched guest OS on IaaS VMCustomer
Physical data center access controlProvider
Hypervisor infrastructure securityProvider
IAM policy grants excessive accessCustomer
SaaS user access reviewCustomer
Managed database engine patchingOften provider, but configuration and data remain customer responsibility
Application vulnerability in custom codeCustomer

Automation, DevOps, and Deployment

Automation Tool Selection

Tool/PatternUse ForExam Cue
IaCDeclarative infrastructure provisioningRepeatable environments, version control
Configuration managementOS/app package and setting enforcementManage desired state across servers
CI/CD pipelineBuild, test, scan, deployReduce manual release risk
Image pipelineCreate hardened VM/container imagesImmutable deployments
Policy-as-codeEnforce governance automaticallyPrevent noncompliant resources
RunbooksDocumented operational tasksStandard response steps
PlaybooksAutomated or semi-automated incident actionsRepeatable remediation
GitOpsGit as desired state sourceKubernetes/platform operations
API/SDK automationProgrammatic cloud operationsCustom workflows and integrations

Deployment Strategies

StrategyHow It WorksBest ForRisk
RollingReplace instances graduallyRoutine low-risk releasesMixed versions during rollout
Blue/greenSwitch traffic from old to new environmentFast rollback, low downtimeDuplicate environment cost
CanarySend small traffic percentage to new versionDetect issues before full rolloutRequires metrics and routing control
A/BCompare user experience/behaviorProduct experimentsNot primarily a reliability strategy
RecreateStop old, start newSimple apps or maintenance windowsDowntime
ImmutableReplace, do not modify in placeConsistency and drift reductionRequires image/build discipline

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:

ConceptPurpose
PodSmallest deployable unit; one or more containers
DeploymentDeclarative desired state for replicated pods
ReplicaSetMaintains pod replica count, usually managed by Deployment
ServiceStable network endpoint for pods
IngressHTTP/S routing into services
ConfigMapNonsecret configuration
SecretSensitive configuration; still requires access control and encryption
NamespaceLogical separation inside cluster
NetworkPolicyPod-level traffic control
PersistentVolumeStorage resource for stateful workloads

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

Monitoring, Observability, and Troubleshooting

Observability Signals

SignalAnswersExamples
MetricsWhat is happening numerically?CPU, latency, error rate, queue depth
LogsWhat event occurred?Auth failures, application exceptions
TracesWhere did a request spend time?Service-to-service call latency
EventsWhat changed?Deployment, scale action, failover
Synthetic checksIs service reachable from user perspective?Health probes, transactions
Audit logsWho did what and when?IAM changes, resource deletion

SLI, SLO, and SLA

TermMeaningExam Cue
SLIMeasured reliability indicatorLatency percentile, error rate, availability
SLOInternal target for SLIEngineering reliability goal
SLAFormal service commitmentContract or customer-facing commitment

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

SymptomLikely CausesUseful Checks
Instance cannot startCapacity, quota, image, permissions, boot diskActivity logs, instance console, image ID, IAM
App returns 403IAM, bucket policy, WAF, auth tokenAccess logs, policy simulation, identity context
App returns 500App bug, dependency failure, config, secret issueApp logs, recent deployment, dependency health
High database latencyStorage IOPS, locks, connection saturation, missing indexDB metrics, slow queries, connection count
Pod crash loopBad config, failed health check, missing secret, image errorkubectl describe, logs, events
Autoscaling not triggeredWrong metric, cooldown, min/max bounds, missing permissionsScaling policy and metric source
Backup restore failsCorrupt backup, missing key, wrong region/account, permission issueRestore logs, key access, backup metadata
Users see stale contentCDN cache, DNS cache, browser cacheCache headers, invalidation, TTL
Sudden cost spikeEgress, runaway scaling, large logs, orphaned resourcesCost reports, tags, recent changes

Resilience, Backup, and Disaster Recovery

RTO and RPO

TermMeaningDesign Impact
RTOMaximum acceptable time to restore serviceDetermines standby and automation level
RPOMaximum acceptable data lossDetermines backup/replication frequency
MTTRMean time to repair/recoverImproved by automation and runbooks
MTBFMean time between failuresImproved by reliability engineering

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

Backup Types

TypeDescriptionTradeoff
FullComplete copySimplest restore, highest storage/time
IncrementalChanges since last backupEfficient, restore may need chain
DifferentialChanges since last full backupFaster restore than long incremental chain
SnapshotPoint-in-time stateFast, but needs retention and isolation planning
Application-consistentApp flushed/quiesced before backupBetter for databases and transactional apps
Crash-consistentDisk state as if power loss occurredFaster, may require app recovery

DR Strategy Selection

StrategyCost/ComplexityRecovery SpeedUse When
Backup and restoreLowSlowestLowest cost, longer outage acceptable
Pilot lightLow-mediumModerateCore services ready, scale after disaster
Warm standbyMediumFasterReduced-size environment always running
Active/passiveMedium-highFastStandby ready for failover
Active/activeHighFastestTraffic served from multiple sites/regions

Resilience Design Checklist

RequirementDesign Response
Single instance failure toleranceMultiple instances behind load balancer
Zone failure toleranceDeploy across availability zones/fault domains
Region failure toleranceCross-region DR or active/active design
Database failure toleranceReplication, backups, tested failover
Accidental deletion protectionVersioning, soft delete, backup isolation
Ransomware resilienceImmutable backups, least privilege, offline/isolated copies
Traffic surge resilienceAutoscaling, CDN, queue-based buffering
Dependency failure resilienceTimeouts, retries with backoff, circuit breakers

Migration and Modernization

Migration Strategies

StrategyMeaningUse When
RehostMove as-is to IaaSFast migration, minimal app change
ReplatformMinor changes to use managed platformReduce ops without full redesign
RefactorRedesign app architectureNeed scalability, resilience, or cloud-native benefits
RepurchaseReplace with SaaSCommodity business function
RetainKeep in current environmentDependency, cost, or timing constraint
RetireDecommissionNo longer needed

Migration Planning Reference

StepKey Activities
DiscoverInventory apps, data, dependencies, licenses, owners
AssessClassify criticality, sensitivity, performance, compliance needs
DesignChoose landing zone, network, IAM, monitoring, migration pattern
PilotMigrate low-risk workload first
ReplicateSync data and validate integrity
Cut overFreeze changes, redirect traffic, monitor
ValidateFunctional, performance, security, and backup checks
OptimizeRightsize, automate, improve resilience
DecommissionShut down old systems after validation

Data Migration Options

OptionUse WhenWatch For
Online replicationMinimal downtime requiredConsistency, bandwidth, lag
Offline transferVery large datasets or constrained networkChain of custody, encryption, import validation
Database dump/restoreSimple database migrationDowntime and version compatibility
Change data captureNeed continuous sync before cutoverComplexity and conflict handling
Object copy/syncFile/object migrationsMetadata, permissions, versioning

Cost Management and Optimization

Cost Drivers

DriverExamplesControl
Compute runtimeAlways-on VMs, oversized instancesRightsize, autoscale, schedule shutdown
Storage volumeUnused disks, old snapshots, hot-tier dataLifecycle policy, cleanup, tiering
Data transferInternet egress, cross-region replicationArchitecture review, caching, locality
Managed servicesDatabases, observability, security toolsMatch tier to requirement
Logging/metricsExcessive retention or high-cardinality metricsRetention policy, sampling, filtering
Orphaned resourcesDetached disks, unused IPs, stale load balancersTagging, inventory, automated cleanup

Governance Controls

ControlPurpose
Tags/labelsOwnership, cost allocation, automation scope
Budgets/alertsDetect spending anomalies early
Quotas/limitsPrevent runaway provisioning
Resource policiesRestrict regions, instance types, public access
Landing zoneStandardized account/subscription/project foundation
Change managementApprove and track production changes
Configuration baselineDefine secure required settings
Audit loggingSupport investigations and compliance evidence
Showback/chargebackMake consumption visible to teams

Cost Optimization Traps

TrapBetter Answer
“Choose cheapest instance”Choose right-sized resource that meets performance and availability needs.
“Turn off redundancy to save cost”Match redundancy to business impact and RTO/RPO.
“Archive all data”Archive only data with retrieval-time tolerance.
“Autoscaling always lowers cost”It can increase cost if policies are misconfigured or demand is constant.
“Serverless is always cheaper”It depends on execution frequency, duration, memory, and integration costs.

Security Operations and Incident Response

Incident Response Phases

PhaseCloud-Focused Actions
PreparationLogging, IAM baselines, runbooks, contacts, backups
IdentificationAlerts, anomaly detection, user reports, audit review
ContainmentDisable credentials, isolate instances, block traffic
EradicationRemove malware, fix misconfigurations, patch vulnerabilities
RecoveryRestore services, rotate secrets, validate integrity
Lessons learnedRoot cause, control improvements, documentation updates

Cloud Forensics Considerations

NeedAction
Preserve evidenceSnapshot disks, export logs, document timestamps
Avoid contaminationDo not log into compromised hosts unnecessarily
Maintain access historyPreserve audit logs and IAM events
Investigate network activityReview flow logs, firewall logs, load balancer logs
Investigate identity misuseReview token use, role assumption, MFA events
Restore trustRebuild from known-good images when practical

High-Yield Exam Distinctions

If the Question Says…Think…
“Reduce operational overhead”Managed service, PaaS, SaaS, automation
“Need OS-level control”IaaS or bare metal
“Stateless, event-driven, unpredictable bursts”Serverless/FaaS
“Portable microservices”Containers and orchestration
“Strict latency to on-prem systems”Hybrid connectivity and placement
“Private outbound internet only”Private subnet plus NAT
“Users in many regions”CDN, global routing, regional placement
“Prevent credential exposure in code”Secrets manager, managed identities/roles
“Temporary admin access”JIT privilege, role assumption, MFA
“Recover from accidental deletion”Backups, versioning, soft delete
“Recover from regional outage”Cross-region DR, failover testing
“Configuration drift”IaC, configuration management, policy-as-code
“Intermittent app errors after release”Rollback, canary metrics, logs, dependency checks
“Sudden 403 errors”IAM/policy/authentication change
“Slow database writes”Storage IOPS, locks, connection pool, query design
“Cost spike after deployment”Scaling, egress, logs, orphaned resources

Final Review Checklist

Before exam day, be able to:

  • Match workloads to IaaS, PaaS, SaaS, containers, and serverless.
  • Explain shared responsibility for compute, data, IAM, and SaaS usage.
  • Choose storage by access pattern, latency, sharing, and durability needs.
  • Troubleshoot routing, DNS, NAT, VPN, load balancers, and firewalls.
  • Select IAM controls for least privilege, federation, MFA, and temporary access.
  • Compare backup, snapshot, replication, HA, and DR strategies.
  • Use RTO/RPO to select appropriate recovery designs.
  • Recognize when automation, IaC, CI/CD, and policy-as-code reduce risk.
  • Interpret metrics, logs, traces, alerts, and audit events during incidents.
  • Identify cost, governance, and compliance tradeoffs in cloud scenarios.

Practical Next Step

Use this Quick Reference to mark weak areas, then move into scenario-based practice for CompTIA Cloud+ (CV0-004). For each missed question, write down the decision cue, the tempting wrong answer, and the control or service that best satisfies the requirement.

Browse Certification Practice Tests by Exam Family