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.

• ✗

  JWT token in the Authorization header

  Why it's wrong here

  The Meraki Dashboard API expects a static API key in the X-Cisco-Meraki-API-Key header, not a JWT bearer token in Authorization. It is tempting because JWTs are widely used for stateless API authentication, and a JWT in the Authorization header would be correct for APIs whose identity provider issues signed tokens.

• ✗

  OAuth 2.0 token in the Authorization header

  Why it's wrong here

  Meraki Dashboard API calls authenticate with a static API key passed in the X-Cisco-Meraki-API-Key header; OAuth 2.0 bearer tokens are not accepted. It is tempting because OAuth 2.0 is the modern delegated-authorisation standard for REST APIs generally, and it would be correct for APIs that issue scoped, expiring access tokens.

• ✗

  HTTP Basic authentication with username and password

  Why it's wrong here

  Meraki Dashboard API authenticates with a per-organisation API key sent in the X-Cisco-Meraki-API-Key header, not a username/password pair. Basic authentication is tempting because it is the default for many REST APIs and legacy Meraki endpoints, but it cannot scope permissions per key or support key rotation.

• ✓

  API key in the X-Cisco-Meraki-API-Key header

  Why this is correct

  The Meraki Dashboard API authenticates every call with a static API key passed in the X-Cisco-Meraki-API-Key request header, satisfying the stem's requirement for the dashboard's native authentication method. Unlike OAuth 2.0 bearer tokens, which Meraki does not issue for dashboard API access, this header-based key is the sole supported credential.

Go deeper

Related to this question