A developer is configuring a custom extension in watsonx Assistant to call an external REST API that requires an API key passed in a request header named X-API-Key. Where in the OpenAPI specification must this authentication method be defined?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Todd Lammle: 'Imagine you're building a chatbot and this exact situation comes up — in the securityschemes object within the components section, then referenced via a security field is your go-to move. OpenAPI 3. This is a classic Domain 6: Build Back-End Integrations concept you'll want locked in before exam day.'
Full explanation below image
Full Explanation
OpenAPI 3.0 security schemes are declared in components/securitySchemes and then applied globally or per-operation via a security field. Defining an apiKey scheme with in: header and name: X-API-Key is the correct approach. watsonx Assistant reads this definition when you import the spec and prompts for the key value in the extension authentication settings. The correct answer, "In the securitySchemes object within the components section, then referenced via a security field", directly satisfies the scenario because it aligns with watsonx Assistant's design principles and the specific capability being tested. The incorrect options ("In the paths object, inline under each operation that requires the key", "In the servers object as a URL template variable", "In the info object under the contact field") may appear relevant but each misses a key requirement or introduces a step that is either unnecessary or belongs to a different workflow. Mastering the distinction between these approaches is essential for effective watsonx Assistant implementations and is a core focus of the Domain 6: Build Back-End Integrations section of the certification exam.