A self-service request for a new application VM must be placed only on a cluster that has capacity available for its project. Which action should the administrator take?
Select an answer to reveal the explanation.
Short Explanation
Think of a project like a budget: you can only spend capacity on clusters that are part of the allowed pool. If the project's limits and placement scope are right, the self-service request lands where capacity exists. The trap is trying to steer placement with Flow or storage efficiency instead of project policy.
Full Explanation
Project-based self-service placement relies on the project being associated with eligible clusters and with resource limits for CPU, memory, and storage. When a request is submitted, the platform evaluates the selected project and placement scope before admitting the workload. If an eligible cluster has capacity remaining under those limits, the VM can be placed there; otherwise the request is blocked or must go to another eligible cluster. This keeps self-service consumers from overcommitting a shared cluster or violating the project's capacity policy. For example, a request for 8 vCPU and 32 GiB memory is admitted only when the selected project has that much remaining quota on an eligible cluster. A storage container on the target cluster provides storage resources, and compression changes capacity utilization after placement, not admission eligibility. A category value on a VM template supports tagging, and Flow can influence network or security policy, but neither defines project cluster placement scope or project capacity limits. A VM-to-CVM anti-affinity rule constrains workload and controller processes, not self-service project capacity policy. Exam caveat: do not confuse project placement and limits with hypervisor affinity rules or storage efficiency features. Operational check: verify the target cluster is in the project's eligible placement scope and that limits leave headroom for the requested VM size.