200-901 Cisco Platforms and Development Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  In the Authorization header as Bearer token

  Why it's wrong here

  Meraki does not use OAuth bearer tokens; it authenticates with the X-Cisco-Meraki-API-Key header, so a Bearer token is rejected. It tempts because Bearer authorisation is the standard scheme for most modern REST APIs and would be correct against an OAuth 2.0-protected endpoint.

• ✗

  In the URL as a query parameter: ?apiKey=...

  Why it's wrong here

  The Meraki Dashboard API expects the key in the X-Cisco-Meraki-API-Key request header; a query parameter is not honoured and leaks the key into URLs, proxies and logs. It tempts because many REST APIs do accept query-string keys, which would work for those services.

• ✗

  In the request body as JSON

  Why it's wrong here

  A GET request to the organisations endpoint carries no body, and Meraki reads credentials only from the X-Cisco-Meraki-API-Key header, so JSON in the body is ignored. It tempts because POST and PUT calls commonly submit credentials in JSON payloads, which works for those methods.

• ✓

  In the X-Cisco-Meraki-API-Key header

  Why this is correct

  The Meraki Dashboard API authenticates every call with a dedicated request header rather than a query string or bearer token. Supplying the key as X-Cisco-Meraki-API-Key satisfies the stem's requirement for the correct method when issuing GET https://api.meraki.com/api/v1/organizations, keeping credentials out of the URL and logs.

Go deeper

Related to this question