A city Intersight inventory has thousands of compute objects. How should the constructed client finish a complete collection retrieve?
Select an answer to reveal the explanation.
Short Explanation
Large Intersight lists arrive in pages—like city council minutes handed over a few sheets at a time. Keep asking with $top/$skip (or next-link) until the stack is empty.
Full Explanation
Large city Intersight inventories do not arrive in one unbounded GET. A complete constructed collection retrieve walks pages with $top and $skip, or follows the documented next-link, until the client has exhausted the set. That pattern is how municipal automation finishes a full claimed-compute census without assuming a single response body holds every object.
Issuing one unpaged GET and assuming it contains the entire estate fails because Intersight pages collections; silent truncation looks like missing racks in the library and transit orgs. Relying only on generic Link-header theory from another domain without Intersight’s paging options fails when the exam expects the platform’s $top/$skip or next-link behavior specifically. POSTing a bulk export to UCS Manager XML and ignoring Intersight paging fails by platform mix-up: UCS Manager is not the paging mechanism for an Intersight SaaS collection retrieve.
Exam caveat: off-by-one $skip arithmetic and stopping when a page is merely “small” instead of empty are common bugs—treat “no more Results / no next-link” as the termination condition, not a guess about estate size.
Operational check: page with a modest $top, accumulate Moids until exhaustion, assert the total equals a known claim count for a test org, and alert if consecutive pages return overlapping identifiers so the civic job cannot silently double-count.