SY0-701 Security Architecture Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  Enable provider-managed encryption at rest only and rotate the storage passwords monthly.

  Why it's wrong here

  Provider-managed encryption-at-rest (e.g., AES-256 on the storage backend) protects data while it resides on disks, but the cloud provider holds the master keys and can decrypt data during normal operations, snapshots, or forensic analysis. Rotating storage account passwords (or access keys) merely changes API authentication credentials; it does not change the encryption key hierarchy or prevent the provider's administrators from accessing the underlying volumes. If the provider copies a snapshot to a different region or a compromised internal process leaks the data, the ciphertext is still decrypted by the provider's key management system, so this control fails to address the threat of unauthorized access to the storage infrastructure itself.

• ✓

  Use client-side encryption before upload and keep the keys in an external HSM or key service.

  Why this is correct

  Client-side encryption means the data is encrypted by your own application or tooling before any bytes are transmitted to the provider, so the provider never receives plaintext or the encryption keys. Keeping the keys in an external HSM or key service (separate from the cloud account) ensures that even if the storage account, snapshots, or mounted disks are copied or accessed by the provider's administrators, the ciphertext remains unreadable without the externally held keys. This achieves a zero-knowledge architecture where the provider cannot decrypt the data, directly addressing the risk of unauthorized administrative access to the cloud storage platform.

• ✗

  Place the storage account in a private subnet and block all Internet access.

  Why it's wrong here

  Placing the storage account in a private subnet and blocking all internet access restricts the network attack surface and prevents external clients from reaching the cloud storage endpoint. However, this does nothing to protect the data from internal threats: a compromised admin account, a malicious insider at the provider, or an API call from an already-authorized workload can still read the plaintext blob storage or block volumes. Furthermore, snapshots, managed disk copies, and backups taken by the provider may reside outside the configured subnet, so network isolation cannot guarantee that copies of the data remain encrypted or inaccessible to the provider's control plane.

• ✗

  Rely on immutable snapshots and versioning to prevent unauthorized access.

  Why it's wrong here

  Immutable snapshots and versioning (e.g., WORM policy or object lock) prevent data from being modified or deleted by users, which is valuable for ransomware protection and accidental deletion recovery. However, immutability does not encrypt the data; it only preserves the existing plaintext or ciphertext state. If the data was uploaded as plaintext, the provider's administrators or anyone with the storage account key can still read it, because immutable storage preserves content but does not restrict read access or apply encryption. Thus, while this option strengthens data retention and tamper resistance, it fails to protect confidentiality against unauthorized administrative or insider access.