A city data-center inventory job must list servers claimed in Intersight. Which retrieve targets that compute inventory?
Select an answer to reveal the explanation.
Short Explanation
Claimed compute inventory in Intersight lives under PhysicalSummaries—like pulling the city’s claimed-vehicle roster from the right filing cabinet, not the traffic-camera feed.
Full Explanation
Claimed compute inventory for a city data-center job lives in Intersight under the compute PhysicalSummaries class. A constructed retrieve issues GET /api/v1/compute/PhysicalSummaries for the collection, or GET that same class with a Moid when you already know one object. That endpoint is what Intersight exposes for claimed servers the municipal tenant manages, so the inventory script talks to intersight.com on the right resource rather than inventing a parallel inventory feed.
Pulling UCS Manager’s XML inventory tree and parsing blade DNs fails as the SaaS answer because UCS Manager is a separate on-premises control plane; its DN tree is not the Intersight claimed-server list even if some hardware is dual-managed elsewhere. Treating DNA Center client-health wireless scores as server inventory fails by concept: assurance client health describes network endpoints’ experience, not compute PhysicalSummaries. Creating a server profile with POST and reading the create response as inventory fails because create is a provisioning write, not a retrieve of existing claimed hardware.
Exam caveat: PhysicalSummaries is the DEVCOR-friendly inventory surface for claimed compute; do not assume every related compute class or a UCS DN dump substitutes for the documented Intersight collection GET on exam day.
Operational check: after claiming a library or transit rack into the city’s Intersight org, run the PhysicalSummaries GET (optionally with $filter on Name or Serial), confirm the new Moid appears, and compare count against the claim queue before operators treat the dashboard as authoritative.