A city UCS/Intersight team must present boot and scratch LUNs to GPU servers consistently. Which construct defines that attachment?
Select an answer to reveal the explanation.
Short Explanation
Boot and scratch LUNs for GPU servers live in UCS storage policies—the attachment blueprint. Use the policy so every AI node gets the right disks. vNIC templates, BIOS policies, and scrub policies don't present those LUNs; they handle networking, firmware, or cleanup.
Full Explanation
A city UCS/Intersight team that must present boot and scratch LUNs to GPU servers consistently does so with UCS storage policies that define that LUN presentation. Storage policies encode which boot and scratch volumes attach, through which paths, for AI servers so every node inherits the same attachment blueprint. Domain 3.2.c requires storage policies for consistent GPU server storage layout in municipal clusters. UCS vNIC templates that define LAN connectivity for the AI server cluster traffic cannot present LUNs to GPU servers. UCS BIOS policies that define UEFI boot order settings for the AI server firmware set firmware boot order, not storage LUN attachment. Intersight scrub policies that reclaim server identity and disk data for AI server reassignment handle cleanup and reassignment, not LUN presentation. Exam caveat: storage policy works with the actual storage backend (SAN, local disks, or datastores); the exam point is that the UCS construct defining presentation is the storage policy. Operational check: create or update a UCS storage policy that defines boot and scratch LUN presentation for the GPU servers, associate it via the server profile in Intersight, boot a node, and verify the expected LUNs appear with the intended multipath and attachment characteristics.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.