A contractor stores a PFX as a generic Key Vault secret string and pastes a 4096-bit RSA value into another secret. How should the security engineer choose Key Vault object types instead?
Select an answer to reveal the explanation.
Short Explanation
Secrets are for passwords and connection strings, keys are for crypto ops, and certificates are for TLS with policy and issuer. Don’t jam a PFX and a raw RSA blob into generic secret strings just because the box accepted the paste.
Full Explanation
Key Vault object types are purpose-built: keys support cryptographic operations inside the HSM/software key boundary, secrets store opaque strings such as passwords and connection strings, and certificates combine key material with policy and issuer settings for TLS lifecycle. A contractor who pastes a PFX into a generic secret and a raw 4096-bit RSA value into another secret collapses those distinctions, losing certificate rotation/policy features and proper key-operation semantics for the lock-lab estate.
Keeping secrets for cryptographic keys, passwords, and TLS material “so one type covers every case” fails by concept: secrets do not provide the key-operation API or certificate policy/issuer automation. Uploading every PFX only to App Service custom-domain bindings and never using Key Vault certificate objects fails centralized rotation, policy, and shared use across services. Storing RSA material exclusively in NSG application security groups fails entirely—ASGs group NICs for network rules and never store key material.
Exam caveat: AZ-500 expects you to pick keys vs secrets vs certificates by intended operation, not by whichever portal blade accepted the paste. Operational check: import or create TLS material as a certificate object with policy, create cryptographic keys as key objects for wrap/sign/encrypt, keep connection strings as secrets, and remove mis-typed PFX/RSA secret blobs after migration.