Your FREE CompTIA Cloud+ Flashcards 2026 – 250+ Cards

Infrastructure as a Service: the provider supplies compute, storage, and networking; you manage the OS, runtime, and apps. Example: virtual machines.

Platform as a Service: the provider manages the OS and runtime; you deploy and manage only your application and data.

Software as a Service: the provider manages everything; you just use the application over the internet. Example: webmail, CRM.

Function as a Service: run individual functions on demand without managing servers (serverless); you are billed per invocation/execution.

A split of security duties: the cloud provider secures the cloud (hardware, host, network); the customer secures what is in the cloud (data, config, access).

A separate geographic area of a cloud provider's infrastructure, made up of multiple availability zones.

One or more isolated data centers within a region, with independent power and networking, used to build high availability.

A hybrid pattern where a private cloud overflows extra workload into a public cloud during demand spikes.

Processing data near where it is generated (the network edge) to reduce latency and bandwidth use.

Using services from two or more cloud providers, often to avoid vendor lock-in and improve resilience.

The maximum acceptable time to restore a service after an outage.

The maximum acceptable amount of data loss, measured as time since the last good backup.

A fully equipped, always-running standby site that can take over almost immediately; the most expensive DR option.

A partially configured standby site with some equipment ready; faster than cold, cheaper than hot.

A basic facility (space, power) with no running systems; the cheapest, slowest DR option.

Stores data as objects with metadata in a flat namespace; ideal for unstructured data and massive scale (e.g., S3-style).

Storage presented as raw volumes (blocks) attached to a VM, like a virtual disk; low latency for databases.

Storage presented as a shared file system (NFS/SMB) accessible by multiple clients.

Frequently accessed data on fast, higher-cost storage.

Infrequently accessed data on cheaper, slower storage.

Rarely accessed, long-retention data at the lowest cost with the slowest retrieval.

SSD (solid-state) is faster with no moving parts and higher cost; HDD (hard disk) is slower and cheaper per GB.

A cloud-provided service (e.g., managed database) where the provider handles patching, scaling, and availability for you.

An architecture that breaks an application into small, independently deployable services that communicate over APIs.

A design where components depend minimally on each other, so one can change or fail without breaking the others.

A messaging pattern where one message is delivered to many subscribers/consumers in parallel.

A mechanism that lets services automatically find and connect to each other (e.g., via a registry or DNS).

A lightweight, portable unit that packages an app with its dependencies, sharing the host OS kernel; faster and smaller than a VM.

Automating the deployment, scaling, networking, and lifecycle of containers (e.g., Kubernetes).

A repository that stores and distributes container images (public or private).

Container storage that survives the container's lifecycle, keeping data after the container stops.

Temporary container storage that is deleted when the container stops.

Running multiple virtual machines on one physical host via a hypervisor, each with its own guest OS.

Software that creates and runs virtual machines by abstracting and sharing physical hardware.

Grouping multiple hosts/nodes so they act as one system for high availability and load distribution.

A rule that controls which physical host a VM runs on (affinity keeps VMs together; anti-affinity keeps them apart).

Giving a VM direct access to a physical device (e.g., GPU) for better performance.

A virtual network built on top of a physical network (e.g., VXLAN) to connect VMs/containers across hosts.

Storage Area Network: high-speed block storage shared over a dedicated network.

Network-Attached Storage: file-level storage shared over a standard network.

A billing model charging only for the resources you actually consume.

Discounted capacity committed for a fixed term (e.g., 1-3 years) in exchange for lower rates.

Spare cloud capacity offered at a steep discount that the provider can reclaim with little notice.

A physical server reserved for a single customer's use, often for licensing or compliance.

Labeling cloud resources with key-value metadata for cost allocation, automation, and organization.

Matching resource size/type to actual workload demand to cut waste and cost.

Measuring resource usage so it can be billed, monitored, or charged back.

A database that stores data in tables with defined schemas and relationships, queried with SQL.

A database for flexible/unstructured data (key-value, document, column, graph) that scales horizontally.

A compute model where the provider runs your code on demand and handles all server management; you pay per execution.

Input/Output Operations Per Second: a measure of storage performance (how many reads/writes per second).

Virtual Private Cloud: an isolated, logically private section of a public cloud where you launch resources.

A direct, private connection between two VPCs so they can route traffic to each other.

A hub that connects many VPCs and on-premises networks through a single gateway.

Content Delivery Network: distributed edge servers that cache content close to users to cut latency.

A Layer 7 load balancer that routes HTTP/HTTPS traffic based on content (URL, headers).

A Layer 4 load balancer that distributes TCP/UDP traffic at high performance and low latency.

Internet of Things: networks of sensors and devices that collect and transmit data, often via gateways, to the cloud.

AI that creates new content (text, images, code) from learned patterns; an evolving cloud-delivered capability.

On-demand delivery of compute, storage, and services over the internet with pay-per-use pricing and elasticity.

The ability to automatically grow and shrink resources to match demand.

A user can provision resources automatically without human interaction from the provider.

Provider resources are shared among multiple tenants and dynamically assigned (multitenancy).

Usage is metered and reported transparently so customers pay for what they use.

A single instance of software/hardware serves multiple isolated customers (tenants).

Automating the arrangement, coordination, and management of complex systems and services.

Applications designed specifically for the cloud: containerized, microservices-based, and dynamically managed.

Placing data on hot, warm, cold, or archive tiers based on access frequency and cost.

A managed entry point that routes and secures application traffic, often with Layer 7 features.

A virtual control that permits or blocks network traffic by rules to protect cloud resources.

A set of rules that determines where network traffic in a VPC/subnet is directed.

A logical subdivision of a network/VPC, typically public (internet-facing) or private.

A private, high-bandwidth link from on-premises to a cloud provider (e.g., Direct Connect).

Continuously checking that services/resources are reachable and healthy.

Faster tiers (SSD, hot) cost more; slower tiers (HDD, archive) cost less per GB.

A database where the cloud provider handles patching, backups, and scaling (DBaaS).

A database the customer installs and operates on cloud compute, retaining full control.

Exposing a container's internal port on the host so external traffic can reach it.

A cloud-delivered capability for text/visual recognition, sentiment, and voice tasks.

Cloud infrastructure owned by a provider and shared by many tenants over the internet.

Cloud infrastructure dedicated to a single organization, on-premises or hosted.

A mix of public and private cloud (and/or on-prem) connected so workloads and data can move between them.

Cloud infrastructure shared by several organizations with common requirements (e.g., compliance).

Run two identical environments (blue=current, green=new); switch all traffic to green at once, with instant rollback to blue.

Release a new version to a small subset of users first; expand gradually if it is healthy.

Update instances in batches so the service stays available throughout the rollout.

Update the existing servers directly rather than spinning up new ones; simpler but riskier.

Migrate an application to the cloud with little or no change.

Migrate with minor optimizations (e.g., move to a managed database) without changing the core architecture.

Significantly redesign an application to be cloud-native (e.g., microservices, serverless).

Decommission an application that is no longer needed during a migration.

Keep an application where it is (on-prem) rather than migrating it.

Dependence on one provider's proprietary services that makes switching costly or difficult.

Defining and provisioning infrastructure through machine-readable files instead of manual setup; repeatable and version-controlled.

Managing system/app configuration in version-controlled code so environments are consistent and repeatable.

Identifying when running infrastructure no longer matches its declared (code) state.

Applying the same IaC repeatedly yields the same result, with no unintended changes.

JavaScript Object Notation: a lightweight, human-readable data format used for config and APIs.

YAML Ain't Markup Language: a human-readable, indentation-based data format common in IaC and CI/CD.

Moving workloads from one cloud provider to another.

Tracking changes to infrastructure code over time so you can review, roll back, and audit.

Selecting resource size and type based on storage, performance, security, cost, availability, and compliance needs.

Computing resources hosted in an organization's own data center rather than in the cloud.

A named placeholder that stores a value reused throughout deployment code.

Code that runs different actions based on whether a condition is true (if/else) during provisioning.

Moving workloads from a local data center into the cloud.

Assigning the right compute, storage, and network capacity to migrated workloads.

Ensuring the target cloud supports the OS, software, and dependencies being migrated.

The ongoing effort to operate a workload; a key migration trade-off.

Legal and standards requirements that constrain where and how workloads can move.

Factors like power and cooling that affect migration and placement decisions.

Symbols (e.g., +, ==, &&) used to compute and compare values in deployment code.

Categories of values (string, integer, boolean, list) used in scripts.

Reusable named blocks of code that perform a task, reducing duplication.

Validating infrastructure code before applying it to catch errors and drift.

Recording infrastructure design and code so it is maintainable and auditable.

Resources hosted by a provider and shared across many organizations.

Repatriating workloads from the cloud back to a local data center.

Provisioning resources to meet required encryption, access, and isolation controls.

Sizing/placing resources to satisfy regulatory and contractual obligations.

The ability to understand a system's internal state from its outputs: logs, metrics, and traces.

Recording discrete events from systems and applications, then collecting, aggregating, and retaining them.

Numeric measurements over time (CPU, latency, request rate) used for monitoring and alerting.

Following a single request as it moves across services to find bottlenecks and failures.

Continuously observing metrics and health to detect problems and verify performance.

Notifying responders when a metric crosses a threshold, including triage and response.

Centralizing logs from many sources into one searchable system.

The policy for how long logs are kept before deletion, balancing cost and compliance.

Adding or removing instances (scaling out/in) to handle load; the cloud-preferred approach.

Increasing or decreasing the size of an instance (scaling up/down), e.g., more CPU/RAM.

Automatically adjusting capacity based on triggers like load, schedule, or events.

Scaling driven by a condition such as trending demand, current load, or a specific event.

Scaling capacity ahead of known time-based demand (e.g., business hours).

A complete copy of all selected data; largest and slowest to create, fastest to restore.

Backs up only data changed since the last backup of any type; small and fast, slower restore.

Backs up all data changed since the last full backup; bigger than incremental, simpler restore.

Continuously copying data to another location for availability and disaster recovery.

Verifying backups by checking recoverability and integrity, not just that they ran.

Restoring data over the original/existing system.

Restoring to a separate system running alongside the original.

Applying vendor fixes to software/systems to resolve bugs and security flaws.

Major updates add significant features/changes; minor updates are small fixes or improvements.

Retiring a resource at end of life or end of support, including data handling and cleanup.

Temporary data that does not need to survive a resource's lifecycle.

Data that must be retained beyond a resource's lifecycle and is stored durably.

How often backups run (e.g., hourly, daily), balancing protection and cost.

How long backups are kept before being deleted, often set by policy/compliance.

Encrypting backup data so it is protected at rest and in transit.

On-site backups restore fast; off-site backups protect against site-wide disasters.

Bulk recovery restores everything at once; granular recovery restores specific items.

Confirming a backup can actually be restored to a working state.

Verifying backup data is not corrupted.

An operator changes capacity by hand rather than automatically.

Scaling based on a sustained upward/downward usage trend.

Scaling when a metric (CPU, requests) crosses a threshold.

Scaling in response to a discrete event (e.g., a queue depth spike).

Managing resources from provisioning through patching, updates, and decommissioning.

End of life: product retired; end of support: no more patches/help, raising risk.

Gathering log data from sources before aggregation and analysis.

The action taken after triage to resolve or mitigate an alert.

A security model that trusts no user or device by default and verifies every request (identity, posture, least privilege).

Granting users and services only the minimum access needed to do their job.

The cycle of defining scanning scope, identifying, assessing, and remediating weaknesses.

Common Vulnerabilities and Exposures: a public catalog of known security flaws, each with a unique ID.

Identity and Access Management: controlling who (or what) can access which cloud resources and actions.

Role-Based Access Control: permissions assigned to roles, and roles assigned to users.

Multifactor Authentication: requiring two or more factors (something you know/have/are) to sign in.

Letting users authenticate with one trusted identity provider to access multiple systems (e.g., via SAML).

Security Assertion Markup Language: an XML standard for exchanging authentication/authorization between identity and service providers.

An authorization framework that lets an app access resources on a user's behalf without sharing their password.

An identity layer built on OAuth 2.0 that adds authentication (verifying who the user is).

Protecting data as it moves across networks, typically with TLS.

Protecting stored data by encrypting it on disk so it is unreadable if stolen.

Securely storing and controlling access to credentials, keys, and tokens (e.g., a vault).

Protecting APIs with authentication, authorization, rate limiting, and input validation.

The principle that data is subject to the laws of the country where it is stored.

Labeling data by sensitivity (e.g., public, confidential) to apply the right controls.

An audit framework reporting on a service organization's security, availability, and confidentiality controls.

Payment Card Industry Data Security Standard: rules for protecting cardholder data.

An international standard for an information security management system (ISMS).

Data Loss Prevention: tools that detect and block sensitive data from leaving the organization.

Intrusion Detection System (alerts) and Intrusion Prevention System (alerts and blocks) for malicious traffic.

Web Application Firewall: filters HTTP traffic to block web attacks like SQL injection and XSS.

A virtual firewall of allow/deny rules controlling traffic to cloud resources.

Defenses that absorb or filter distributed denial-of-service floods to keep services available.

Security software on hosts/VMs/devices to detect and stop malware and intrusions.

Reducing attack surface by removing unneeded services, closing ports, and applying secure configs.

Center for Internet Security configuration guidelines for securely hardening systems.

A hardened, monitored jump server that provides controlled access into a private network.

A social-engineering attack that tricks users into revealing credentials or running malware.

Malware that encrypts data and demands payment for the decryption key.

Unauthorized use of cloud resources to mine cryptocurrency.

A running cloud resource that is unused, unmonitored, or compromised, wasting cost and adding risk.

An attacker gaining higher permissions than they were granted.

An immutable record of who did what and when, supporting accountability and investigations.

Securing images and runtime: prefer unprivileged containers, scan images, and limit file permissions.

Confidentiality, Integrity, and Availability: the three core goals of information security.

Ensuring data is accessible only to authorized parties.

Ensuring data is accurate and unaltered by unauthorized changes.

Ensuring systems and data are accessible when needed.

Authentication verifies who you are; authorization determines what you may access.

Issuing a signed token after login so the user need not resend credentials each request.

Verifying identities against a central directory (e.g., LDAP/Active Directory).

The resource owner decides who gets access.

Granting permissions to groups, then placing users in groups.

Defining who is accountable for specific data and its protection.

Where data physically resides, which affects performance and legal jurisdiction.

Keeping data for required periods, including litigation hold, contractual, and regulatory drivers.

An organization that publishes cloud security best practices and frameworks.

Defining which assets and systems a vulnerability scan will assess.

Fixing identified vulnerabilities by patching, reconfiguring, or mitigating.

A container with elevated host access; risky and discouraged in favor of unprivileged ones.

Protecting stored data with access policies, encryption, and least-privilege permissions.

Watching security-relevant events to detect suspicious activity.

Activity that differs from normal patterns, signaling a possible attack.

Exposed ports that widen the attack surface and should be closed.

Manipulating people into revealing information or granting access.

Attacking a known weakness, often from human error or outdated software.

A culture and practice that unites development and operations to deliver software faster and more reliably through automation.

Tracking and managing changes to source code over time (e.g., with Git).

A distributed version-control system that tracks code changes and supports branching and merging.

A proposal to merge code changes, enabling review and discussion before integration.

Peers examining proposed changes for quality, security, and correctness before merge.

Organizing parallel lines of development (branches) and merging them back safely.

Frequently merging code and automatically building and testing it to catch issues early.

Automatically delivering tested code to staging (delivery) or production (deployment).

An automated workflow that builds, tests, and deploys code through defined stages.

The packaged output of a build (e.g., a container image or zip) that gets deployed.

A read-only template containing an app and its dependencies, used to run containers.

A store for build artifacts and packages (public or private).

Representational State Transfer: a stateless web-service style using HTTP verbs and resources.

Simple Object Access Protocol: a strict, XML-based web-service protocol.

Remote Procedure Call: invoking a function on a remote system as if it were local.

A query language for APIs that lets clients request exactly the data they need in one call.

A design where services react to events/messages asynchronously, enabling loose coupling.

A protocol providing a persistent, two-way connection between client and server.

A platform for building, shipping, and running applications in containers.

An open-source platform that automates deploying, scaling, and managing containers.

An IaC tool that provisions infrastructure across providers using declarative config.

An agentless automation tool for configuration management and app deployment.

An automation server widely used to build CI/CD pipelines.

A CI/CD platform built into GitHub that automates workflows on repository events.

Elasticsearch, Logstash, and Kibana: a toolset for collecting, storing, and visualizing logs.

An open-source tool for visualizing metrics and building monitoring dashboards.

Managing code changes: commit, push, merge, pull request, review, and branching.

Saving a set of changes to the version-control repository with a message.

Combining changes from one branch into another.

Using tooling to run builds, tests, and deployments without manual steps.

Combining developers' code frequently and verifying it builds and passes tests.

The pipeline step that compiles/packages code into a deployable artifact.

Scanning code and dependencies for vulnerabilities within the CI/CD workflow.

Public repos are open to all; private repos restrict access to authorized users.

A VM image includes a full OS; a container image shares the host kernel and is smaller.

An application component exposed over a network via standard protocols (REST, SOAP, RPC).

A simple file (e.g., CSV) with no structured relationships, sometimes used as an artifact/data.

Linux software package formats (RPM for Red Hat, .deb for Debian/Ubuntu).

A provider limiting the rate of API calls; exceeding it causes errors until requests slow down.

A provider-imposed limit on resources (e.g., max instances) that can block new deployments when hit.

Allocating more virtual resources than the physical hardware can provide, causing contention.

Incorrect settings (allocation, permissions, sizing) that cause a deployment to fail or underperform.

Removal or end-of-support of a feature/version that breaks dependent deployments.

A service or feature not being offered in a particular region, breaking a deployment there.

Clients cannot obtain IP settings, often shown by scope exhaustion or no address; breaks connectivity.

Name resolution fails, so hosts can reach IPs but not names; a classic 'site is down' cause.

Clock drift from a failed time service can break authentication, certificates, and logging.

A DHCP pool runs out of addresses, so new clients cannot get an IP.

Two networks using the same IP range, causing routing conflicts after a migration or peering.

A routing table lacks a path to a destination, so traffic is dropped.

A routing entry sends traffic the wrong way, causing unreachable resources or loops.

Wrong 802.1Q tags or access-vs-trunk port settings break Layer 2 segmentation and connectivity.

High delay between request and response, often from distance, congestion, or under-provisioning.

Insufficient capacity for the traffic volume, causing slowness or drops.

4xx errors indicate a client problem (e.g., 403 forbidden, 404 not found); 5xx indicate a server-side error.

Old encryption algorithms being disabled, breaking TLS connections that still rely on them.

Exposed keys/passwords that enable unauthorized access until rotated/revoked.

Access by an entity without proper permission, often from misconfigured authorization.

A flaw in software that attackers can exploit; remediated by patching or updating.

Unapproved applications running in the environment, creating risk and policy violations.

Two systems unable to communicate because they use incompatible protocols/versions.

A complete service failure (full) versus degraded or partial loss of functionality.

A component that does not work with others, causing a failed deployment.

An old template/definition causing a deployment to use deprecated or wrong resources.

Wrong access settings that block or over-expose a deployed resource.

Under- or over-provisioning resources, causing failure or wasted cost.

Failed address translation breaking outbound/inbound connectivity for private hosts.

Incorrect settings on a router/switch/firewall that disrupt traffic.

An older protocol/version being disabled, breaking systems that still use it.

Access ports carry one VLAN; trunk ports carry multiple tagged VLANs; mixing them breaks connectivity.

A failure or misconfiguration in what an authenticated entity is allowed to do.

A failure to verify identity, sometimes caused by leaked or expired credentials.