The water utility releases a new meter-reading app that talks to Intersight. Two engineers ship builds with different unofficial and official client library versions because the SDK was left unpinned. What should the release process treat the platform client library as?
Select an answer to reveal the explanation.
Short Explanation
Cisco platform SDKs are ingredients in the meal kit, not free air in the kitchen. Pinning them documents the API surface you actually tested and keeps both engineers shipping the same client behavior.
Full Explanation
Platform client libraries for Intersight (or any Cisco API SDK) are ordinary application dependencies: they define the request surface, serialization, and auth helpers the meter-reading app was tested against. The release process must treat them as versioned release dependencies with explicit pins so two engineers cannot ship unofficial versus official builds that behave differently against the same municipal controller.
Treating the SDK as an ambient OS package that never belongs in the application list hides the API surface from the release bill of materials and invites silent host-level drift. Calling it a runtime secret confuses credentials (which rotate) with library code (which versions); rotating a token does not align two different client majors. Managing it as a network topology artifact owned only by campus switching teams misplaces a software dependency into Layer-2/3 operations.
Exam caveat: pinning the official client still requires testing against the Intersight API version you expect—pinning does not freeze the remote API. Operational check: record the exact client library version in the lockfile or release notes, verify both engineers’ builds resolve to that pin in CI, and smoke-test a representative inventory or meter-reading call before promoting the water-utility release.