A municipal NOC ChatOps bot posts outage notices into a Webex ops space around the clock. Which credential should the service present on each Webex API call?
Select an answer to reveal the explanation.
Short Explanation
Think of the bot token as the building’s badge for a dedicated robot account—always on duty, never pretending to be a person. A personal portal token is a short-lived visitor pass, and three-legged OAuth is how an integration borrows a user’s identity, not the default ChatOps bot pattern.
Full Explanation
A municipal NOC ChatOps bot that posts around the clock needs a durable machine identity on the Webex REST API. The correct credential is the bot’s own access token, presented as Authorization: Bearer on each request that posts or receives in the ops space. That token represents the bot identity created in the developer portal, so the service can act unattended without borrowing a human session and without depending on interactive browser consent. Messages, memberships, and webhook registrations for that bot all use the same Bearer construction.
A developer-portal personal access token fails for production ChatOps because it represents a human user, typically expires on the order of hours, and must be refreshed as if a person were still present. That model breaks overnight outage notices and ties automation to an individual account lifecycle. A three-legged OAuth authorization-code grant likewise fails the unattended pattern: it exists to let an integration act on behalf of a consenting user after a browser redirect, not to keep a robot account posting status forever while impersonating the on-call engineer. An unsigned Meraki Dashboard API key fails by platform boundary—X-Cisco-Meraki-API-Key authenticates api.meraki.com, not the Webex API Authorization header, so pasting it into Webex calls cannot authorize posts.
Exam caveat: bot tokens and integration/user OAuth tokens are different Webex identity models; choosing OAuth because “OAuth sounds more secure” is a common distractor when the task is an always-on bot.
Operational check: call GET /people/me (or an equivalent who-am-I) with the Bearer token and confirm the returned identity is the bot, then post a test message into the designated ops space before enabling production outage automation.