A financial services company requires that its Copilot Studio agent authenticate to an internal high-security trading API using mutual TLS (mTLS) with a client certificate. The API validates both the server certificate and the client certificate on every request. The organization stores certificates in Azure Key Vault. A Power Automate premium flow is used to call the API. Which configuration correctly enables client certificate authentication for this API call within the Power Platform solution?

Mutual TLS (mTLS) requires both parties to present certificates during the TLS handshake. In Power Automate, the HTTP premium action supports client certificate authentication directly, but the security of this configuration depends on how the certificate is stored and referenced.

Option C is correct and represents the secure, recommended configuration. The HTTP action's 'Client Certificate' authentication type accepts a base64-encoded PFX (PKCS#12 file containing both the certificate and private key) and, if password-protected, the PFX password. Storing the PFX as an Azure Key Vault secret referenced through a Power Platform Secret environment variable ensures that the certificate and private key are never stored in plain text within the Power Platform environment. The Power Platform managed identity must be granted the 'Get' permission on the Key Vault secret (Secret permissions → Get) to retrieve the value at runtime. This approach keeps the private key in Key Vault's HSM-protected storage and allows certificate rotation by updating the Key Vault secret without redeploying the flow.

Option A is similar to C but subtly incorrect. Storing the base64-encoded PFX as a Power Platform Secret environment variable is correct, but the description 'reference the base64-encoded PFX file and password stored as Power Platform Secret environment variables' does not mention the Key Vault-backed nature of those Secret variables or the managed identity permission requirement. In practice, if the Secret environment variables are properly configured with Key Vault backing (as in option C), this would work — but the description in A suggests storing the certificate value in the Power Platform environment variable store itself (not Key Vault-backed), which would mean the PFX value is stored in Dataverse rather than Key Vault's HSM. For a financial services high-security scenario, Key Vault-backed storage with managed identity access is the required pattern.

Option B describes a valid architectural pattern — using Azure API Management as a security proxy to handle mTLS on behalf of the Power Automate flow — but it introduces significant additional infrastructure (APIM instance required, certificate stored in APIM, additional policy configuration) and adds latency. While this is a legitimate enterprise architecture choice, it is not the most direct answer to the question of how to configure client certificate authentication within the Power Platform solution itself.

Option D describes OAuth 2.0 with certificate assertion, which is a different authentication mechanism (using a certificate to sign a JWT assertion for OAuth token acquisition from Entra ID). This is the correct approach for authenticating to Entra ID-protected APIs using a certificate credential, but the scenario describes a trading API that requires mTLS client certificate authentication directly — not OAuth token acquisition. These are fundamentally different authentication patterns: mTLS presents the certificate at the transport layer, while OAuth certificate assertion uses the certificate to sign a token request at the application layer.

Exam tip: Know that Power Automate HTTP action supports four authentication types: None, Basic, Client Certificate, Active Directory OAuth, and Raw. Client Certificate uses PFX format (base64-encoded). For high-security scenarios, always store certificates in Azure Key Vault and access them through Power Platform Secret environment variables with managed identity. Certificate thumbprint alone does not establish mTLS — the full private key must be accessible to the client.