A development team requests a temporary AHV VM for a disposable build environment. The data can be rebuilt from source control, and the cluster is capacity-constrained. Which storage policy setting best conserves capacity for this low-risk workload?
Select an answer to reveal the explanation.
Short Explanation
Think of RF like copies of a document: RF2 keeps a spare, RF1 keeps only the one you're working on. For a throwaway dev VM, you want to stop paying for the spare copy, so RF1 is the capacity saver. The trap is chasing compression or dedupe while still keeping a full second replica.
Full Explanation
Replication factor determines how many complete copies of a VM disk are kept across the cluster. An RF1 storage policy tells the cluster to retain only one copy, so the disposable development workload consumes roughly half the replicated capacity compared with RF2. You apply it by assigning a storage policy whose container is configured for RF1, or by setting the VM disk policy to RF1 when the data can be rebuilt and temporary loss is acceptable. RF2 is the wrong choice here because it intentionally preserves a second replica for fault tolerance, which is exactly the capacity cost this scenario is trying to avoid. Compression can reduce stored bytes, but it does not remove the second replica; it merely encodes the data that still exists in replicated copies. Deduplication can eliminate repeated blocks, but it also leaves the replication model in place and may provide little benefit for unique, short-lived development data. Exam caveat: RF1 trades durability for capacity, so it belongs to rebuildable, low-risk workloads rather than production services. Operational check: confirm the VM disk or storage policy reports RF1 and verify the container's replication factor before allocating the VM.