A Nutanix administrator is designing a category taxonomy for AHV workloads across several applications, production and non-production environments, and multiple sites. The goal is self-service placement and consistent workload management. Which category structure should be used?
Select an answer to reveal the explanation.
Short Explanation
Think of categories like filing cabinets, not sticky notes: separate Application, Environment, and Location drawers keep self-service placement predictable. If you mix those dimensions into one value, your reports, policies, and project limits start guessing instead of knowing.
Full Explanation
Nutanix categories are structured metadata that let administrators classify workloads along independent dimensions. When Application, Environment, and Location are separate category types with approved values, self-service users can select the right values, projects can scope access and placement, and operations can filter, report, and automate against the same fields. A single combined category with free-text values defeats structured metadata because the same meaning can be written many ways, making consistent policy and project placement difficult. Categories that only record application names while using project names for environment or location conflate workload classification with organizational access and hide placement attributes from category-based management. Creating only Environment and Location and relying on VM naming to infer application makes the taxonomy dependent on naming discipline, so automated placement, reporting, and project constraints cannot reliably identify the application. Exam caveat: do not memorize a menu path; test the concept of independent, controlled category types. Operational check: create Application, Environment, and Location category types, populate approved values, and assign project category restrictions before onboarding workloads.