A CI pipeline updates the syslog server settings on one existing Meraki network every night. Reruns are expected, downstream reports reference that network's permanent identifier, and the job must leave every other network in the organization untouched. Which Meraki Dashboard API request pattern should the pipeline use?
Select an answer to reveal the explanation.
Short Explanation
You’re updating one known network, so a PUT to that network’s own endpoint lets every rerun apply the desired settings in place. The network keeps its permanent identifier, and your job leaves other networks untouched. That idempotent update keeps downstream reports pointing to the same network.
Full Explanation
Use a PUT request to the existing network’s own endpoint with the desired settings. This updates the intended network in place, so its permanent identifier remains available to downstream reports, and it avoids changing any other network. PATCHing the existing network’s syslog settings may seem suitable for a targeted change, but PATCH is not interchangeable with the method supported by a particular Dashboard endpoint; the request may be rejected rather than applying the settings. Sending only changed syslog fields in a PUT assumes partial-update behavior. PUT generally represents replacement of the addressed resource, so omitted settings may be cleared or reset instead of preserved; provide the complete desired configuration. Creating a replacement network and retiring the existing one may match the desired configuration, but the replacement has a different identifier, breaking the stated requirement. Exam caveat: HTTP method semantics are not perfectly uniform across APIs, so verify the documented behavior of the specific endpoint rather than relying only on generic REST conventions. Practical check: confirm the target network ID in the request, inspect the endpoint’s schema and response, then rerun the job and verify that the same ID and desired settings remain and no other network changed.