A municipal Intersight client must retrieve only the server named library-r720. Which query option narrows the GET on the server?
Select an answer to reveal the explanation.
Short Explanation
Think of $filter as telling the clerk which drawer to open before mailing the box—Intersight applies OData on the server so you never ship the whole warehouse.
Full Explanation
When a municipal Intersight client must return only the server named library-r720, the constructed query adds an OData $filter predicate on the GET—Name eq 'library-r720', or Serial/tag equivalents the API documents. Server-side filtering keeps the response small, reduces transfer cost across civic WAN links, and matches how Intersight expects constructed retrieves to narrow collections instead of shipping the whole org.
Downloading the entire organization collection and filtering names in local Python can produce the same row eventually, but it fails as the intended API technique: it wastes bandwidth, risks timeouts on large estates, and ignores the query option the platform provides for exactly this job. Appending a SQL WHERE clause to the URL path fails because Intersight’s constructed query language is OData-style ($filter), not SQL pasted into the path. Using $expand alone fails by concept: expand pulls related objects; it does not replace filtering the primary collection down to one named server.
Exam caveat: $filter syntax is exact—wrong quotes, operators, or property names yield empty sets that look like “missing inventory,” so validate the predicate against a known Name/Serial before blaming claim state.
Operational check: issue the same PhysicalSummaries (or class) GET with and without $filter=Name eq 'library-r720', confirm only the library host returns, and log the Moid for downstream detail GETs so parks and transit scripts share one identifier.