A gorse-fire watch must encrypt a payload with a vault-managed key and must never download the raw key material. Which client pattern is correct?
Select an answer to reveal the explanation.
Short Explanation
Keys are not secrets you yank out and wave around. Use KeyClient encrypt/wrap/sign so the vault does the crypto and a non-exportable key never leaves home.
Full Explanation
When a key must never leave Key Vault, perform cryptography with the Key client: encrypt, wrap, or sign inside the vault so a non-exportable key's raw material stays home. The gorse-fire watch sends the payload or digest to Key Vault and receives ciphertext or a signature back. That pattern is the correct client choice for vault-managed keys under municipal custody rules.
Calling SecretClient.GetSecret on the key name and encrypting locally fails because cryptographic keys are not fetched as secret strings for local use when the design requires non-exportable keys; SecretClient is the wrong client and local encryption defeats the control. Exporting the key to App Configuration nightly and encrypting only with a local library fails both export policy and store selection—App Configuration is not a key HSM. Storing the raw key in Blob metadata and encrypting in the browser with JavaScript exposes key material to storage ACLs, CDN caches, and every client, which is the opposite of vault-managed crypto.
Exam caveat: some keys are exportable by policy; never-download-raw-key-material is a design constraint you must match with key type and KeyClient operations, not assume every vault key blocks export. Operational check: create or import a non-exportable key, run encrypt via KeyClient from the watch service, attempt a forbidden export or get of raw key bytes, and confirm the service never persists key material beside the ciphertext.