CompTIA A+ Core 1 Domain 4: Virtualization and Cloud Computing

The provider runs its applications on cloud infrastructure and users reach them through a thin client such as a web browser, configuring only user-specific settings while the provider manages everything else.

• ATrap of picking the model where the customer deploys and maintains operating systems and applications; IaaS supplies raw compute, not a finished browser-based application that the provider fully manages.
• BNames the layer that supplies a development platform for building and deploying custom application code; the firm consumes a finished product instead of developing software, so PaaS does not fit.
• DConfuses one of the five essential cloud characteristics with a service model; on-demand self-service describes how resources are provisioned, not which layer of the technology stack is delivered.

The provider supplies the runtime, libraries, and tools and manages servers, operating systems, and storage, while the consumer controls only the deployed applications and some hosting-environment settings.

• ATrap of choosing the layer where you must provision and maintain the operating system yourself; the team explicitly wants to avoid managing servers and operating systems, which IaaS still requires.
• CNames the model that delivers a finished application to end users; here the team is building and deploying their own software, so a ready-made application does not match the requirement.
• DConfuses a deployment model that combines private and public clouds with a service model describing which layer of the technology stack the provider delivers to the developer.

The provider supplies fundamental compute, storage, and networking while the consumer controls operating systems, storage, and deployed applications, matching the need to install and patch the OS.

• ATrap of selecting the top layer where the provider manages everything including the operating system; with SaaS the customer cannot install or patch their own operating system as required here.
• BNames the platform layer where the provider manages the operating system for you; the scenario explicitly requires the customer to install and patch the operating system themselves.
• CConfuses one of the five essential characteristics with a service model; resource pooling describes multi-tenant sharing of provider resources, not the layer of infrastructure being rented to the customer.

The infrastructure is provisioned for exclusive use by a specific community of organizations that share concerns such as mission, security requirements, policy, and compliance considerations.

• BTrap of choosing the model open to the general public and shared among unrelated tenants; the hospitals want exclusive use limited to their compliance-bound group, not access for anyone.
• CNames the model dedicated to a single organization; here several separate hospital organizations jointly share the environment, so a single-tenant private cloud does not describe the arrangement.
• DConfuses a composition of two or more distinct cloud types bound together with a single shared environment serving multiple organizations that happen to have common concerns.

Two distinct cloud infrastructures (private and public) remain unique entities but are bound together to enable data and application portability, such as cloud bursting for load balancing.

• ATrap of naming only the public side; the retailer also keeps sensitive data in a private environment, so a single public cloud does not describe the combined setup it uses.
• BNames only the dedicated on-premises side; the retailer also offloads to a public provider during spikes, so an exclusively private cloud omits the public component of the design.
• DConfuses an environment shared by multiple organizations with common concerns with a single organization combining its own private and public clouds to gain elastic capacity during peaks.

A consumer can unilaterally provision computing capabilities such as server time and storage automatically as needed, without requiring human interaction with the service provider.

• ATrap of picking the trait about reaching services over the network from varied thin or thick clients; the scenario highlights provisioning without human interaction, not multi-device accessibility.
• CNames the metering trait that monitors, controls, and reports resource usage; the scenario is about self-provisioning instantly, not about tracking or billing consumption for transparency.
• DConfuses the multi-tenant trait where provider resources are shared among many consumers with the consumer's ability to provision capacity independently and automatically on demand.

Capabilities are elastically provisioned and released, sometimes automatically, to scale outward and inward with demand, appearing effectively unlimited to the consumer at any time.

• ATrap of choosing the multi-tenant sharing trait; the scenario emphasizes automatic scaling out and in with demand, not multiple tenants drawing from a common shared pool of resources.
• BNames the usage-metering trait; while billing may follow consumption, the described behavior is automatic capacity scaling, not the monitoring and reporting of how much was used.
• CConfuses network accessibility from diverse client devices with the elastic provisioning and release of capacity that scales rapidly outward and inward to match changing demand.

Cloud systems automatically control and optimize resource use through metering, and usage can be monitored, controlled, and reported, providing transparency for both provider and consumer.

• BTrap of selecting the scaling trait; the scenario describes metering and billing of consumed resources, not the automatic outward and inward scaling of capacity to match demand.
• CNames the self-provisioning trait; the focus here is transparent measurement and reporting of usage, not the consumer's ability to provision resources without provider interaction.
• DConfuses the multi-tenant sharing of provider resources among consumers with the metering capability that quantifies, monitors, and reports each consumer's actual resource consumption.

It runs directly on the host hardware in place of a host operating system, scheduling VM resources straight to the hardware, and is common in enterprise data centers.

• ATrap of picking the hosted type that runs as an application on top of a conventional host operating system; the scenario installs the hypervisor directly on bare hardware with no host OS.
• BNames an approach that shares the host kernel and packages only an application; it is not a hypervisor installed directly on server hardware to run full virtual machines with their own OS.
• DConfuses the desktop hosted hypervisor used for end-user testing, which requires an underlying host operating system, with a bare-metal hypervisor installed directly on server hardware.

It runs on a conventional operating system as a software layer or application, scheduling VM resources against the host OS, and suits individual users running a few guest operating systems.

• ATrap of selecting the bare-metal type that replaces the host operating system and runs directly on hardware; here the hypervisor is installed as an application on top of an existing Windows OS.
• CNames a hypervisor embedded at the firmware level; the described product is ordinary software installed on top of Windows, not code residing in the system firmware below the operating system.
• DConfuses a container runtime that shares the host kernel and isolates processes with a hosted hypervisor that runs complete guest operating systems on top of the host OS.

The hypervisor pools the host's processing, memory, and storage and reallocates them among virtual machines, giving each VM its allocated vCPU, RAM, and virtual disk.

• ATrap of attributing host resource allocation to the guest OS; the guest only manages resources already handed to it, while the hypervisor is what allocates physical host resources among the VMs.
• BNames the firmware that initializes hardware at boot; it does not pool and distribute CPU, memory, and storage to running virtual machines the way a hypervisor continuously does.
• CConfuses fixed hardware dedication with virtualization; the hypervisor time-shares physical cores as vCPUs across many VMs rather than permanently reserving one physical core per virtual machine.

Running 64-bit guests in a hypervisor requires a CPU with Intel VT-x or AMD-V support that is enabled in firmware; without it the host cannot start the virtual machine.

• BTrap of assuming a dedicated GPU is mandatory; graphics acceleration is optional, whereas the actual blocker for 64-bit guests is missing or disabled CPU virtualization extensions in firmware.
• CNames a security module used for measured boot and disk encryption such as BitLocker; a TPM is not what enables a hypervisor to run 64-bit virtual machines on the host CPU.
• DConfuses a storage redundancy feature with virtualization support; RAID affects disk fault tolerance, not the processor's ability to run hardware-assisted 64-bit guest virtual machines.

NIST defines capabilities that scale rapidly outward and inward commensurate with demand, in some cases automatically, appearing unlimited to the consumer.

• ANames the multi-tenant sharing of provider hardware among many customers, but it does not describe capacity automatically growing and shrinking to track live demand.
• BDescribes metering and reporting of consumed resources for billing transparency, yet the scenario emphasizes automatic capacity change, not usage accounting or pay-per-use reporting.
• DRefers to reaching services over the network from diverse client devices, which is unrelated to provisioning and releasing capacity as demand spikes and then falls.

Scalability is the planned ability to grow capacity to handle larger workloads; cloud platforms provide several ways to scale resources as needs increase.

• BDescribes automatic, near-instant outward and inward scaling that tracks moment-to-moment demand, not the deliberate, budgeted capacity growth scheduled over successive years.
• CNames temporarily overflowing on-premises workloads into a public cloud at peak, which differs from steadily enlarging owned capacity on a recurring yearly schedule.
• DRefers to metering resource consumption for billing and transparency, which has nothing to do with planning long-term capacity growth for a rising workload.

NIST cites cloud bursting for load balancing between clouds; Microsoft describes shifting workloads from on-premises to the public cloud during periods of high demand.

• ADescribes a provider serving multiple tenants from shared hardware, not one company temporarily offloading its own peak overflow to a separate public cloud.
• BNames infrastructure shared by organizations with common concerns such as policy or compliance, not the temporary overflow of a single firm's peak workload to a public cloud.
• CRefers to metering consumed resources for billing transparency, which does not capture the act of bursting excess load from private to public infrastructure.

Azure Virtual Desktop is a desktop and app virtualization service that runs on Azure, delivering full desktops or individual apps to users on any device.

• AKeeps copies of files consistent across a user's devices, but it does not deliver a remote Windows desktop and applications running on cloud-hosted virtual machines.
• CPackages an app with its dependencies to share the host OS kernel locally, which does not provide users a full remote Windows desktop streamed from cloud servers.
• DConfigures how a single VM reaches the physical LAN, an unrelated networking detail that does not deliver hosted desktops to remote users from the cloud.

On-premises VDI means the organization itself runs the hosting servers, brokers, and gateways locally, whereas a cloud service like Azure Virtual Desktop runs without on-site gateway servers.

• AIncorrect because virtual desktops, whether on-premises or cloud-hosted, are reachable over the network from heterogeneous clients; remote access is not what distinguishes them.
• BDescribes a cloud measured-service billing trait, not the hallmark of self-hosted on-premises VDI where the organization owns and operates the hardware itself.
• DConflates desktop virtualization with OS-level containerization; VDI desktops are full virtual machines with their own guest OS, not kernel-sharing containers.

OneDrive syncs files between your computer and the cloud so changes propagate automatically to your other devices; Google Drive likewise syncs edits automatically across surfaces.

• BDescribes compute capacity scaling out and in with demand, which has nothing to do with keeping one user's documents consistent across her multiple personal devices.
• CRefers to the provider serving many tenants from shared hardware, not to mirroring a single user's files automatically across her own client devices.
• DCaptures a VM's point-in-time state for rollback on one host, not the continuous propagation of file changes to a user's other client devices.

NIST defines capabilities available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms.

• AConcerns the provider dynamically sharing and reassigning physical resources among many tenants, not many device types simply connecting to the same service over the network.
• CDescribes metering and reporting of consumption for billing transparency, which is not what is shown when varied client devices connect to the service.
• DLets a consumer provision capabilities automatically without human interaction, which is unrelated to many different device types reaching an already-running service.

NIST defines resources pooled to serve multiple consumers with a multi-tenant model, dynamically assigned and reassigned; AWS calls multi-tenancy multiple workloads in a shared environment.

• ADescribes overflowing peak workload from a private cloud into a public cloud, not multiple tenants concurrently sharing and being reassigned the same provider hardware.
• BIs a virtual-machine adapter mode that places a VM on the physical LAN, an unrelated networking detail that does not describe many tenants sharing physical resources.
• CFocuses on one consumer's capacity automatically growing and shrinking with demand, not on multiple tenants sharing and being dynamically reassigned the same physical resources.

An EC2 Dedicated Host is a physical server fully dedicated to your use, providing the single-tenant isolation and per-socket/per-core licensing the firm requires.

• BPlaces the workload on hardware dynamically shared with other tenants, the opposite of the firm's requirement for a physical server used by no other customer.
• CDescribes automatic capacity scaling with demand and says nothing about whether the underlying physical server is shared with or isolated from other customers.
• DConcerns reaching the service from many client devices over the network, not whether the compute runs on shared or single-tenant physical hardware.

Containers virtualize the operating system and share the host OS kernel as isolated user-space processes; unlike a VM, a container does not require a guest OS.

• ARuns its own complete guest operating system on virtualized hardware through a hypervisor, making it heavier and not the kernel-sharing unit the developer asked for.
• BCaptures a virtual machine's point-in-time state for rollback and is not a packaging unit for shipping an application together with its dependencies.
• DIs a single-tenant physical server used for isolation and licensing, not a lightweight application package that shares the host operating system's kernel.

NIST advises disabling unneeded hypervisor services and installing updates; Microsoft adds minimizing attack surface and keeping the host current with security updates.

• AReverses the guidance, because convenience features like shared clipboard and file sharing should be disabled since they create attack vectors between guest VMs.
• CViolates least privilege, since access to the virtualization management system must be restricted to authorized administrators because it controls every guest VM.
• DIs false, because anyone who can reboot the host might alter hypervisor security settings, so physical access controls are still required for bare-metal hypervisors.

Application virtualization provides a virtual implementation of the API an app expects; Microsoft's MSIX app attach separates applications and their state from the operating system.

• AIs a virtual-machine adapter mode that connects a VM to the physical LAN, which has nothing to do with isolating an application from the host operating system.
• BDescribes overflowing peak workload from private to public cloud, not delivering a single application in an isolated environment separate from the local OS.
• CRefers to compute capacity automatically scaling out and in with demand, which does not describe isolating and delivering an individual application to users.

Full virtualization runs a complete guest OS on virtual hardware, so a Windows VM can run on a Mac host, letting software built for one platform run on another.

• AKeeps a user's files consistent across devices in the cloud, which is unrelated to running an operating system built for a different platform on the host.
• BDescribes a provider sharing and reassigning physical resources among many tenants, not running another platform's full operating system on a single host machine.
• DSaves a virtual machine's state at a point in time for rollback and is not the act of running another platform's operating system on the host.

With NAT the VM has no address on the external network and shares the host's single network identity via a private internal subnet, reaching the internet through translation.

• AConnects the VM through the host's adapter so it gets its own IP on the physical LAN and appears as a separate device, the opposite of hiding behind the host.
• CCreates an isolated network limited to the host and its VMs with no path off the machine, so it cannot meet the requirement to reach external internet sites.
• DIs a saved point-in-time virtual-machine state used for rollback and is not a network configuration mode for connecting a VM at all.

Host-only creates a network completely contained within the host computer, connecting the host and its VMs while keeping them off the physical network and internet.

• BPuts each VM directly on the physical LAN with its own routable IP, exposing the malware lab to the production network and the internet, which violates the isolation requirement.
• CLets the VMs reach the internet through the host's translated connection, so the environment is not fully isolated as required for safe malware analysis.
• DIs a cloud characteristic about sharing provider hardware among tenants, not a virtual-machine network adapter mode for isolating lab VMs from outside networks.

A snapshot preserves the state and data of a VM at a specific point in time for rollback, and VMware warns snapshots should not be considered a backup.

• APackages an application and its dependencies to run sharing the host kernel; it is not a point-in-time capture of a running VM's state used to revert after a failed change.
• CIs a single-tenant physical server reserved for one customer's instances, not a captured point-in-time VM state that an admin can revert to after a bad patch.
• DConfigures how the VM connects to the physical LAN and stores nothing about the machine's state, so it cannot be used to roll back a failed update.

AWS and Azure both place guest-OS patching on the customer in IaaS, since the customer controls the operating system, applications, and configuration of each VM.

• AIn IaaS the provider secures only the hypervisor and the hardware beneath it; the guest OS is explicitly handed to the customer to maintain and patch.
• CNo automatic guest patching is guaranteed in IaaS; leaving the OS unpatched is a customer failure, not a feature of the service model.
• DAuditors verify controls but do not operate or patch customer workloads; guest-OS maintenance remains a direct customer responsibility in IaaS.

In SaaS the provider manages the full stack through application delivery, so application availability, integrity, and patching are the provider's responsibility, not the customer's.

• ASaaS consumers cannot access or rebuild the provider's application code; control is limited to user-level settings, not the application stack itself.
• BNo separate partner is required; the SaaS provider operates and patches the application itself as part of delivering the managed service.
• DResponsibility is layered, not an even split; for SaaS the application layer is provider-managed while the customer retains data, identity, and endpoints.

For all cloud deployment types the customer owns its data and identities, retaining responsibility for data classification, encryption decisions, accounts, and access management.

• APhysical hosts and facilities are provider-managed in every cloud service model; customers never have physical access to that infrastructure.
• BThe hypervisor is managed by the provider in all service models; customers do not configure or patch the virtualization layer themselves.
• CPhysical networking within the datacenter is owned and operated by the provider in every model; customers cannot reach that hardware.

The provider secures the physical datacenter, physical hosts, and physical network in IaaS, PaaS, and SaaS, because only the provider can physically access that hardware.

• BAccount management and access controls are customer responsibilities in all models; the provider does not create or govern the customer's user identities.
• CData classification and encryption decisions stay with the customer regardless of model; the provider supplies tools but does not own the data.
• DProtecting client devices and endpoints is a customer responsibility; the provider does not manage the consumer's accessing hardware in any model.

DaaS delivers desktops from the cloud with the provider managing the supporting infrastructure; Azure Virtual Desktop is a desktop and app virtualization service that runs on Azure.

• AA local Type 2 hypervisor runs the desktop on the user's own hardware, not in a provider-managed cloud streamed to many devices, so it is not cloud desktop delivery.
• BSelf-hosted on-premises VDI means the organization owns and manages the backend infrastructure, which is the opposite of a provider-operated cloud desktop service.
• DApplication virtualization delivers individual apps, not full desktops; the scenario describes complete cloud desktops, which is the defining trait of DaaS.

Windows Sandbox is a lightweight isolated desktop using hypervisor-based virtualization; it is temporary, so closing it deletes all software, files, and state.

• AExecuting untrusted files on the host with protection disabled risks infecting the real machine; it provides no isolation and no clean discard of changes.
• CA separate user account still shares the same operating system kernel and disk, so malware can persist and affect the host beyond that profile.
• DSafe Mode merely limits loaded drivers; it runs the same installed OS and offers no disposable container or guaranteed cleanup of malicious changes.

A Type 1 hypervisor delivers robust isolation, running each guest in a separate partition so a compromise of one VM is contained and does not automatically reach others.

• AResource pooling governs how capacity is shared, not security separation; it does not define the protective boundary that keeps compromised guests apart.
• BSnapshots aid rollback and recovery but provide no runtime separation; they do not contain an attacker who has compromised a running guest.
• COvercommitment is a capacity-efficiency technique, not a security control; assigning more resources than exist does nothing to isolate compromised guests.

Full virtualization lets one machine host several guest operating systems at once, so the developer can run and test the app across Windows and Linux on one workstation.

• BPer-use metering is a cloud billing characteristic, not the reason client-side virtualization enables multi-OS testing on a single local computer.
• CBroad network access describes cloud reachability across devices; it does not explain hosting several different operating systems locally for testing.
• DRapid elasticity is a cloud scaling concept; the scenario is about hosting multiple fixed OS environments at once on one workstation, not autoscaling.

With overcommitment the kernel may allocate less physical memory than requested, but heavy simultaneous demand can trigger heavy swapping or an out-of-memory condition.

• AResource pooling describes multi-tenant capacity sharing, not assigning more memory than exists; the stated risk about region visibility is irrelevant to the scenario.
• BElasticity refers to scaling capacity with demand, not over-assigning fixed memory; the described auto-shrink risk does not match memory over-assignment.
• DMeasured service is a cloud metering characteristic, not memory over-assignment; billing accuracy is not the hazard created by exceeding physical RAM.

When allocated vCPUs far exceed physical cores, guests contend for cycles and queue, producing elevated CPU ready time and degraded responsiveness under load.

• ANetwork saturation affects I/O throughput, not CPU ready time; high ready time specifically reflects vCPUs queuing for scarce physical processor cycles.
• CBallooning reclaims memory and pressures RAM, not CPU scheduling; CPU ready time tracks contention for physical cores, not memory reclamation activity.
• DOld storage drivers slow disk I/O, not CPU scheduling; ready time measures time vCPUs spend waiting for physical CPU, unrelated to disk driver versions.

vCPUs run as host threads and the hypervisor consumes a portion of resources converting them, so a guest cannot quite match the host's native efficiency.

• AVMs are not wired to the host by a USB cable; the performance gap comes from virtualization overhead, not any external physical cabling between guest and host.
• BModern hypervisors use hardware-assisted virtualization and do not emulate every instruction; the claim of a guaranteed fifty-percent loss is inaccurate.
• CGuests can be assigned multiple vCPUs and run multi-threaded work; there is no inherent single-core cap, so this does not explain the modest slowdown.

Rehosting moves applications to the cloud without making changes to them; it is the fastest path with the lowest short-term effort, ideal for tight timelines.

• BRefactoring redesigns the application and is the most complex, time-consuming strategy, which contradicts the goal of moving quickly with no code changes.
• CRetiring decommissions an unneeded application; here the business wants to keep and run the app in the cloud, so retiring does not fit.
• DRepurchasing swaps the app for a SaaS alternative rather than moving the existing application unchanged, so it does not satisfy a no-changes lift and shift.

Pay-as-you-go charges only for the individual services used, for as long as they are used, with no long-term contracts, much like billing for water or electricity.

• AA prepaid annual reservation requires committing and paying upfront, which is the opposite of paying only for what is consumed with no long-term contract.
• BA one-time perpetual license is a capital purchase decoupled from usage, unlike a consumption-based model that bills for resources as they are used.
• DA flat unlimited fee does not vary with consumption, whereas the scenario specifically wants to pay only for the resources actually used.

Measured service uses a metering capability so usage can be monitored, controlled, and reported, providing transparency for both the provider and the consumer.

• AOn-demand self-service means consumers provision resources themselves without human interaction; it does not describe metering and reporting of usage for billing.
• CResource pooling describes serving many tenants from shared, dynamically assigned capacity; the metering and reporting of usage is measured service, not pooling.
• DRapid elasticity is about scaling capacity quickly with demand, not about metering and reporting usage, which is the role of measured service.

A private cloud is provisioned for exclusive use by a single organization, matching the bank's need for isolated, dedicated infrastructure under tight regulatory control.

• APublic cloud is provisioned for open use by the general public and is multi-tenant, which is the opposite of exclusive single-organization use the bank requires.
• BA community cloud is shared by several organizations with common concerns, so it is not exclusive to one organization as the bank's requirement demands.
• CHybrid combines two or more distinct cloud types; it is not necessary merely to obtain exclusive single-organization infrastructure, which private cloud already provides.

Live migration transparently moves running virtual machines from one host to another without perceived downtime, allowing a host to be drained before maintenance.

• BA snapshot only captures point-in-time state for rollback; it does not transfer a running VM to another host or keep it serving users during maintenance.
• CCold cloning requires the source VM to be powered off and produces a copy, so it cannot move a running workload without downtime as the scenario demands.
• DAdjusting overcommit changes memory allocation on one host; it does not transfer running VMs to another host or provide a maintenance evacuation path.

A template is a primary copy of a virtual machine used to create ready-for-use VMs; one image can launch many instances that share the same configuration.

• AA snapshot only records point-in-time changes against one VM's own disk for rollback; it cannot be deployed as 30 separate independent ready-to-run virtual machines.
• BInstalling each server by hand defeats the goal of rapid consistent provisioning and is exactly the slow manual process a reusable master image is meant to eliminate.
• DA bridged adapter only connects a VM to the physical network for traffic; it does not clone or distribute an operating system, applications, or patches to other machines.

Providers bill outbound data transfer to the internet while inbound transfer is free, so heavy downloads of files out of the cloud increase the bill.

• AThis reverses how providers bill transfer; inbound data is generally free, so blaming upload charges contradicts a scenario where downloads, not uploads, drive the rising cost.
• CInstance runtime is billed on uptime, not on bytes moved; it cannot explain a bill that tracks download volume while uploads of the same data remain free.
• DStored-capacity charges depend on space used at rest, not on transfer direction; they do not rise specifically when users download files out to the public internet.

Committing to a one-year or three-year term of consistent usage earns a large discount, reducing resource costs by up to about 72% from pay-as-you-go prices.

• AOn-demand charges full hourly rates with no commitment and therefore gives no committed-term discount; calling it a one-year commitment contradicts its no-commitment nature.
• BSpot pricing sells interruptible spare capacity that can be reclaimed at any time; it is not a guaranteed one-year commitment suited to steady always-on baseline servers.
• CA perpetual license is a one-time capital purchase of software or hardware; it is not a cloud usage-commitment discount and wrongly conflates ownership with reserved consumption pricing.

Synchronizing on-premises directories to the cloud creates a common user identity for authentication and authorization to resources both on-premises and in the cloud.

• BAir-gapping deliberately disconnects a system from networks, which would prevent any synchronization or cloud authentication, the opposite of giving users one identity across both environments.
• CMulti-tenancy describes a provider sharing pooled infrastructure among many separate customers; it does not unify one organization's on-premises and cloud user credentials at all.
• DTrunking switches joins network segments at the data-link layer and has nothing to do with synchronizing directory user accounts between on-premises and cloud identity systems.

A container is lightweight and contains everything needed to run the application, so anyone you share it with gets the same container that runs the same way across environments.

• AA Type 1 hypervisor runs full virtual machines on bare metal and is not what packages an application with its dependencies into one portable unit that runs identically everywhere.
• BCopying files into a partition does not carry the runtime environment; differences in the host operating system and installed libraries still cause inconsistent behavior across machines.
• DA VPN only encrypts network traffic between endpoints; it neither packages an application with its dependencies nor guarantees consistent execution across different host environments.

Hyper-V requires a 64-bit processor with second level address translation, the CPU feature that efficiently maps each guest's memory to physical host memory for the hypervisor.

• AA TPM provides cryptographic key storage and measured boot, not memory address translation; it is not the processor feature Hyper-V requires in order to enable the hypervisor.
• CHyper-threading lets one core present two logical processors for throughput; it is not required for Hyper-V and is unrelated to the guest-to-physical memory translation the role needs.
• DAn integrated GPU accelerates graphics, not memory address translation; Hyper-V's requirement is a CPU feature for mapping memory, not any graphics capability at all.

A snapshot only logs changes against the base disk for rollback; if the base disk is lost, the snapshot alone cannot restore the VM, so separate backups remain essential.

• AThis is backwards; a snapshot is not an independent copy and does not live on separate storage, so it cannot replace the protection that the deleted backups provided.
• BSnapshots can be taken on running, suspended, or powered-off VMs, so the claim is incorrect; the real problem is relying on a snapshot in place of true backups.
• CSnapshots are stored locally alongside the VM and are not auto-uploaded to a cloud provider; billing is not the issue, and this misstates how snapshots actually work.

Cloning creates a virtual machine that is a copy of the original, configured with the same virtual hardware, installed software, and other properties as the source VM.

• BLive migration relocates one running VM between hosts for maintenance without downtime; it does not produce a second, separate copy of the machine as the scenario describes.
• CA checkpoint or snapshot captures point-in-time state of the same VM for reverting; it does not create a new standalone VM running beside the original as described.
• DOvercommitment only assigns more virtual resources than the host physically has; it is a capacity-efficiency technique and never duplicates a virtual machine into a second copy.

A public cloud is provisioned for open use by the general public and exists on the premises of the cloud provider, matching a startup renting pay-as-you-go resources.

• AA private cloud is dedicated to one organization, the opposite of infrastructure open to the general public; the description directly contradicts the exclusive nature of private cloud.
• BA community cloud serves a specific group of organizations with shared concerns, not the open general public, so it does not match a provider open to everyone.
• DAn on-premises data center requires owning and housing hardware in your own facility; it is neither rented nor open to the general public, contradicting the scenario.

The cloud lets you trade fixed expenses such as data centers and physical servers for variable expenses, paying only for IT as you consume it.

• ACloud billing relies on metering usage, not a fixed capital purchase; this directly contradicts the scenario where the company pays monthly only for what it consumes.
• CPay-per-use is not automatically cheaper for every workload; very steady, heavy usage can cost more than owning, so a universal savings guarantee is inaccurate.
• DShifting to operating expense does not abolish capacity planning, and providers do have finite capacity; the claim overstates and misrepresents the financial benefit being described.

An image is a read-only template for creating containers and is stored in a registry, and a container is a runnable instance launched from that image.

• AThis inverts the definitions; the registry stores the read-only image, and starting it produces the running instance, not the other way around as the option states.
• BAn image and a container are distinct objects; the image is a static template while the container is its live running instance, so they are not interchangeable terms.
• CContainers share the host operating system kernel and are not full VM disks with their own guest kernel, so describing the image as a bootable VM disk is incorrect.

PaaS removes the need to manage the underlying infrastructure such as hardware and operating systems, letting the team focus on deploying and managing its own applications.

• BIaaS still makes the customer manage the operating systems and runtime, which contradicts the team's goal of having the provider manage everything beneath the application.
• CSaaS delivers a complete vendor-built application for end users; it provides no place for the team to deploy its own custom code, so it does not fit this need.
• DA local Type 2 hypervisor is on-workstation virtualization that the team fully manages itself; it is not a cloud service that offloads the platform to a provider.