A hazel-coppice API must load a client certificate each night for a partner call. What should replace a checked-in PFX on disk?
Select an answer to reveal the explanation.
Short Explanation
Ditch the PFX in the repo. Pull the client cert from Key Vault with the Certificate client (or the cert’s secret backing, as docs describe) so rotation does not mean hunting disks.
Full Explanation
Client certificates used for partner mutual TLS should live in Key Vault. The hazel-coppice API should load the certificate each night through the Certificate client—or through the documented secret backing Key Vault maintains for that certificate—rather than shipping a PFX in source control. Rotation then becomes a vault operation instead of hunting disks and repos.
Storing only the PFX password in Redis while keeping the PFX in Git forever still leaves private key material in version control; Redis adds another place to lose the password without fixing the root leak. Pasting PEM into an App Service sticky slot setting as permanent plaintext duplicates the secret in platform configuration and complicates rotation across slots. Uploading the PFX to a public CDN endpoint for anonymous nightly download publishes the client credential to the world.
Exam caveat: know that Key Vault certificates can be retrieved as certificate objects or as secret-encoded PFX depending on SDK samples—both keep the vault authoritative compared with Git. Operational check: remove the PFX from the repo, grant the API identity certificate or secret get as required, schedule the nightly partner call against a rotated vault certificate version, and confirm secret scanning no longer flags the old file path in new commits.