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:
- Workload requirement: latency, availability, compliance, cost, performance, scale.
- Operational model: self-managed, provider-managed, automated, outsourced.
- Risk constraint: security, data loss, vendor lock-in, downtime, skills gap.
- Most appropriate control: preventive, detective, corrective, compensating.
- Troubleshooting signal: metric, log, trace, alert, dependency, recent change.
Cloud Models and Responsibility
Deployment Models
| Model | Use When | Watch For |
|---|
| Public cloud | Elastic demand, fast provisioning, managed services, global reach | Shared responsibility, network egress cost, provider dependency |
| Private cloud | Strong control, internal governance, predictable workloads, custom compliance needs | Higher operations burden, capacity planning, slower elasticity |
| Hybrid cloud | Gradual migration, data locality, burst capacity, legacy integration | Identity federation, routing, latency, consistent security policy |
| Multicloud | Avoid provider concentration, use best-of-breed services, regional availability | Operational complexity, inconsistent IAM/networking, data portability |
| Community cloud | Shared sector-specific requirements | Governance agreements, limited provider choice |
Service Models and Responsibility
| Model | You Manage More | Provider Manages More | Exam Cue |
|---|
| IaaS | OS, middleware, runtime, data, apps, security config | Physical facilities, hardware, virtualization layer | Need OS-level control or lift-and-shift |
| PaaS | App code, data, identity, app config | Runtime, middleware, OS, scaling platform | Developers need speed without server management |
| SaaS | Users, data governance, access policies, configuration | Application stack and infrastructure | Business function needed quickly |
| FaaS/serverless | Function code, events, permissions, data | Runtime scaling and infrastructure | Event-driven bursts, short-lived tasks |
| Containers/Kubernetes | Images, manifests, orchestration config, app networking | Depends on self-managed vs managed cluster | Portability 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
| Quality | Meaning | Design Techniques |
|---|
| Scalability | Ability to handle growth | Horizontal scaling, vertical scaling, partitioning, autoscaling |
| Elasticity | Automatic scale up/down with demand | Autoscaling groups, queues, serverless, policies |
| High availability | Service remains accessible despite failures | Redundancy, load balancing, health checks, fault domains |
| Resilience | Ability to recover and continue | Retries, failover, backups, chaos testing, DR plans |
| Portability | Ability to move workloads | Containers, standard APIs, IaC, data export plans |
| Observability | Ability to understand system state | Metrics, logs, traces, events, dashboards |
| Maintainability | Easy to patch and change | Immutable infrastructure, automation, CI/CD |
| Security by design | Controls built into architecture | Least privilege, segmentation, encryption, logging |
Compute Selection Matrix
| Option | Best Fit | Advantages | Tradeoffs |
|---|
| Virtual machines | Lift-and-shift, custom OS, long-running services | Familiar admin model, full OS control | Patch burden, slower scaling than serverless |
| Bare metal | Specialized hardware, licensing, high performance isolation | No hypervisor overhead, hardware control | Less elasticity, more operational responsibility |
| Containers | Microservices, portability, consistent runtime | Fast startup, efficient density, image-based deployment | Requires image security and orchestration knowledge |
| Managed Kubernetes | Complex container platforms, service discovery, scaling | Portable orchestration, declarative operations | Cluster complexity, networking and RBAC learning curve |
| PaaS application platform | Web/API apps without server management | Faster deployment, built-in scaling | Less OS/runtime control |
| Serverless functions | Event-driven workflows, intermittent tasks | No server management, scales to events | Execution/runtime constraints, cold starts, stateless design |
| Batch/spot/preemptible compute | Non-urgent processing, analytics, rendering | Cost-efficient for interruptible jobs | Must tolerate termination and retries |
Common Architecture Traps
| Trap | Correct 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. |
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
| Metric | Measures | Use For |
|---|
| CPU utilization | Processor demand | Rightsizing, scaling, noisy neighbor investigation |
| Memory utilization | RAM pressure | OOM troubleshooting, cache sizing |
| IOPS | Storage operations per second | Database and transactional workload planning |
| Throughput | Data transfer rate | Backups, analytics, streaming, file transfer |
| Latency | Time to complete request | User experience, database response, network path |
| Queue depth | Waiting operations | Bottleneck detection, autoscaling signal |
| Error rate | Failed requests | Reliability and incident triage |
| Saturation | Resource near limit | Capacity planning and alert thresholds |
Networking Quick Reference
Core Network Components
| Component | Role | Exam Decision Cue |
|---|
| VPC/VNet/virtual network | Isolated logical network boundary | Need segmentation and private addressing |
| Subnet | Address range inside a virtual network | Separate tiers, route domains, or availability zones |
| Route table | Determines next hop | Diagnose unreachable networks or wrong path |
| Internet gateway | Public internet connectivity | Public-facing resources need controlled ingress/egress |
| NAT gateway/instance | Private subnet outbound internet | Instances need updates without public inbound access |
| VPN | Encrypted tunnel over internet | Hybrid connectivity with moderate setup time/cost |
| Dedicated private connection | Private circuit to provider | Predictable latency, bandwidth, or compliance-driven connectivity |
| Load balancer | Distributes traffic | HA, scaling, TLS offload, health checks |
| DNS | Name resolution | Cutovers, service discovery, failover |
| CDN | Edge caching and acceleration | Static content, global users, DDoS absorption |
| WAF | Layer 7 filtering | Protect HTTP/S apps from web attacks |
| Firewall/security group | Traffic allow/deny | Enforce least-privilege network access |
Load Balancer Selection
| Type | Layer | Use When | Common Trap |
|---|
| Layer 4 | Transport | Need fast TCP/UDP distribution | Cannot inspect HTTP paths or headers |
| Layer 7 | Application | Need host/path routing, HTTP headers, TLS features | Higher processing overhead than L4 |
| Internal | Private | Service-to-service traffic | Not reachable from internet |
| External/public | Public | Internet-facing application | Must combine with WAF, TLS, and least-privilege rules |
| Global traffic manager | DNS/edge | Multi-region routing or failover | DNS caching can delay cutover |
Network Security Distinctions
| Control | Stateful? | Scope | Use For |
|---|
| Security group / instance firewall | Usually stateful | Workload or interface | Least-privilege inbound/outbound per app |
| Network ACL | Often stateless | Subnet boundary | Broad subnet-level allow/deny |
| Host firewall | Stateful or rule-based | OS instance | Defense in depth and local policy |
| WAF | Application-aware | HTTP/S | SQL injection, XSS, bot filtering |
| IDS | Detection | Network/host | Alert on suspicious activity |
| IPS | Prevention | Network/host | Block known malicious patterns |
| DDoS protection | Provider/edge | Network/application | Absorb or filter volumetric attacks |
CIDR Quick Table
| Prefix | Total IPv4 Addresses | Common Use |
|---|
| /16 | 65,536 | Large virtual network |
| /20 | 4,096 | Large subnet range |
| /24 | 256 | Common subnet size |
| /25 | 128 | Smaller subnet |
| /26 | 64 | Smaller app tier |
| /27 | 32 | Small service segment |
| /28 | 16 | Very small subnet |
Network Troubleshooting Cues
| Symptom | Likely Area | Check First |
|---|
| Private VM cannot reach internet | NAT, route table, DNS, firewall | Default route and NAT path |
| Internet users cannot reach app | Public IP, DNS, security rules, load balancer | DNS target and inbound allow rule |
| One subnet cannot reach another | Route table, NACL, peering, firewall | Routes and bidirectional rules |
| TLS errors | Certificate, hostname, cipher, expiration | Certificate chain and CN/SAN |
| Intermittent failures | Health checks, scaling events, DNS TTL, overloaded backend | Load balancer target health |
| High latency | Region distance, routing, saturation, DNS, database | Trace path and service metrics |
Storage and Data Services
Storage Selection Matrix
| Storage Type | Access Pattern | Best For | Avoid When |
|---|
| Object storage | API over HTTP, whole-object operations | Backups, logs, static assets, data lakes | Need low-latency block semantics |
| Block storage | Attached disk volumes | Databases, VM boot disks, transactional workloads | Need shared multi-client file semantics |
| File storage | Shared filesystem | Lift-and-shift apps, shared content, home directories | Need massive object-scale metadata model |
| Archive/cold storage | Rare retrieval | Long-term retention, compliance archives | Need immediate restore |
| Ephemeral storage | Temporary local storage | Cache, scratch data | Data must survive instance loss |
| Managed relational DB | SQL, transactions, schema | OLTP, referential integrity | Highly variable unstructured data |
| NoSQL/key-value/document | Flexible schema, scale-out | Low-latency lookups, high scale, semi-structured data | Complex joins and strict relational constraints |
| Cache | In-memory reads | Session acceleration, read-heavy apps | Source of truth data |
| Data warehouse | Analytical queries | BI and reporting | High-frequency transactional writes |
| Stream/message service | Event ingestion | Decoupling, buffering, async processing | Synchronous request/response only |
Data Protection Concepts
| Concept | Meaning | Exam Cue |
|---|
| Snapshot | Point-in-time copy of volume/object state | Fast restore or clone |
| Backup | Managed copy with retention and recovery process | Recover from deletion, corruption, ransomware |
| Replication | Copy data to another location | HA, read locality, DR |
| Synchronous replication | Write confirmed after remote copy | Lower RPO, higher latency |
| Asynchronous replication | Remote copy happens after local write | Better latency, possible data loss window |
| Versioning | Preserve object/file versions | Protect against overwrite/delete |
| Immutability/WORM | Prevent modification for retention period | Tamper resistance |
| Lifecycle policy | Move/delete data by age or class | Cost optimization and retention governance |
| Encryption at rest | Protect stored data | Disks, objects, databases, backups |
| Encryption in transit | Protect network traffic | TLS, VPN, encrypted service endpoints |
| Requirement | Likely Choice |
|---|
| Low-latency database writes | Provisioned or performance-oriented block storage |
| Shared POSIX-style access | Managed file storage |
| Static website content | Object storage plus CDN |
| Long-term low-access retention | Archive storage with lifecycle policy |
| High read repetition | Cache layer or CDN |
| Decouple producers and consumers | Queue or stream service |
| Analytics over large files | Object storage data lake plus analytics engine |
Identity, Security, and Governance
IAM Terms That Drive Scenario Answers
| Term | Meaning | Best Practice |
|---|
| Principal | User, service, workload, or federated identity | Assign only required access |
| Role | Assumable identity with permissions | Prefer roles for workloads and temporary access |
| Policy | Permission definition | Scope actions, resources, and conditions |
| Group | Collection of users | Assign permissions to groups, not individuals |
| Federation | Trust external identity provider | Use for SSO and centralized identity |
| MFA | Additional authentication factor | Enforce for privileged and remote access |
| Least privilege | Minimum required access | Start narrow and expand only with justification |
| Separation of duties | Split conflicting responsibilities | Reduce fraud and admin misuse |
| Just-in-time access | Temporary privilege elevation | Limit standing admin rights |
| Break-glass account | Emergency access | Protect, monitor, and test carefully |
Access Control Models
| Model | Basis | Use When |
|---|
| RBAC | Job role | Standard enterprise permissions |
| ABAC | Attributes such as department, tag, location | Dynamic, large-scale policy decisions |
| DAC | Owner-defined permissions | Collaborative file/resource ownership |
| MAC | Central classification labels | High-control environments |
| Policy-based access | Rules and conditions | Cloud IAM, network policy, zero trust |
Security Control Selection
| Need | Prefer |
|---|
| Prevent public object exposure | Resource policy, block public access, least privilege |
| Protect secrets in automation | Secrets manager or vault, not hardcoded variables |
| Encrypt disks and backups | Managed keys or customer-managed keys |
| Protect keys with stronger isolation | HSM-backed key management |
| Detect unauthorized changes | Configuration monitoring and audit logs |
| Prevent drift from approved configs | Policy-as-code and IaC enforcement |
| Segment application tiers | Subnets, security groups, microsegmentation |
| Protect web application | WAF, secure coding, TLS, logging |
| Protect admin access | MFA, bastion or privileged access workflow, JIT |
| Investigate incident | Preserve logs, snapshots, timelines, and chain of custody procedures |
Encryption and Key Management
| Concept | High-Yield Point |
|---|
| Symmetric encryption | Same key encrypts/decrypts; efficient for bulk data |
| Asymmetric encryption | Public/private key pair; useful for exchange and signatures |
| Hashing | One-way integrity check; not encryption |
| Salting | Adds randomness to password hashes |
| TLS | Protects data in transit and authenticates endpoint identity |
| KMS | Central service for creating, storing, rotating, and auditing keys |
| HSM | Hardware-backed key protection for stronger isolation |
| BYOK | Customer supplies key material to provider-managed KMS |
| Key rotation | Limits exposure period; plan app compatibility |
| Envelope encryption | Data key encrypts data; master key encrypts data key |
Shared Responsibility Traps
| Scenario Phrase | Likely Responsibility |
|---|
| Misconfigured public storage bucket | Customer |
| Unpatched guest OS on IaaS VM | Customer |
| Physical data center access control | Provider |
| Hypervisor infrastructure security | Provider |
| IAM policy grants excessive access | Customer |
| SaaS user access review | Customer |
| Managed database engine patching | Often provider, but configuration and data remain customer responsibility |
| Application vulnerability in custom code | Customer |
Automation, DevOps, and Deployment
| Tool/Pattern | Use For | Exam Cue |
|---|
| IaC | Declarative infrastructure provisioning | Repeatable environments, version control |
| Configuration management | OS/app package and setting enforcement | Manage desired state across servers |
| CI/CD pipeline | Build, test, scan, deploy | Reduce manual release risk |
| Image pipeline | Create hardened VM/container images | Immutable deployments |
| Policy-as-code | Enforce governance automatically | Prevent noncompliant resources |
| Runbooks | Documented operational tasks | Standard response steps |
| Playbooks | Automated or semi-automated incident actions | Repeatable remediation |
| GitOps | Git as desired state source | Kubernetes/platform operations |
| API/SDK automation | Programmatic cloud operations | Custom workflows and integrations |
Deployment Strategies
| Strategy | How It Works | Best For | Risk |
|---|
| Rolling | Replace instances gradually | Routine low-risk releases | Mixed versions during rollout |
| Blue/green | Switch traffic from old to new environment | Fast rollback, low downtime | Duplicate environment cost |
| Canary | Send small traffic percentage to new version | Detect issues before full rollout | Requires metrics and routing control |
| A/B | Compare user experience/behavior | Product experiments | Not primarily a reliability strategy |
| Recreate | Stop old, start new | Simple apps or maintenance windows | Downtime |
| Immutable | Replace, do not modify in place | Consistency and drift reduction | Requires image/build discipline |
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:
| Concept | Purpose |
|---|
| Pod | Smallest deployable unit; one or more containers |
| Deployment | Declarative desired state for replicated pods |
| ReplicaSet | Maintains pod replica count, usually managed by Deployment |
| Service | Stable network endpoint for pods |
| Ingress | HTTP/S routing into services |
| ConfigMap | Nonsecret configuration |
| Secret | Sensitive configuration; still requires access control and encryption |
| Namespace | Logical separation inside cluster |
| NetworkPolicy | Pod-level traffic control |
| PersistentVolume | Storage 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
| Signal | Answers | Examples |
|---|
| Metrics | What is happening numerically? | CPU, latency, error rate, queue depth |
| Logs | What event occurred? | Auth failures, application exceptions |
| Traces | Where did a request spend time? | Service-to-service call latency |
| Events | What changed? | Deployment, scale action, failover |
| Synthetic checks | Is service reachable from user perspective? | Health probes, transactions |
| Audit logs | Who did what and when? | IAM changes, resource deletion |
SLI, SLO, and SLA
| Term | Meaning | Exam Cue |
|---|
| SLI | Measured reliability indicator | Latency percentile, error rate, availability |
| SLO | Internal target for SLI | Engineering reliability goal |
| SLA | Formal service commitment | Contract or customer-facing commitment |
Troubleshooting Method
- Identify symptoms and scope.
- Determine what changed recently.
- Check health dashboards, logs, metrics, and alerts.
- Test dependencies: DNS, network path, IAM, storage, database, external services.
- Form and test one hypothesis at a time.
- Apply least-risk fix first when production is affected.
- Validate service recovery.
- Document root cause and preventive action.
Symptom-to-Cause Table
| Symptom | Likely Causes | Useful Checks |
|---|
| Instance cannot start | Capacity, quota, image, permissions, boot disk | Activity logs, instance console, image ID, IAM |
| App returns 403 | IAM, bucket policy, WAF, auth token | Access logs, policy simulation, identity context |
| App returns 500 | App bug, dependency failure, config, secret issue | App logs, recent deployment, dependency health |
| High database latency | Storage IOPS, locks, connection saturation, missing index | DB metrics, slow queries, connection count |
| Pod crash loop | Bad config, failed health check, missing secret, image error | kubectl describe, logs, events |
| Autoscaling not triggered | Wrong metric, cooldown, min/max bounds, missing permissions | Scaling policy and metric source |
| Backup restore fails | Corrupt backup, missing key, wrong region/account, permission issue | Restore logs, key access, backup metadata |
| Users see stale content | CDN cache, DNS cache, browser cache | Cache headers, invalidation, TTL |
| Sudden cost spike | Egress, runaway scaling, large logs, orphaned resources | Cost reports, tags, recent changes |
Resilience, Backup, and Disaster Recovery
RTO and RPO
| Term | Meaning | Design Impact |
|---|
| RTO | Maximum acceptable time to restore service | Determines standby and automation level |
| RPO | Maximum acceptable data loss | Determines backup/replication frequency |
| MTTR | Mean time to repair/recover | Improved by automation and runbooks |
| MTBF | Mean time between failures | Improved 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
| Type | Description | Tradeoff |
|---|
| Full | Complete copy | Simplest restore, highest storage/time |
| Incremental | Changes since last backup | Efficient, restore may need chain |
| Differential | Changes since last full backup | Faster restore than long incremental chain |
| Snapshot | Point-in-time state | Fast, but needs retention and isolation planning |
| Application-consistent | App flushed/quiesced before backup | Better for databases and transactional apps |
| Crash-consistent | Disk state as if power loss occurred | Faster, may require app recovery |
DR Strategy Selection
| Strategy | Cost/Complexity | Recovery Speed | Use When |
|---|
| Backup and restore | Low | Slowest | Lowest cost, longer outage acceptable |
| Pilot light | Low-medium | Moderate | Core services ready, scale after disaster |
| Warm standby | Medium | Faster | Reduced-size environment always running |
| Active/passive | Medium-high | Fast | Standby ready for failover |
| Active/active | High | Fastest | Traffic served from multiple sites/regions |
Resilience Design Checklist
| Requirement | Design Response |
|---|
| Single instance failure tolerance | Multiple instances behind load balancer |
| Zone failure tolerance | Deploy across availability zones/fault domains |
| Region failure tolerance | Cross-region DR or active/active design |
| Database failure tolerance | Replication, backups, tested failover |
| Accidental deletion protection | Versioning, soft delete, backup isolation |
| Ransomware resilience | Immutable backups, least privilege, offline/isolated copies |
| Traffic surge resilience | Autoscaling, CDN, queue-based buffering |
| Dependency failure resilience | Timeouts, retries with backoff, circuit breakers |
Migration and Modernization
Migration Strategies
| Strategy | Meaning | Use When |
|---|
| Rehost | Move as-is to IaaS | Fast migration, minimal app change |
| Replatform | Minor changes to use managed platform | Reduce ops without full redesign |
| Refactor | Redesign app architecture | Need scalability, resilience, or cloud-native benefits |
| Repurchase | Replace with SaaS | Commodity business function |
| Retain | Keep in current environment | Dependency, cost, or timing constraint |
| Retire | Decommission | No longer needed |
Migration Planning Reference
| Step | Key Activities |
|---|
| Discover | Inventory apps, data, dependencies, licenses, owners |
| Assess | Classify criticality, sensitivity, performance, compliance needs |
| Design | Choose landing zone, network, IAM, monitoring, migration pattern |
| Pilot | Migrate low-risk workload first |
| Replicate | Sync data and validate integrity |
| Cut over | Freeze changes, redirect traffic, monitor |
| Validate | Functional, performance, security, and backup checks |
| Optimize | Rightsize, automate, improve resilience |
| Decommission | Shut down old systems after validation |
Data Migration Options
| Option | Use When | Watch For |
|---|
| Online replication | Minimal downtime required | Consistency, bandwidth, lag |
| Offline transfer | Very large datasets or constrained network | Chain of custody, encryption, import validation |
| Database dump/restore | Simple database migration | Downtime and version compatibility |
| Change data capture | Need continuous sync before cutover | Complexity and conflict handling |
| Object copy/sync | File/object migrations | Metadata, permissions, versioning |
Cost Management and Optimization
Cost Drivers
| Driver | Examples | Control |
|---|
| Compute runtime | Always-on VMs, oversized instances | Rightsize, autoscale, schedule shutdown |
| Storage volume | Unused disks, old snapshots, hot-tier data | Lifecycle policy, cleanup, tiering |
| Data transfer | Internet egress, cross-region replication | Architecture review, caching, locality |
| Managed services | Databases, observability, security tools | Match tier to requirement |
| Logging/metrics | Excessive retention or high-cardinality metrics | Retention policy, sampling, filtering |
| Orphaned resources | Detached disks, unused IPs, stale load balancers | Tagging, inventory, automated cleanup |
Governance Controls
| Control | Purpose |
|---|
| Tags/labels | Ownership, cost allocation, automation scope |
| Budgets/alerts | Detect spending anomalies early |
| Quotas/limits | Prevent runaway provisioning |
| Resource policies | Restrict regions, instance types, public access |
| Landing zone | Standardized account/subscription/project foundation |
| Change management | Approve and track production changes |
| Configuration baseline | Define secure required settings |
| Audit logging | Support investigations and compliance evidence |
| Showback/chargeback | Make consumption visible to teams |
Cost Optimization Traps
| Trap | Better 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
| Phase | Cloud-Focused Actions |
|---|
| Preparation | Logging, IAM baselines, runbooks, contacts, backups |
| Identification | Alerts, anomaly detection, user reports, audit review |
| Containment | Disable credentials, isolate instances, block traffic |
| Eradication | Remove malware, fix misconfigurations, patch vulnerabilities |
| Recovery | Restore services, rotate secrets, validate integrity |
| Lessons learned | Root cause, control improvements, documentation updates |
Cloud Forensics Considerations
| Need | Action |
|---|
| Preserve evidence | Snapshot disks, export logs, document timestamps |
| Avoid contamination | Do not log into compromised hosts unnecessarily |
| Maintain access history | Preserve audit logs and IAM events |
| Investigate network activity | Review flow logs, firewall logs, load balancer logs |
| Investigate identity misuse | Review token use, role assumption, MFA events |
| Restore trust | Rebuild 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.