An administrator deploys VMs from a template onto a cluster managed by a different Prism Central than the source. On the source, the VMs' category is associated with an encryption storage policy, but on the target Prism Central no storage policy is associated with that category, so the new VMs only follow the container settings. What should the administrator do?

Prism Central storage policies are defined in Prism Central and applied to VMs through categories; a template or VM does not carry a policy object with it. When VMs land on a cluster managed by a different Prism Central, their category values may exist there, but that Prism Central has its own set of storage policies and associations. If nothing is associated with the category, the VMs fall back to the container's settings, and encryption, compression or QoS that the policy provided on the source is missing. The fix is to create a storage policy with the required settings on the target Prism Central and associate it with the same category, after which the VMs carrying that category pick it up. A Flow network security policy governs traffic between VMs; it cannot map categories to storage policies. A volume group is block storage presented to VMs, not a policy object, so attaching one changes nothing about encryption or QoS. Increasing the container's replication factor changes how many copies are kept, not whether data is encrypted. Exam caveat: categories are the glue between VMs and Prism Central policies, so check both the category values and the policy associations whenever a policy appears missing. Operational check: on the target Prism Central, open the storage policy, confirm the category association, and verify the VMs show the policy as applied.