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
Treat that API key like a spare house key: put it in Azure Key Vault, not under the topic mat. You reference it through a Secret environment variable, so makers can't see the value and you can rotate it by changing only Key Vault.
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. The approach that stores the API key as a secret in Azure Key Vault, references the Key Vault secret in a Power Platform environment variable of type Secret, configures the custom connector to use the environment variable, and updates only the Key Vault secret value when rotation is required satisfies all three mandates. This 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.\n\nThe approach that keeps the weather API credential in a Copilot Studio environment variable of type Text, references that variable in connector authentication, and edits the variable value during key rotation is incorrect because a Text environment variable stores the credential inside the Power Platform environment rather than referencing Azure Key Vault. It does not provide Key Vault-level isolation, audit logging, versioning, or access-policy controls, and it does not satisfy the requirement that the key not be visible to makers as robustly as a Key Vault-backed Secret environment variable. It also makes rotation dependent on changing the stored environment variable value instead of updating only the Key Vault secret.\n\nThe approach that encodes the API key in Base64, stores it in a Copilot Studio topic variable, and decodes it at runtime using a Power Fx expression before passing it to the custom connector as a request header 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.\n\nThe approach that stores the API key in a Dataverse configuration table with row-level security, retrieves it at runtime using a Power Automate flow, and passes it as a dynamic header value in the HTTP request to the weather API 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.\n\nExam 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.