A developer is building a Copilot Studio agent that connects to a third-party weather data API. The API requires an API key for authentication. The security team mandates that the API key must not be embedded in topic code, must not be visible to Copilot Studio makers in the environment, and must be rotatable without requiring changes to the agent or its flows. Which approach satisfies all three security mandates?
Select an answer to reveal the explanation.
Short Explanation and Infographic
Managing an API key the right way is like storing a spare house key in a bank safety deposit box instead of under the mat — Azure Key Vault is the bank, and the Power Platform environment variable of type Secret is the authorized method to reference it without exposing the actual value. When the key needs to change, you update the Key Vault secret only, and nothing in Copilot Studio needs to change. That's the rotation-without-reconfiguration requirement solved.
Full explanation below image
![Portrait infographic (1536x2048) showing enterprise API key management for Copilot Studio. Three-tier stack: Top tier 'Azure Key Vault' (key vault icon with shield) containing a secret labeled 'weather-api-key: [hidden]' and a 'Rotation' arrow showing new key version. Middle tier 'Power Platform Environment Variable (Type: Secret)' box showing 'Value: [Key Vault URI reference]' — a callout bubble saying 'Makers see the variable, not the key'. Bottom tier 'Custom Connector → Copilot Studio Agent' showing the connector reading the environment variable reference and calling the Weather API. A rotation workflow on the right shows: Update Key Vault only → No changes needed in Copilot Studio. Red X contrast panel showing Base64 in topic code (wrong). Microsoft blue and gold security color scheme on white.](/media/microsoft/ab-620/AB-620-e6-q017-infographic.webp)
Full Explanation
API key security in enterprise Copilot Studio deployments requires that secrets be stored at the appropriate security layer, access-controlled from makers, and rotatable without cascading changes through the application stack.
Option B is correct because it uses the recommended enterprise-grade secret management pattern for Power Platform. Azure Key Vault is purpose-built for secret storage — it supports access policies, audit logging, and versioning for rotation. Power Platform environment variables of type Secret can reference Azure Key Vault secrets by URI, meaning the actual secret value is never stored in Power Platform's data layer — it is fetched from Key Vault at runtime. Makers in the environment can see the environment variable definition but not the secret value, satisfying the visibility requirement. Custom connectors that reference environment variables use the resolved value at runtime. When the API key is rotated, only the Key Vault secret value is updated — the Power Platform environment variable URI reference and the custom connector configuration remain unchanged.
Option A is incorrect because Power Platform environment variables of type Secret that store the value directly in Power Platform (rather than referencing Key Vault) do not satisfy the rotation-without-change requirement as robustly. More importantly, environment variable values of type Secret can be accessed by environment admins and are stored within the Power Platform environment — they are not as securely isolated as Key Vault secrets. Additionally, direct environment variable secrets do not provide the audit trail and access policy controls that Key Vault offers.
Option C is incorrect because Base64 encoding is not encryption — it is an encoding scheme that can be trivially reversed. Storing a Base64-encoded API key in a topic variable embeds the key directly in the topic definition, which is visible to all makers in the environment. This violates both the 'not visible to makers' requirement and the 'not embedded in topic code' requirement.
Option D is incorrect because storing an API key in a Dataverse table — even with row-level security — keeps the secret in a database that is fundamentally a data store, not a secret management system. Dataverse tables do not provide the audit controls, secret versioning, or access policy capabilities of a dedicated secrets manager. Retrieving the key via a Power Automate flow also introduces latency on every API call. Additionally, passing the key as a dynamic header value in the flow's HTTP request rather than in a custom connector's native authentication setting bypasses the connector's built-in credential management.
Exam tip: The Power Platform secret storage hierarchy: most secure = Azure Key Vault referenced by environment variable → environment variable of type Secret (stored in platform) → environment variable of type Text → hardcoded in topic/flow. For any question mentioning 'not visible to makers' and 'rotatable without changes,' the answer always involves Azure Key Vault referenced through an environment variable. Know that Key Vault integration with Power Platform uses the URI reference pattern.