CV0-004 CompTIA Cloud+ (V4) Study Guide¶

Independent AI-assisted resource — SOURCES + OBJECTIVES CHECKED; HUMAN REVIEW PENDING. Objective coverage, citations, volatility labels, links, and exam-integrity compliance were checked on October 28, 2026. See the sources-and-objectives record. The official Cloud+ page is authoritative.

Study guide at a glance

Start here

Report an issue with CV0-004

Blueprint checked2026-10-28

Review stateSources + objectives checked — human review pending

Guide-only active reading1 hr–1 hr 30 min

Prerequisites: CompTIA recommends 2–3 years of hands-on experience as a systems administrator or cloud engineer; the objectives PDF also recommends Network+ and Server+ or equivalent knowledge. These are recommendations, not mandatory prerequisites. Practice provider-neutral requirement mapping, availability/network/compute/storage/database/cost architecture, migrations and IaC, scaling/backup/observability, IAM/data/network/container security and compliance evidence, CI/CD and event-driven integration, and layered troubleshooting across at least one cloud with translation to a second provider.

Exam essentialsRead the objective map, key distinctions, and readiness checklist.

Deep understandingWork through every domain, including decisions, failure modes, and related items.

Hands-on labsBegin with Original local IaC lifecycle exercise, then use the remaining labs to produce evidence you can inspect and explain.

Official objective domains

See the objective map in this guide

The active-reading range uses 90–130 words per minute for technical material. Labs, troubleshooting, note-taking, spaced review, and prerequisite gaps add time; it is not a total preparation promise.

Current baseline: Cloud+ V4, exam CV0-004; launched September 24, 2024
Lifecycle watch: CompTIA estimates retirement in 2027 but publishes no exact date or replacement; verify before scheduling.
Official delivery snapshot: Maximum 90 multiple-choice and performance-based questions; 90 minutes; 750/900 passing score; English and Japanese listed
Experience guidance: CompTIA recommends 2–3 years of hands-on experience as a systems administrator or cloud engineer. The objectives PDF also recommends Network+ and Server+ or equivalent knowledge; these are recommendations, not mandatory prerequisites

Refresh check — October 28, 2026¶

CompTIA still lists Cloud+ V4 / CV0-004, launched September 24, 2024, with the current objective PDF, 90-minute exam, and 750/900 passing score. Its lifecycle estimate remains “usually three years after launch” (2027); no exact retirement date or successor was published on the Cloud+ page. Treat that as a planning window and check the live page before buying a voucher.

How to use this guide¶

Cloud+ is provider-neutral, but cloud decisions are never context-neutral. Practice this reasoning loop:

translate business, workload, data, dependency, availability, security, compliance and budget requirements into measurable constraints;
select a deployment/service model and architecture, explicitly allocating shared responsibility;
provision through reviewed, repeatable configuration or infrastructure as code (IaC), with identity, network, data, secrets and rollback designed in;
observe availability, performance, security, cost and recovery evidence during normal operation and controlled failure;
troubleshoot from symptom and scope through control plane, identity, network, compute, storage, application and dependency layers; then revalidate.

Use at least one public cloud and translate each lab to a second provider or private-cloud equivalent. Record generic intent beside product terms—for example, object store with lifecycle policy, not only one vendor’s service name. Use free tiers, sandboxes or local emulators carefully, set cost alerts, remove resources, and never test against systems you do not own or have explicit authorization to administer.

About related items: A Related item: callout adds prerequisite, operational, architectural, or adjacent context that makes the current topic easier to understand. It is useful supporting knowledge, not a claim that the item appears verbatim in the published exam objectives.

Weighted objective map¶

Domain	Weight	Readiness evidence
1. Cloud architecture	23%	Choose service/deployment models, availability, network, compute, storage, database and cost patterns from requirements
2. Deployment	19%	Discover and migrate workloads, use IaC, and provision/configure resources with validation and rollback
3. Operations	17%	Manage lifecycle, scaling, backup/recovery, observability, performance, capacity and cost
4. Security	19%	Apply IAM, network/data/workload controls, vulnerability management and auditable compliance
5. DevOps fundamentals	10%	Explain source control, automation, CI/CD, orchestration, integrations and event-driven workflows
6. Troubleshooting	12%	Isolate deployment, network, identity, time/name-service, resource and configuration faults systematically

CURRENT BLUEPRINT: The public CV0-004 objectives PDF, document version 5.0 expands 31 main-page summary rows into 33 numbered objectives, grouped 11/5/4/6/4/3. Find it through CompTIA’s resource portal. Document 5.0 and exam V4 are different identifiers.

Published IDs	Coverage and evidence
1.1–1.4	Service models, availability, networking, storage
1.5–1.8	Cloud-native design, containers, virtualization, costs
1.9–1.11	Databases, optimization, evolving AI/ML and IoT technologies
2.1–2.5	Deployment models/strategies, migration, code, provisioning
3.1–3.4	Observability, scaling, backup/recovery, lifecycle
4.1–4.3	Vulnerabilities, compliance, identity/access
4.4–4.6	Security practices, controls, suspicious activity
5.1–5.4	Source control, CI/CD, integrations, DevOps tools
6.1–6.3	Deployment, network and security troubleshooting

Use the full outline when checking older courses: AI/IoT and community cloud are explicit scope, even though the main-page summary does not enumerate every topic.

1. Cloud architecture — 23%¶

Service, deployment and responsibility models¶

IaaS exposes virtual compute, network and storage while the customer manages more of the operating system and workload. PaaS manages more runtime and platform behavior; SaaS delivers the application; FaaS/serverless executes functions or workloads on demand. Moving upward can reduce undifferentiated operations but also changes configuration surface, portability, observability and provider dependency. Select from requirements—not from a blanket belief that one model is “best.”

Public cloud uses shared provider infrastructure; private cloud is dedicated to an organization; hybrid connects distinct private/on-premises and public environments; multicloud uses services from multiple cloud providers. Multicloud can meet organizational, resilience or capability needs, but duplicates identity, network, skills, governance and operational complexity. Tenancy describes resource sharing/isolation, not automatically ownership or security.

Shared responsibility changes by service and provider. The provider normally secures physical facilities and underlying cloud infrastructure; the customer still owns data classification, identities, entitlements, workload configuration and much of application security. Map every control to an owner, evidence source, review cadence and failure response.

Related item: Responsibility can be shared without being ambiguous. A RACI-style control matrix helps expose gaps such as “the provider patches the host, but who patches the guest or base image?”

CURRENT BLUEPRINT — community cloud: Objective 2.1 includes this deployment model. NIST SP 800-145 describes infrastructure dedicated to a community of organizations with shared concerns, such as mission, security or compliance. Ownership and operation can involve member organizations or a third party, on or off premises. This is different from public access or simply buying accounts from multiple providers. NIST’s hybrid taxonomy connects distinct cloud infrastructures; an ordinary on-premises network connection alone does not demonstrate all the characteristics of private cloud.

Availability, resilience and recovery architecture¶

Regions are geographic service areas; zones/failure domains separate infrastructure within or across a region. Horizontal scaling adds instances; vertical scaling changes instance capacity. Elasticity responds to demand; scalability is the ability to handle growth. A load balancer distributes healthy traffic, but health checks, session state, data consistency and dependency design determine whether this actually increases availability.

High availability minimizes service interruption; disaster recovery restores after a disruptive event; business continuity preserves essential business outcomes. Recovery time objective (RTO) is targeted restoration time; recovery point objective (RPO) is tolerated data-loss window. Metrics are objectives until backups, replication, runbooks, capacity, access and restore/failover tests prove them. Active-active, active-passive, pilot-light, warm-standby and backup/restore approaches trade cost, complexity, RTO and RPO.

Avoid single points across DNS, identity, secrets/keys, network egress, load balancing, compute, storage, database, observability and administrators. Replication can reproduce corruption or ransomware; a snapshot can depend on the source account; redundancy is not the same as an isolated, retained and restored backup.

Original availability and failure-capacity cases¶

PRACTICAL DEPTH: If two required serial components each have 99.9% availability, a simplified independent-failure model gives 0.999 × 0.999 = 99.8001%. If either of two independent 99% components can serve the complete request, a simplified parallel model gives 1 − (1 − 0.99)² = 99.99%. Shared identity, data, routing, deployment or control-plane failures can invalidate the independence assumption. These calculations are not vendor SLAs or evidence of real application availability.

A service needs four units of capacity during a failure. With three equal zones and two units in each, six total units leave four after one zone is lost. That is a theoretical minimum with no remaining load margin; test latency, quotas, placement, failover and dependencies before calling the design sufficient. A healthy replica count can hide all replicas sharing one failure domain. Cloud bursting likewise requires compatible identity, data, networking and startup capacity before overflow demand arrives.

Virtualization, containers and orchestration¶

A hypervisor allocates virtual CPU, memory, storage and networking to VMs. Images/templates speed consistent provisioning; snapshots capture point-in-time state but have lifecycle and consistency limits. Overcommit, noisy neighbors, thin provisioning and orphaned resources can create performance or cost risk. Validate guest tools/drivers, licensing and placement constraints.

Containers package application and dependencies while sharing a host kernel. Images are immutable layers; registries distribute them; containers add runtime state; volumes preserve data outside the writable layer. Orchestrators schedule replicas, expose services, attach configuration/secrets/storage, perform health checks and rollouts, and reschedule after failure. Container portability does not erase kernel, architecture, storage, identity, network or managed-service differences.

Related item: VM orchestration, container orchestration and IaC overlap but manage different layers. State which tool owns each resource to prevent competing automation.

Cloud networking¶

Design IP address space before connection: avoid overlapping CIDRs, reserve growth, and separate environments/trust zones. Virtual networks contain subnets, route tables, gateways, firewalls/security groups, load balancers, private endpoints and name resolution. Public endpoints traverse Internet-accessible addressing; private connectivity can use VPN or dedicated circuits, but “private” does not automatically mean encrypted, authenticated or least privilege.

Follow a packet both directions: source identity/address, DNS result, route, NAT, network/security policy, load balancer, target listener, host/workload policy, application and return path. VPN establishes an encrypted overlay and depends on compatible proposals, routes and identities. Dedicated links provide predictable private connectivity but still need redundant paths and security controls. SDN separates programmable control from packet forwarding; NFV implements functions such as routing or firewalling in software.

DNS maps names and enables discovery; DHCP supplies addressing configuration; NTP supplies time used by logs, certificates and authentication. CDN and edge/cache services reduce latency and origin demand but require cache/invalidation, TLS, access and data-residency decisions.

Compute, storage, database and workload optimization¶

Choose compute by workload shape: general purpose, compute/memory/storage/GPU optimized, autoscaled groups, containers, serverless or dedicated hosts. Consider architecture, licensing, startup time, locality, quotas, interruptibility and steady versus burst usage. Right-sizing uses measured utilization and latency, not only average CPU.

Block storage presents volumes for filesystems/databases; file storage provides shared hierarchical access; object storage uses objects/metadata/API and suits durable unstructured data. Evaluate latency, throughput, IOPS, consistency, durability, availability, access protocol, encryption, replication and lifecycle tiering. Ephemeral local storage is fast but tied to instance lifecycle.

Relational databases emphasize schema, joins and transactions; non-relational types trade data model and consistency behavior for particular scale/access patterns. Managed databases reduce infrastructure work, not data modeling, access, backup/restore, patch-window or cost responsibility. Caches improve latency but introduce invalidation and failure-mode decisions.

Cost includes consumption, licensed capacity, requests/operations, data transfer/egress, storage tier/retrieval, support and idle resources. Use tagging/labels, budgets/alerts, showback/chargeback, scheduling, rightsizing, autoscaling, lifecycle policies and commitment/spot models only when workload risk and utilization support them. Performance and cost optimization must preserve SLO, security and recovery margin.

Evolving technologies — objective 1.11¶

CURRENT BLUEPRINT: Match the task to a capability and an evaluation method:

Task	Design and validation question
Text recognition	Extract text from images/documents; measure errors on representative layouts and protect sensitive content.
Translation / sentiment	Convert language or classify expressed sentiment; evaluate language/domain coverage and ambiguous cases.
Visual recognition	Detect or classify image content; check false positives/negatives, lighting and deployment conditions.
Voice-to-text / text-to-voice	Transcribe or synthesize speech; assess language, noise, accessibility, latency and data handling.
Generative AI	Generate content from inputs/context; verify accuracy, authorized data use, output handling and action permissions. A fluent answer is not an evidence check.
IoT	Connect sensors/devices through appropriate gateways and communication paths; establish device identity, updates, buffering, data validation and loss/duplicate handling.

These are original planning questions, not claims that a particular model or product meets the requirement. Distinguish model training from inference, and assess retention, resource demand and access boundaries. Edge processing can reduce round trips or bandwidth, but requires local capacity and an update/recovery design.

As one provider-specific example, AWS IoT’s overview distinguishes MQTT/MQTT over secure WebSockets publish/subscribe from HTTPS publishing, with separate device/gateway and management interfaces. The provider-neutral lesson is to verify the chosen protocol’s supported operations and identity boundary; do not assume all interfaces expose identical behavior.

Original capacity, throughput and cost cases¶

A queue has 600 pending items, receives two per second and each worker processes one per second. Draining the backlog within five minutes requires two items/second of spare capacity, or four workers total under this steady-rate model. Startup delay, retries and downstream limits can require more; scaling only on queue length can misread old versus newly arriving work.
At 8,000 IOPS with 16 KiB requests, the arithmetic data rate is 125 MiB/s. Actual throughput is also bounded by device, instance, network, queue depth and request pattern; IOPS and bandwidth limits can bind separately.
With invented rates of $0.08 per instance-hour and $0.09 per GB of egress, three instances for 720 hours plus 200 GB egress total $190.80. This excludes storage, requests, licenses, tax and other charges. These are practice inputs, not current vendor prices.

AWS Budgets documentation explicitly notes delayed cost information and notifications. Treat a budget alert as a signal, not an instantaneous spending cap. Any automated cost action requires supported scope, permissions, timing and service-impact review; existing usage can keep accruing charges.

2. Deployment — 19%¶

Requirements, discovery and migration¶

Inventory workload owners, users, components, versions, data classification/location, dependencies, authentication, network flows, ports/protocols, certificates, licenses, peak/seasonal load, recovery objectives and operational skills. Establish a measured baseline and acceptance tests. Hidden DNS, time, batch, file-share, IP allowlist and service-account dependencies commonly defeat superficial discovery.

Migration strategies include retaining or retiring a workload, rehosting with minimal change, replatforming onto a managed service, refactoring/rearchitecting, repurchasing SaaS, or relocating a compatible stack. The labels help communication; the decision still requires value, risk, technical fit, downtime, data movement, licensing, rollback and operating-model analysis.

Plan pilot and waves, data seeding plus change synchronization, cutover/freeze, DNS or routing transition, user communication, validation and rollback criteria. Test performance, data completeness/integrity, identity/authorization, monitoring, backup and restore—not merely “the server started.” Decommission only after retention, dependency and recovery obligations are satisfied.

Infrastructure as code and configuration¶

IaC declares or scripts infrastructure through versioned files. Declarative approaches state desired outcome; imperative approaches specify steps. Templates/modules improve reuse; variables parameterize; outputs expose results; dependency graphs order work. State records managed-resource relationships and is sensitive: protect access, encryption, locking and recovery. Drift is difference between declared and actual state.

A safe workflow is format/lint → validate → plan/preview → policy/security checks → peer approval → limited environment → observed apply → acceptance/rollback evidence → promoted immutable version. Pin providers/modules/artifacts, keep secrets out of source and ordinary output, protect any sensitive state/plan artifacts, use least-privilege pipeline identities, separate environments and review destructive replacements. Idempotence means repeated convergence; it does not prove the target state is correct.

Configuration management operates inside systems or applications, while image building produces reusable artifacts. Prefer reproducible configuration over one-off console clicks. If an emergency manual change is needed, record it, validate it and reconcile code afterward.

Validation, planning and sensitive state¶

Terraform validation checks configuration structure and consistency; it does not verify remote services or application readiness. A plan evaluates a particular configuration/input/state context. With plan’s detailed exit-code option, zero means no changes, one means error and two means changes are present. Automation that treats every nonzero code as failure will misclassify a successful change plan.

Terraform’s sensitive-data guidance distinguishes hiding a value in normal output from omitting it from saved artifacts. sensitive alone can still leave a value in state or plan files. Ephemeral values and write-only arguments have version, context and provider support requirements; do not assume a secret disappears merely because the CLI redacts it. Treat state, saved plans, backups and diagnostic output according to their actual contents and access policy.

Original local IaC lifecycle exercise¶

Save this as main.tf in a new practice directory. It was executed with Terraform 1.12.2, and deliberately pins that minor series for reproducibility. It uses only the built-in terraform_data resource and input validation. Its values are synthetic: it creates no cloud replicas, downloads no image and makes no external provider calls. A correctly shaped digest string does not establish that an image exists or is trusted.

terraform {
  required_version = ">= 1.12.2, < 1.13.0"
}

variable "deployment" {
  type = object({
    replicas     = number
    environment  = string
    owner        = string
    image_digest = string
  })
  default = {
    replicas     = 2
    environment  = "lab"
    owner        = "training"
    image_digest = "sha256:0000000000000000000000000000000000000000000000000000000000000000"
  }
  validation {
    condition     = var.deployment.replicas == floor(var.deployment.replicas) && var.deployment.replicas >= 1 && var.deployment.replicas <= 6
    error_message = "Choose an integer replica count from 1 through 6."
  }
  validation {
    condition     = contains(["lab", "staging", "production"], var.deployment.environment) && length(trimspace(var.deployment.owner)) > 0
    error_message = "Choose an allowed environment and a nonempty owner."
  }
  validation {
    condition     = can(regex("^sha256:[0-9a-f]{64}$", var.deployment.image_digest))
    error_message = "Use a syntactically valid lowercase SHA-256 digest reference."
  }
}

# Local state only: this does not create replicas, fetch an image or contact a cloud.
resource "terraform_data" "reviewed_plan" {
  input            = var.deployment
  triggers_replace = [var.deployment.image_digest]
}

output "reviewed_plan" {
  value = terraform_data.reviewed_plan.output
}

In that isolated directory, run terraform init -backend=false, terraform fmt -check and terraform validate. Review terraform plan -detailed-exitcode -out=practice.tfplan, then apply that saved local plan. A repeated plan should report no change. In an inputs.auto.tfvars.json file, supply the complete deployment object with a different owner or replica count; inspect an in-place update. A different digest triggers the explicitly configured local resource replacement. Invalid replica counts, environment, owner or digest should fail the plan. Finally destroy only this practice configuration and confirm its state lists no resources.

The example illustrates real Terraform validation/plan/state lifecycle. It does not prove provider IAM, quota, network, image, rollout or health behavior. The current online resource documentation may contain newer features; this example uses the input and triggers_replace behavior verified with its pinned runtime.

Provision and configure resources¶

Provision identity and guardrails before workloads. Select region/zone, account/project/subscription, network/subnet/routes/endpoints, compute size/image, storage/database, encryption/key, backup, monitoring/logging and tags. Apply quotas and policies early. Separate control-plane permission to create/configure a resource from data-plane permission to use its contents.

Bootstrap/cloud-init/user-data can configure a new instance, but must be repeatable, logged, bounded and secret-safe. Validate instance identity, package trust, service state, listening path, health, logs, backup, scale behavior and restart/recreation. For containers, pin an image digest/version, scan, configure non-root execution where possible, attach only required secrets/volumes/network, set requests/limits and test readiness/liveness plus rollout/rollback.

Related item: A successful deployment API response proves control-plane acceptance, not application readiness, data correctness or recoverability.

3. Operations — 17%¶

Lifecycle, scaling and maintenance¶

Track resources from request/approval through provisioning, ownership/tagging, configuration, patch/update, scale, backup, renewal, change and retirement. Detect orphans and expired certificates/secrets. Maintenance planning includes compatibility, dependency order, snapshot/backup limits, drain/failover, change window, user impact, rollback and post-change observation.

Autoscaling uses a metric, threshold, evaluation window, cooldown, minimum/maximum and health behavior. Scale-out can amplify database, API, license or downstream bottlenecks. Scheduled and predictive scaling fit known patterns; event-driven scaling follows queue or workload signals. Test scale-in data/session behavior and cost limits.

Backup, recovery and continuity¶

Define what is protected: configuration, identity, keys, databases, object/file/block data, images, pipeline artifacts and documentation. Choose full/incremental/differential or service-native mechanisms according to recovery chain and tool behavior. Protect copies with encryption, least privilege, immutability/lock where suitable, separate account/region/media, retention and legal hold.

Test restores to an isolated location. Verify identity/keys, dependency order, data integrity/consistency, application behavior, elapsed RTO and achieved RPO. A replication/failover test also needs failback and split-brain/data-reconciliation design. Runbooks need current owners, access, prerequisites and decision points.

Original recovery checkpoint: A hypothetical service fails at 14:00. The last recoverable committed data is from 13:50, so the measured data-loss window is ten minutes against a 15-minute RPO. If the usable application returns at 15:12, restoration took 72 minutes and missed a 60-minute RTO. State the reference timestamps, completeness, dependency and validation criteria; a completed storage-copy task alone is not application recovery. This arithmetic was checked locally; no cloud restore or failover ran.

Observability, performance and cost¶

Metrics quantify time-series behavior; logs record events; traces follow distributed requests; events describe state changes; health checks test chosen behavior. Correlate them with synchronized time, resource/workload identity and deployment/change metadata. Dashboards support investigation; alerts need actionable symptom, scope, severity, owner, threshold, deduplication and runbook.

SLIs measure service behavior, SLOs set internal targets and SLAs are agreements with consequences. Availability percentage alone can hide latency, correctness or regional/user impact. Baseline CPU, memory, disk latency/IOPS/queue, network throughput/loss/latency, request rate/error/latency, database connections/locks, queue depth and provider limits. Capacity planning includes growth, failure headroom and lead time.

Tagging and billing exports allocate cost; budgets/alerts reveal variance; recommendations require engineering review. Investigate quantity × rate: resource count/size/hours, request/operation volume, storage/tier/retention, data transfer and licenses. Cost anomalies can signal misconfiguration or compromise.

Related item: Monitoring tells you a known signal crossed a condition; observability lets you investigate new questions from sufficiently rich telemetry.

4. Security — 19%¶

Identity and access management¶

Federate workforce identities to a trusted provider, require MFA according to risk, use roles/groups instead of direct grants and separate privileged administration. Least privilege includes action, resource, condition, source, time and session. Use just-in-time elevation/PAM and access reviews for humans. Workloads should use short-lived managed/workload identity rather than embedded static keys.

Authentication proves identity; authorization permits action; accounting records it. Diagnose explicit denies, inherited policy, resource policy, organization guardrail, session/token expiry and cross-account trust. Break-glass accounts need isolation, strong protection, monitoring and testing.

CURRENT BLUEPRINT — interface terminology: Objective 4.3 prints “Common Language Infrastructure (CLI)” in the cloud-management list. Here the relevant operational concept is a command-line interface, alongside SDK/API and web portal access; for example, the AWS CLI documentation explicitly uses that name. This guide does not teach a .NET execution standard as the cloud management interface.

OAuth 2.0 delegates access; OpenID Connect adds an identity/authentication layer. Token issuance, successful sign-in and permission to the target resource are separate checks. Audit evidence should identify the actor, action, target, result and context without copying credentials into logs. Suspicious cloud activity can appear as new privileged identities, unusual data movement, cryptojacking/resource spikes, orphaned workloads or metadata-service access; correlate configuration and identity evidence before attribution.

Data, network and workload protection¶

Classify data, minimize collection, define residency/retention/disposal and map owners. Encryption at rest protects stored media; encryption in transit protects connections; application/client-side encryption can reduce provider visibility. Keys require creation, access separation, rotation, backup/escrow where appropriate, revocation and destruction. Secrets need a managed store, scoped retrieval, rotation and log/repository scanning.

Segment networks by trust and workload, default-deny where practical, use private endpoints/service identities, restrict management plane, filter egress, protect edge with firewall/WAF/DDoS controls, and centralize flow/security logs. Zero trust continually evaluates identity, device/workload and context rather than granting trust by network location.

Harden images and managed services with supported versions, minimum components/features, secure configuration baselines and patching. For containers, trust and scan registry/image/SBOM/signature/provenance, restrict user/capabilities/privileged mounts/host access, enforce network and admission policy, protect secrets and monitor runtime. Serverless still needs dependency, permission, input, secret, logging and denial-of-wallet controls.

Vulnerability, compliance and evidence¶

Vulnerability management inventories assets; scans code/dependencies/images/configuration/runtime; validates version, reachability and business impact; prioritizes risk; remediates through patch, configuration, replacement or compensating control; rescans and records exception/expiry. Do not treat every severity equally or suppress evidence without ownership.

PCI DSS, SOC 2 and ISO/IEC 27001 represent different payment-card, attestation and management-system contexts. Determine applicable contract/law/framework and current version with qualified governance/legal specialists. Map requirement → control → implementation owner → evidence → test → exception/remediation. Cloud provider attestations cover their scoped service controls, not the customer workload automatically.

Security monitoring correlates identity, control-plane audit, network, host/workload, data and application signals. Preserve timestamps, retention, integrity and access. Incident response follows preparation, detection/analysis, containment, eradication, recovery and lessons learned while meeting evidence, communication and regulatory duties.

5. DevOps fundamentals — 10%¶

Source control records reviewable change through commits, branches, pull/merge workflows and tags/releases. Keep secrets and generated state out; sign/verify where required; resolve conflicts by understanding both intents and retesting. An artifact repository stores promoted packages/images with version, provenance and retention.

CI validates each change through build, unit/integration/security/policy tests and artifact creation. CD promotes the same immutable artifact through environments with approvals and deployment strategies such as rolling, blue-green or canary. Rollback may require application, configuration and schema compatibility; “redeploy the old binary” is not always enough.

Automation performs repeatable tasks; orchestration coordinates tasks/resources across a workflow. Tools such as Ansible, Jenkins and Kubernetes have different roles and trust boundaries. Protect runner/controller, plugins, dependencies, webhooks, service connections and credentials. Log who changed what, from which reviewed version, with which result.

APIs enable systems integration; queues/topics decouple producers and consumers. Event-driven architecture reacts to state/event streams and must handle duplicate/out-of-order delivery, retry/backoff, poison messages/dead-letter queues, idempotency, authentication and observability. Synchronous calls are simpler but couple availability and latency; asynchronous flows trade immediate response for resilience and operational complexity.

Related item: DevOps is an operating model connecting people, process and technology. Installing a CI server or orchestrator does not by itself create safe delivery.

Integration choices and retry boundaries¶

Objective 5.3 includes REST, SOAP, RPC, WebSockets and GraphQL. Distinguish resource-oriented interfaces, structured messages, operation calls, persistent bidirectional connections and schema-driven queries. Each still needs authentication, authorization, input/output handling, versioning and observability. A protocol name alone does not guarantee encryption or safe retries. Objective 5.4 also names Ansible, Docker, ELK, Git, GitHub Actions, Grafana, Jenkins, Kubernetes and Terraform; classify their roles instead of treating them as interchangeable automation engines.

SQS standard-queue documentation provides one concrete example of delivery that may repeat a message. A consumer should distinguish a retry of the same intent from a new operation with similar data. Malcolm Featonby’s Builders’ Library article on idempotent APIs motivates caller-scoped request identifiers, parameter-mismatch rejection and a deliberate retention contract. Those principles inform the original local exercise below; it is not an AWS queue implementation.

Original atomic receipt-and-effect exercise¶

Save this Python 3.13 program as event_consumer.py. It uses Python’s sqlite3 API and explicit SQLite transactions. One local database transaction updates a synthetic total and stores its receipt. A repeated caller/request ID returns the original result; changing the intended item or amount with that same key fails. A different caller’s ID is a different key.

"""Original local transaction exercise; no queue or external side effects."""
import sqlite3


def connect(database=':memory:'):
    # Explicit SQL BEGIN/COMMIT below; do not rely on a connection context manager.
    db = sqlite3.connect(database, autocommit=True, timeout=5)
    db.executescript('''
        CREATE TABLE IF NOT EXISTS totals (
            sku TEXT PRIMARY KEY, quantity INTEGER NOT NULL);
        CREATE TABLE IF NOT EXISTS receipts (
            caller TEXT NOT NULL, request_id TEXT NOT NULL,
            sku TEXT NOT NULL, amount INTEGER NOT NULL, result INTEGER NOT NULL,
            PRIMARY KEY (caller, request_id));
    ''')
    return db


def consume(db, caller, request_id, sku, amount, before_commit=None):
    if not all(isinstance(v, str) and v.strip() for v in (caller, request_id, sku)):
        raise ValueError('Use nonempty caller, request ID and item strings.')
    if type(amount) is not int or not 1 <= amount <= 1000:
        raise ValueError('Use an integer amount from 1 through 1000.')
    db.execute('BEGIN IMMEDIATE')
    try:
        old = db.execute('SELECT sku, amount, result FROM receipts '
                         'WHERE caller=? AND request_id=?', (caller, request_id)).fetchone()
        if old is not None:
            if old[:2] != (sku, amount):
                raise ValueError('The same caller/request ID has different intent.')
            db.execute('COMMIT')
            return {'duplicate': True, 'result': old[2]}
        db.execute('INSERT INTO totals VALUES (?, ?) '
                   'ON CONFLICT(sku) DO UPDATE SET quantity=quantity+excluded.quantity',
                   (sku, amount))
        result = db.execute('SELECT quantity FROM totals WHERE sku=?', (sku,)).fetchone()[0]
        db.execute('INSERT INTO receipts VALUES (?, ?, ?, ?, ?)',
                   (caller, request_id, sku, amount, result))
        if before_commit is not None:
            before_commit()  # Lab fault-injection hook, not an external delivery step.
        db.execute('COMMIT')
        return {'duplicate': False, 'result': result}
    except BaseException:
        if db.in_transaction:
            db.execute('ROLLBACK')
        raise


if __name__ == '__main__':
    db = connect()
    try:
        print(consume(db, 'lab-client', 'request-1', 'synthetic-item', 3))
        print(consume(db, 'lab-client', 'request-1', 'synthetic-item', 3))
    finally:
        db.close()

The standalone example uses an in-memory database and prints one new result followed by a duplicate result. With autocommit=True, this code uses SQL BEGIN IMMEDIATE, COMMIT and ROLLBACK; Python’s connection commit()/rollback() methods do not perform this job in that mode. The write transaction serializes competing writers within SQLite’s supported locking model. No email, payment, cloud action or queue acknowledgement is performed inside the transaction.

Executed October 28, 2026: the two examples and a harness passed 61 checks with Terraform 1.12.2, Python 3.13.14 and SQLite 3.50.4. Terraform initialized its built-in provider, validated/planned/applied local state, produced unchanged/update/replacement outcomes, rejected six invalid inputs and destroyed the local resource. SQLite tests covered duplicates, conflicting intent, rollback, reconnect, an owned worker exiting before commit and eight concurrent calls producing one new effect. Owned temporary state and database fixtures were cleaned.

The SQLite atomic-commit discussion explains recovery mechanisms, but this test did not simulate arbitrary disk corruption or power loss. The receipt table has no expiry cleanup, distributed replication or production authentication. A local commit cannot atomically acknowledge an external queue or perform an unrelated external action; those require additional design. Do not describe this as distributed exactly-once delivery. All eight complete cloud labs remain proposed.

Original retry arithmetic: Three total attempts at each of three nested retrying layers can generate 27 downstream attempts for one top-level call. Budget attempts and elapsed time across the call chain, use appropriate backoff/jitter and respect the operation’s idempotency and error contract. Blindly retrying validation or authorization failures repeats the same problem; an ambiguous timeout may occur after the effect already committed.

6. Troubleshooting — 12%¶

Method and deployment faults¶

Define symptom, expected behavior, scope, impact, time, recent change and reproducibility. Preserve evidence; establish a theory; run the least-invasive discriminating test; plan risk/rollback; change one controlled variable; validate service, security, cost, persistence and dependencies; document root cause and prevention.

For failed deployments, inspect syntax/schema, plan output, dependency/order, provider/plugin/version, authentication/token, authorization/guardrail, region/zone, service availability, quota/capacity, image/artifact, naming/tagging, state lock/drift and logs. Separate local tool failure, control-plane rejection, resource provisioning failure and application bootstrap failure. A partial apply may require import/reconciliation rather than blind rerun or state deletion.

Network, identity and shared services¶

For network symptoms, walk DNS result, client/source, interface/address, route, NAT, firewall/security policy, VPN/tunnel, load balancer/health, target listener, workload policy, application and return path. Test name versus IP, private versus public path and permitted versus denied source. Latency can arise from distance, loss/retransmission, congestion, DNS, TLS, proxy, resource saturation or dependency—not only bandwidth.

Authentication failure can be wrong identity/provider/tenant, token expiry/audience/scope, clock skew, certificate/key, disabled account or federation. Authorization failure can be missing role, wrong resource, conditional/inherited policy, explicit deny, resource policy or stale session. Credential exposure requires revocation/rotation, scope and log review—not only deleting the file.

DNS errors include wrong zone/record/value/TTL/delegation/resolver/private-zone link; DHCP errors include scope/options/relay/exhaustion; NTP failure breaks log correlation, certificates and ticket/token protocols. Confirm system clocks and authoritative sources.

HTTP evidence — objective 6.2¶

RFC 9110’s status definitions help distinguish where to investigate; the response alone does not prove the root cause.

Status	First distinction and next evidence
400	Request rejected as a client error; inspect syntax, schema, framing and the API’s diagnostic details before repeating it.
401	Valid authentication credentials are missing for the target; inspect the challenge, token/credential scope and time without exposing secrets.
403 / 404	Refusal versus no disclosed representation. A server may conceal a forbidden resource with 404; do not infer nonexistence or solve it by granting broad access.
502	A gateway/proxy received an invalid upstream response; correlate upstream and gateway logs.
503	Temporary inability to serve, such as overload or maintenance; inspect capacity and any Retry-After guidance under a bounded retry policy.
504	A gateway/proxy did not receive a timely required upstream response; investigate latency, dependency and timeout budgets.

A DNS lookup or direct-IP probe is a discriminating test, not a substitute for the intended HTTPS host name, certificate verification and application request. Preserve the correct host/SNI context when testing an alternate address.

Resources, security and configuration¶

Quota limits, regional capacity, incorrect size, autoscale cap, CPU throttling, memory pressure, storage latency/IOPS, full volume/inodes, network limits, database locks/connections and downstream rate limits can all look like application slowness. Correlate metrics, logs, traces and change events before scaling. More instances cannot fix a serialized database lock.

Misconfiguration includes wrong region/project, route, policy, endpoint, port, image, environment variable, secret version, key permission, storage tier, backup scope or deployment order. Compare desired code, actual state, known-good environment and audit/change history. Security troubleshooting should preserve the control: do not permanently disable encryption, firewall, certificate verification or least privilege to make a test pass.

Related item: A workaround restores function; root-cause correction removes the enabling condition; prevention adds test, telemetry, guardrail, capacity or process so recurrence is less likely.

Integrated scenarios¶

Scenario 1: Migrate a regulated application¶

Inventory data, identities, flows, dependencies, load, residency, RTO/RPO and evidence obligations. Select service/deployment models and control owners; design segmented connectivity, federated identities, keys/secrets, immutable backup and logging. Pilot with IaC, seed/synchronize data, test performance/security/restore, define cutover and rollback, validate users and evidence, then retire old resources only after retention/dependency approval.

Scenario 2: Costs spike while latency worsens¶

Correlate billing quantity/rate, tags, deployment/audit events, autoscaling, request/queue, CPU/memory/I/O/network/database and error/trace signals. Determine whether traffic, loop/retry, compromise, orphan, data transfer, wrong tier/size or downstream throttling is causal. Contain safely, correct the narrow cause, validate SLO/security/recovery margin and add budget, anomaly, scale-limit and deployment tests.

Scenario 3: IaC succeeds but service is unreachable¶

Separate apply from readiness. Verify resource state, instance/container bootstrap, workload identity, DNS, routes/NAT, policies, load-balancer target/health, listener/TLS, application logs and return path. Compare code/state/known-good; repair through reviewed code where possible; test allowed and denied access, restart/recreation and rollback; then improve health and pipeline gates.

Hands-on labs¶

All eight full cloud labs remain proposed. The Terraform local-state and SQLite exercises above are narrower execution evidence. Use an authorized sandbox, synthetic data, bounded resource counts and a verified cleanup inventory; budget alerts do not guarantee an immediate spending cap.

Architecture translation: design one small workload for a public cloud and map it to a second provider/private or community alternative. Record responsibilities, identity/data flows, failure domains, capacity, RTO/RPO and cost assumptions. Success: explain one portability limit and one shared failure dependency; show how the design behaves when one zone or identity dependency is unavailable.
Network packet walk: create an isolated network/test workload with explicit routes, DNS and minimum security rules. Test allowed and denied paths plus one DNS, route and listener fault. Success: capture evidence from both directions while preserving HTTPS identity checks; restore the baseline and remove only the recorded sandbox resources.
IaC lifecycle: first run the local Terraform example and its invalid-input/update/replacement cases. Then, in an authorized cloud sandbox, inspect an actual provider plan, permissions, quotas and sensitive artifacts before a limited apply. Success: distinguish local validation, control-plane acceptance and application readiness; reconcile a deliberate benign drift and verify cleanup without deleting unrelated state or resources.
Migration rehearsal: baseline a synthetic application/database, identify dependencies and compare rehost/replatform/refactor choices. Rehearse seeding, synchronization, cutover and rollback with data/identity/performance checks. Success: show a measurable rollback decision and retained recovery point; do not decommission the source until the planned evidence and retention conditions are met.
Operations and cost: instrument a test service with metrics/logs/traces/health and a response owner. Apply bounded synthetic load, inspect queue age and downstream limits, and test scale-out/scale-in behavior. Success: connect resource quantities to a cost estimate and demonstrate why an alert or average CPU alone is insufficient; remove load generators and resources afterward.
Backup/restore: protect synthetic data, configuration and necessary recovery dependencies in an isolated copy. Restore to a separate target after an owned working-copy fault, measuring timestamps, integrity and usable application return. Success: report achieved RPO/RTO and any missed objective; distinguish bulk/granular and in-place/parallel recovery, and remove only test artifacts after retaining evidence.
Security pipeline: use a deliberately vulnerable owned sample and test configuration, with explicit assessment scope. Review image/dependency/IaC findings, remediate or document an expiring exception, and validate least-privilege workload access and secrets handling. Success: an allowed path works, a denied path remains denied and evidence supports the claimed remediation; no production scanning or leaked credentials.
Break/fix capstone: inject one quota, synthetic token/time, DNS, route, unhealthy target, secret-version or resource-pressure fault at a time. Use logs and a discriminating test to isolate the layer, repair through reviewed configuration and revalidate cost/security/recovery assumptions. Success: distinguish an ambiguous timeout from a confirmed failure and demonstrate safe retry behavior; document root cause and cleanup.

Original knowledge checks¶

How do IaaS, PaaS, SaaS and FaaS change customer responsibility?
When does hybrid differ from multicloud?
Why does provider compliance not make a workload compliant?
Distinguish availability, durability, resilience and disaster recovery.
How do RTO and RPO shape design?
Why can replication fail as a backup strategy?
Distinguish vertical scale, horizontal scale and elasticity.
What container state survives recreation, and why?
Which differences prevent a container from being universally portable?
What must an end-to-end packet walk include?
Why can private connectivity still require encryption and authorization?
Compare block, file and object storage.
When is a managed relational database preferable to a NoSQL store?
Which cost dimensions can make a small resource expensive?
What workload facts must discovery capture before migration?
Compare rehost, replatform and refactor.
What evidence makes a migration rollback viable?
Distinguish declarative from imperative IaC.
Why must IaC state be protected and locked?
How do drift, idempotence and correctness differ?
What must be validated after a provisioning API succeeds?
How should bootstrap code handle secrets and reruns?
Which controls belong in a safe resource lifecycle?
What makes an autoscaling policy stable rather than oscillatory?
Which artifacts belong in a recoverable cloud backup set?
What must a restore test prove?
Compare metrics, logs, traces and events.
How do SLI, SLO and SLA differ?
Why can average CPU mislead capacity decisions?
How does billing evidence help security investigation?
What is the difference between workforce and workload identity?
Which dimensions make a permission least privilege?
What is required after a credential leak?
Which container supply-chain and runtime controls complement each other?
What does a vulnerability scan fail to prove?
How should a compliance requirement become testable evidence?
What is the role of an immutable artifact in CI/CD?
When is blue-green preferable to a rolling deployment?
Which failure cases must an event-driven consumer handle?
How do control-plane and data-plane failure differ?
How would you separate DNS failure from application failure?
Why is disabling a security control a poor troubleshooting conclusion?
What do community cloud and objective 1.11 add to a study plan based only on the main-page summary?
Does Terraform’s sensitive flag guarantee a value is absent from state and saved plans?
Why reject different payloads under the same idempotency key, and what cannot the local SQLite transaction guarantee?
If failure is at 14:00, recoverable data is from 13:50 and service returns at 15:12, which 15-minute RPO and 60-minute RTO targets were met?

Answers and reasoning¶

The provider manages progressively more infrastructure/runtime, while customers retain responsibility for identities, data, configuration and usage according to the exact service contract.
Hybrid joins on-premises/private and public environments; multicloud uses multiple cloud providers and may or may not include on-premises/private cloud.
Attestation covers defined provider controls and scope; customers must implement and evidence their workload, identity, data and process controls.
Availability is usable service time; durability is retained data probability; resilience is adaptation/recovery from failure; DR restores after disruption.
RTO bounds restoration time and RPO bounds tolerable data loss, driving redundancy, replication, backup, automation and cost.
It can immediately copy deletion/corruption and may share account, key or regional failure; isolated retained restore-tested copies are still needed.
Vertical adds capacity to a unit, horizontal adds units, and elasticity adjusts capacity with demand.
Only externally persisted volumes/services/configuration survive by design; the writable layer disappears with the container.
Kernel/architecture, runtime, storage, network, identity and managed dependencies remain platform-specific.
Name resolution, source/address, route/NAT, policy, load balancer, listener/workload, application, dependency and return path.
Private means path/addressing exposure, not necessarily confidentiality, authenticated identity, least privilege or safe endpoint configuration.
Block is volume-like, file is shared hierarchical storage, and object is API-addressed data plus metadata; latency/protocol/consistency differ.
When schema, transactions and relational queries dominate; choose from access/consistency/scale requirements rather than branding.
Hours/size, licenses, requests, I/O, transfer/egress, storage tier/retrieval, retention, support and idle/orphan count.
Owners, components, versions, data, dependencies/flows, identity, load, licensing, recovery, compliance, operations and acceptance baseline.
Rehost changes little, replatform adopts some managed platform, and refactor changes architecture/code; risk and benefit rise differently.
Preserved old state/path, synchronized recoverable data, measurable reversal criteria, tested procedure, access, time and stakeholder decision authority.
Declarative states desired outcome; imperative specifies actions. Both require versioning, validation and rollback.
It can contain sensitive values and controls resource identity/dependencies; concurrent or lost/corrupt state can cause destructive actions.
Drift is declared/actual difference; idempotence is repeatable convergence; correctness means the authorized desired outcome is actually right.
Application readiness, health, data, identity, network, observability, backup, scale, restart/recreation and acceptance behavior.
Retrieve short-lived secrets securely, avoid logs/state/source, validate inputs, make steps repeatable and report bounded failures.
Ownership/tags, approval, code/configuration, security, patch/renewal, observation, backup, cost, change and authorized retirement.
A relevant metric with evaluation window, cooldown, minimum/maximum, health, dependency/cost bounds and scale-in safety.
Data plus configuration/IaC, identity/key recovery where permitted, images/artifacts, dependency order and current runbooks.
Integrity/consistency, access/keys, application behavior, dependency order, actual RTO/RPO and cleanup/failback.
Metrics quantify series, logs record events, traces connect requests, and events signal state change; correlation gives stronger evidence.
SLI is measured behavior, SLO is an internal target, and SLA is a contractual commitment/consequence.
Bursts, queue, disk/network/database bottlenecks, per-instance skew and tail latency can be hidden by averages.
Unexpected resources, regions, request/transfer volume or scale can reveal misconfiguration, abuse or compromised credentials.
Workforce identity represents people; workload identity represents software/service and should normally be short-lived and non-embedded.
Narrow action, resource, condition/source, time/session and environment, with explicit denies/guardrails and review.
Revoke/rotate, contain affected access, find scope/use through logs and repositories/artifacts, remediate exposure and add prevention.
Trusted provenance/signing/SBOM/scanning/pinning reduce input risk; non-root/capability/network/admission/secret/runtime controls limit execution risk.
Exploitability, reachability, business impact, complete coverage, absence of unknown flaws, or successful remediation.
Identify applicability/version, map control and owner, implement, collect protected evidence, test, and manage exceptions/remediation.
The same versioned, tested output is promoted rather than rebuilt differently per environment, supporting provenance and rollback.
When enough duplicate capacity exists and fast whole-environment traffic switch/rollback matters; database compatibility still needs design.
Duplicates, ordering, retry/backoff, poison messages, dead letters, idempotency, auth, overload and observability.
Control plane creates/configures/manages resources; data plane carries or accesses workload data. One may work while the other fails.
Compare name with direct address, resolver/authoritative evidence and local versus remote request while preserving TLS/host behavior.
It hides the cause and creates exposure. Use logs and a narrow temporary diagnostic only with authorization, then implement the least control-preserving fix.
Community cloud serves organizations with shared concerns; 1.11 explicitly includes AI/ML capabilities and IoT sensors/gateways/communications. The full PDF is the detailed scope checklist.
No. It primarily controls display; values can persist in artifacts. Ephemeral/write-only capabilities have version/context/provider requirements, and state/plan access still needs protection.
A caller’s retry must represent the same intent, or it could silently return an unrelated outcome. A local atomic receipt/effect does not include external actions or queue acknowledgements and does not establish distributed exactly-once delivery.
The ten-minute data-loss window meets the 15-minute RPO; 72 minutes to usable recovery misses the 60-minute RTO. Both require defined reference points and application validation.

CV0-003-to-CV0-004 gap checklist¶

Do not treat a CV0-003 course as complete V4 coverage. Re-map it to all six current weights and close V4 emphasis on community/multicloud/hybrid models, AI/ML and IoT, availability, workload and cost optimization, IaC deployment/state/drift, containers/orchestration, deeper security/compliance, DevOps source-control/CI-CD/event-driven integration and scenario-based troubleshooting. Use the current official page as the final scope authority.

Source and freshness notes¶

Scope, weights, delivery, experience and estimated retirement: official CompTIA Cloud+ V4 page, checked October 28, 2026.
Reachable third-party catalog metadata was checked October 28, 2026; O’Reilly and Udemy details remain unverified where access was blocked. Prices, access, bundles and catalogs can change.
Cloud services, limits, regions, naming, interfaces, security recommendations, standards and laws change. Verify implementation behavior in current first-party provider documentation.
The objective snapshot is stored at data/objective-snapshots/cv0-004-official-objectives.txt; its SHA-256 is 6fb337abbad0ccde4c7a29dceb3c7e3611211edf97a676fe7bd7800406c0a192.
This guide independently synthesizes public scope and product concepts. It does not reproduce proprietary objective PDFs, course content, PBQs or recalled exam items.

Places to learn¶

This is not a complete list, and it is not meant to be consumed end to end. Pick the formats that work for you, map them to the six official domains, practice weak areas, and recheck version/date before paying.

Resource	Access	Estimated time	Best use and boundary
CompTIA Cloud+ V4	Public	3–6 hours	Map public domains, delivery and lifecycle; repeat at the end
CompTIA CertMaster Perform	Paid	30–60 hours, provider estimate	Combined learning/practice option; verify exact CV0-004 bundle
CompTIA CertMaster Learn	Paid	25–40 hours, provider estimate	Official self-paced route listed on the current exam page
CompTIA CertMaster Labs	Paid	15–25 hours, provider estimate	Select weak-domain labs, then reproduce key work independently
CompTIA CertMaster Practice	Paid	10–20 hours, provider estimate	Baseline, explanation-led remediation and final checks
Pluralsight Cloud+ CV0-004 path	Paid	14 hours listed	Six domain courses dated July–October 2024 plus practice exam; no verified lab count
LinkedIn Learning Cloud+ CV0-004 Cert Prep	Paid	6 hours 13 minutes listed	Total Seminars route released December 1, 2025, with 12 quizzes
O’Reilly/Sybex CompTIA Cloud+ Study Guide, 4th Edition	Paid; automated catalog access blocked	Earlier 12h34 runtime not reverified	Prior fourth-edition/480-page catalog claims unverified in this review; inspect current edition before purchase
Udemy Cloud+ CV0-004 Complete Course	Paid; automated catalog access blocked	Earlier 10h54 runtime not reverified	Earlier instructor, update-date and assessment details not reverified; inspect current syllabus
MeasureUp CV0-004 practice test	Paid	5–9 hours estimated	Product-specific 186 questions, March 2025 release; suggested time includes explanation-led remediation

VERIFY CURRENT: Public metadata checked October 28, 2026; paid interiors, provider labs and assessment questions were not accessed. CompTIA’s product estimates overlap and should not be added into a mandatory workload. Other estimated hours are planning suggestions. MeasureUp’s specific 186-question listing takes precedence over its generic FAQ’s approximate 150. A course’s publication date or runtime does not establish complete current coverage.

Use practice assessments to find gaps, not to memorize items. Avoid any product claiming live, leaked or recalled exam questions.