What is the recommended approach when a custom extension must call different API endpoints in Draft versus Live?
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 — use environment variables for the base url so the same extension resolves the correct endpoint per environment is your go-to move. Environment variables allow the same extension configuration to reference the appropriate base URL per environment at runtime; keeping a single extension definition while supporting environment-specific behavior. This is a classic Domain 8: Publish Across Multiple Environments concept you'll want locked in before exam day.'
Full explanation below image
Full Explanation
Environment variables allow the same extension configuration to reference the appropriate base URL per environment at runtime; keeping a single extension definition while supporting environment-specific behavior. Two extensions double the maintenance burden. Hardcoded conditional URLs are fragile. Disabling the extension in Draft prevents testing. The correct answer, "Use environment variables for the base URL so the same extension resolves the correct endpoint per environment", directly satisfies the scenario because it aligns with watsonx Assistant's design principles and the specific capability being tested. The incorrect options ("Create two separate custom extensions; one for Draft and one for Live", "Hardcode both URLs in the extension with a condition to select the correct one", "Disable the extension in Draft and only use it in Live") 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 8: Publish Across Multiple Environments section of the certification exam.