Cyber Security Quiz: Cloud Encryption
10 questions · exam conditions
0:00
Cloud EncryptionQuestion 1 of 10

Users connect to a cloud application through an HTTPS gateway. The gateway terminates TLS and forwards requests to application instances over ordinary HTTP on a private cloud network. The security team claims that every application request is encrypted in transit from the user to the application instance.

Which assessment of the claim is most accurate?

The claim is correct because traffic on a private cloud network is encrypted by definition.
The claim is incorrect because only the user-to-gateway segment is encrypted; the backend segment carries plaintext.
The claim is correct because TLS encryption remains attached to a request after the gateway terminates TLS.
The claim is incorrect because TLS at a gateway protects responses but does not encrypt incoming requests.
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Cloud Encryption

Practice Cloud Encryption in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Cloud Encryption, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

Users connect to a cloud application through an HTTPS gateway. The gateway terminates TLS and forwards requests to application instances over ordinary HTTP on a private cloud network. The security team claims that every application request is encrypted in transit from the user to the application instance.

Which assessment of the claim is most accurate?

  1. The claim is correct because traffic on a private cloud network is encrypted by definition.
  2. The claim is incorrect because only the user-to-gateway segment is encrypted; the backend segment carries plaintext. (correct answer)
  3. The claim is correct because TLS encryption remains attached to a request after the gateway terminates TLS.
  4. The claim is incorrect because TLS at a gateway protects responses but does not encrypt incoming requests.
Explanation: When you see a question about encryption "in transit," your job is to trace the entire path a request travels and ask whether encryption is maintained at every segment — not just part of the route. Here, the architecture has two distinct hops: user → gateway (HTTPS/TLS) and gateway → application instance (plain HTTP). The gateway terminates TLS, meaning it decrypts the traffic, inspects it, and then forwards it onward. That second hop — across the private cloud network — carries plaintext. So the security team's claim that traffic is encrypted end-to-end is simply false. B is correct: only the user-to-gateway segment is protected; the backend segment is exposed as cleartext, which matters because threats like a compromised internal host or a misconfigured network tap could intercept it. A is wrong because private networks are not encrypted "by definition." Private or internal networks restrict access, but they do not automatically encrypt traffic. Confidentiality still requires explicit encryption protocols. C is wrong because TLS is not a property that "stays attached" to data after the termination point — terminating TLS means the encryption ends there, period. The forwarded request is now plaintext. D is wrong because TLS encrypts both requests and responses symmetrically; the flaw in the scenario isn't directional, it's about the missing backend segment entirely. For exam questions like this, always map out every network segment in the described architecture. "Encrypted in transit" means every hop, not just the first one — a gateway that terminates TLS creates a plaintext gap unless re-encryption is explicitly configured on the backend.

Question 2

A cloud storage system encrypts each object with a data-encryption key. It then encrypts each data-encryption key with a key-encryption key held in a cloud key-management service. Administrators disable the key-encryption key. No plaintext data-encryption keys are cached anywhere.

What is the immediate effect on the existing objects?

  1. The object ciphertext remains stored, but the objects cannot be decrypted while the key-encryption key is disabled. (correct answer)
  2. The object ciphertext is immediately erased because disabling the key-encryption key performs cryptographic deletion.
  3. The objects remain readable because their data-encryption keys are stored beside the encrypted object contents.
  4. The objects are automatically re-encrypted with a new key-encryption key before the old key becomes unavailable.
Explanation: When you see a question about cloud encryption architectures, focus on where data actually lives and what operation is required to access it. This scenario describes envelope encryption: each object is encrypted with a data-encryption key (DEK), and each DEK is itself encrypted with a key-encryption key (KEK) stored in a key-management service (KMS). Disabling the KEK doesn't touch the stored ciphertext — it simply removes your ability to unwrap the DEK needed to decrypt it. That's exactly why A is correct. The encrypted objects sit untouched in storage, but any decryption attempt requires the KMS to unwrap the DEK using the KEK. With the KEK disabled, that unwrapping step fails, making the objects effectively inaccessible — without destroying a single byte of ciphertext. B describes cryptographic erasure (sometimes called crypto-shredding), which is what happens when you delete or destroy the KEK permanently. Disabling is a reversible administrative action, not destruction — no data is erased, and re-enabling the KEK would restore access. Don't confuse "disable" with "delete." C is wrong because it assumes the plaintext DEKs are stored alongside the objects. The passage explicitly states no plaintext DEKs are cached anywhere — only encrypted DEKs exist, and they're useless without the KEK to unwrap them. D is a fabricated behavior. KMS systems do not automatically re-encrypt objects when a key is disabled; that would require an active migration process initiated by an administrator. Study tip: In envelope encryption questions, always trace the key hierarchy. Ask yourself: which key is unavailable, and which operation does that block?

Question 3

A managed cloud database uses transparent data encryption for its database files. An attacker steals valid credentials for the application's database account and issues permitted queries that return employee salary records.

Why does transparent data encryption not prevent this disclosure?

  1. Transparent data encryption protects network packets but does not encrypt database files stored on cloud disks.
  2. Transparent data encryption protects stored files, but the database decrypts data for queries authorized under the stolen account. (correct answer)
  3. Transparent data encryption applies only after a database account has been disabled by an administrator.
  4. Transparent data encryption protects database schemas but intentionally excludes the values stored in table rows.
Explanation: When you see a question about encryption failing to prevent data exposure, always ask yourself at what layer the encryption operates and when decryption occurs. Encryption protects data in a specific state — and understanding that boundary is everything here. Transparent Data Encryption (TDE) is designed to protect data at rest — meaning the raw database files sitting on disk are encrypted. If an attacker physically steals storage media or backup files, TDE blocks them cold. However, TDE operates transparently to the database engine itself. When a legitimate query arrives, the database automatically decrypts the data to fulfill the request — it has to, otherwise the application couldn't function. This is precisely why B is correct: the attacker didn't steal a hard drive; they stole valid credentials. From the database's perspective, those credentials authorize the query, so it decrypts and returns the salary records exactly as designed. TDE never had a chance to help. A is backwards — TDE protects files on disk, not network packets. That's the job of transport-layer encryption like TLS. C describes no real TDE behavior; TDE is not tied to account status in any way. Disabled accounts are an access-control concept, not an encryption trigger. D is fabricated — TDE encrypts entire database files, including row data, not just schemas. The study tip here: always separate encryption controls from access controls. TDE is a storage-layer defense against physical theft; it cannot compensate for compromised credentials. If an attacker can authenticate, they inherit whatever the account is permitted to see — encrypted storage won't stop that.

Question 4

A production volume is encrypted with an organization-controlled cloud key. An administrator copies a snapshot of the volume into a partner's cloud account. During the copy, the snapshot is re-encrypted with a provider-managed key in the partner account. The organization later deletes its original key.

Which conclusion is most accurate?

  1. Deleting the original key makes both the production volume and the partner's copied snapshot immediately readable as plaintext.
  2. Deleting the original key makes the partner's copy unreadable because every snapshot copy retains the source volume's key dependency.
  3. The partner's copy is unencrypted because changing encryption keys during a snapshot copy removes encryption at rest.
  4. The partner's copy can remain readable because it was re-encrypted under a different key not controlled by the organization. (correct answer)
Explanation: When a cloud snapshot is copied across accounts, the encryption context travels with the data, not necessarily the key. Cloud providers like AWS allow snapshot copies to be re-encrypted with a completely different key during the copy operation — the destination key becomes the sole protector of that new copy. This is the core concept being tested here. Option D is correct because once the snapshot was re-encrypted with the partner account's provider-managed key, it became entirely independent of the organization's original key. Deleting the original key has no effect on the partner's copy — it was never tied to that key to begin with. Option A is wrong on two levels: deleting an encryption key doesn't render data "plaintext" — it renders it unreadable. Additionally, only the original production volume loses its key dependency; the partner's copy does not. Option B contains a seductive-sounding rule — that snapshot copies "retain the source key dependency" — but this is simply false. The whole point of re-encryption during a copy is to break that dependency and transfer ownership to a new key. Option C confuses the mechanism of re-encryption with the removal of encryption entirely. Changing which key protects data is not the same as removing encryption — the data remains encrypted at rest under the new key throughout the process. As a study tip, watch for questions that blur which key protects which resource. In cloud key management scenarios, always trace the encryption chain independently for each copy or snapshot — a re-encryption event creates a clean separation of key dependencies.

Question 5

A company stores customer documents in a cloud object-storage bucket. Server-side encryption is enabled for every object, and clients download objects over HTTPS. During an audit, an unauthenticated user successfully downloads a document because the bucket policy permits public reads.

Which statement best explains the audit result?

  1. HTTPS protects only upload traffic, so public users can decrypt documents during downloads.
  2. Server-side encryption encrypts object names but leaves document contents available to public users.
  3. At-rest encryption does not override access policy; the service decrypts objects for requests that the policy authorizes. (correct answer)
  4. Public-read access causes the storage service to permanently remove server-side encryption from each requested object.
Explanation: When you see a question combining encryption and access control, train yourself to think of them as two completely separate security layers — one governs confidentiality of stored data, the other governs who is permitted to retrieve it. Confusing these two layers is exactly the trap this question sets. Server-side encryption (SSE) means the cloud provider encrypts your data before writing it to disk and decrypts it before serving it to a requester. The critical word there is before serving it — the decryption happens automatically on the provider's side whenever a request is authorized. This is why C is correct: at-rest encryption protects against threats like physical disk theft or provider-infrastructure compromise, but it does not function as an access control mechanism. If the bucket policy says "allow public reads," the storage service treats an unauthenticated request as authorized and hands back a fully decrypted object over HTTPS. The encryption never had a chance to stop that. A is wrong because HTTPS protects data in transit in both directions — uploads and downloads equally. The direction of traffic is irrelevant to TLS protection. B is wrong because SSE encrypts the object contents, not the object names; more importantly, it still doesn't restrict access — that's the policy's job. D describes something that simply doesn't happen; requesting an object never strips or permanently removes its encryption settings. SSE configuration persists on the object regardless of how many times it is read. Your study tip: memorize the phrase "encryption ≠ access control." On security exams, distractors frequently imply that enabling encryption automatically restricts who can read data. It doesn't — access policies and encryption solve different problems.

Question 6

A cloud database is encrypted at rest with a customer-managed key. A reporting job queries the database, creates plaintext CSV exports, and stores them in a separate object-storage location where encryption is disabled. The organization requires every persisted copy of the records to be encrypted at rest.

Which action most directly closes the identified gap?

  1. Enable TLS on database connections because doing so automatically encrypts every CSV file after it is stored.
  2. Rotate the database key because key rotation propagates database encryption to all derived data exports.
  3. Restrict the reporting job to a private subnet because private networking encrypts persisted object contents.
  4. Enable at-rest encryption for the export location and apply appropriate key controls to the stored CSV files. (correct answer)
Explanation: When you see a cloud security question describing data flowing from a protected source into an unprotected destination, your job is to trace where the gap actually lives — then match the fix to that exact location. Here, the problem is crystal clear: plaintext CSV files are being written to an object-storage bucket with encryption disabled. The organization's policy requires every persisted copy to be encrypted at rest. That means the fix must target the export storage location itself. D does exactly this — enabling at-rest encryption on the export bucket and applying key controls directly closes the policy violation where it occurs. The distractors each commit the same category of error: they address a real security practice, but one that has no causal connection to encrypting stored CSV files. A claims that enabling TLS on database connections encrypts the CSV files afterward — this is false. TLS protects data in transit between systems; it has no effect on how data is stored once it arrives. B suggests that rotating the customer-managed key propagates encryption to derived exports — also false. Key rotation re-wraps the existing encrypted database; it does nothing to a separate storage bucket where encryption was never enabled. C proposes restricting the job to a private subnet, implying network isolation encrypts object contents — this confuses network access control with storage encryption. A private subnet limits who can reach the data, not how it's stored on disk. A useful rule of thumb: network controls protect data in transit; encryption controls protect data at rest. When a question identifies an at-rest gap, the correct answer will always address storage configuration, not networking or key rotation elsewhere.

Question 7

A company already uses correctly validated server-side TLS for connections from managed devices to a cloud API. It adds a requirement that the API must authenticate each managed device by a device certificate during TLS negotiation while continuing to encrypt traffic.

Which change best meets the new requirement?

  1. Configure mutual TLS so the API validates client certificates and devices continue validating the API certificate. (correct answer)
  2. Replace TLS with server-side disk encryption so device certificates are checked when requests are stored.
  3. Keep server-only TLS and add a private IP address because private addressing authenticates each individual device.
  4. Disable server certificate validation and require devices to present their certificates after an unverified connection.
Explanation: When a question asks about authenticating both sides of a TLS connection while maintaining encryption, you're being tested on mutual TLS (mTLS). Standard TLS only has the server prove its identity to the client; mTLS adds a second handshake step where the client also presents a certificate, and the server validates it. This is exactly how device-level authentication is achieved without disrupting encryption. Option A is correct because mutual TLS is precisely designed for this scenario. The API validates each device's certificate during the TLS handshake, devices continue validating the server certificate as before, and the session remains encrypted end-to-end. It satisfies every stated requirement: device authentication, server authentication, and traffic encryption — all within the same protocol. Option B confuses transport-layer security with storage-layer security. Disk encryption protects data at rest, not data in transit, and has nothing to do with authenticating devices during a network connection. Device certificates checked "when requests are stored" is not a real authentication mechanism for network sessions. Option C reflects a common misconception: private IP addresses identify network segments, not individual devices. They provide no cryptographic proof of device identity, so a device on the same private network could still impersonate another. Option D is a security failure, not a solution. Disabling server certificate validation removes protection against man-in-the-middle attacks, and collecting client certificates over an unverified connection undermines the entire trust model. Study tip: When you see "authenticate each device during TLS," that phrase is a direct signal for mTLS. Remember: standard TLS = one-way trust (server proves itself); mTLS = two-way trust (both sides prove themselves).

Question 8

A cloud client establishes TLS connections to an API but is configured to accept any server certificate without checking the hostname or certificate chain. A tester positioned on the network presents a self-signed certificate, establishes TLS with the client, and then creates a separate TLS connection to the real API.

Which statement best describes the resulting protection?

  1. The traffic is secure because encryption in transit is sufficient to protect data even when the server's identity is not validated by the client.
  2. Only the API response is exposed because certificate validation is not required for outbound client requests, leaving inbound responses unprotected.
  3. Each connection may be encrypted, but the tester can read and relay data because the client did not authenticate the server's identity. (correct answer)
  4. TLS automatically detects the relay because two separate encrypted connections cannot legitimately carry the same application request simultaneously.
Explanation: Whenever you see a question involving TLS and certificate validation, separate two distinct concepts in your mind: encryption and authentication. TLS does both, but skipping certificate validation eliminates the authentication half — and that omission is catastrophic. Here's what's happening in the scenario: the client accepts any certificate without checking who actually signed it or whether the hostname matches. This lets a tester slip in their own self-signed certificate, convincing the client it's talking to the real API. The client encrypts traffic to the tester; the tester decrypts it, reads it, then re-encrypts it toward the real API. Each individual tunnel is genuinely encrypted — but the tester sits in the middle reading everything in plaintext between the two hops. This is a classic TLS man-in-the-middle (MitM) attack, and answer C captures it precisely: both connections may use encryption, yet the tester can read and relay all data because the client never verified the server's identity. A is the most dangerous misconception — "encryption is enough." Encryption only protects data from eavesdroppers who don't hold the keys. When the client hands its session key to an impersonator by skipping validation, encryption offers zero additional protection. B invents a false asymmetry; both request and response traffic flow through the tester's relay, so neither direction is protected. D is simply wrong — TLS has no built-in mechanism to detect or flag relayed connections; two separate sessions are perfectly normal from the protocol's perspective. Remember this pattern: encryption without authentication = false security. On any exam question where a client "accepts any certificate," assume MitM is possible and encryption alone means nothing.

Question 9

A cloud key-management service performs automatic annual rotation for a key used in envelope encryption. The service creates a new key-material version for future encryption operations and retains older versions so existing ciphertext can still be decrypted. An auditor concludes that rotation proves all historical data was re-encrypted during the year.

How should the auditor's conclusion be evaluated?

  1. It is correct because key rotation necessarily rewrites every ciphertext object with the newest key-material version.
  2. It is incorrect because rotation can change the version used for new encryption without re-encrypting historical ciphertext. (correct answer)
  3. It is correct because retaining older key versions causes existing ciphertext to adopt the newest version automatically.
  4. It is incorrect because rotating an encryption key permanently prevents decryption of all data created before rotation.
Explanation: Whenever you see a question about key rotation and envelope encryption, focus on what rotation actually changes versus what it leaves untouched. Key rotation is a lifecycle management operation — it does not automatically trigger re-encryption of existing data. In envelope encryption, a Key Encryption Key (KEK) wraps individual Data Encryption Keys (DEKs), which in turn encrypt the actual data. When a cloud KMS rotates a key, it generates a new key-material version and designates it as the default for future encryption operations. Critically, all previously encrypted ciphertext remains protected by whichever key version was active when it was created. Older versions are retained precisely so that existing ciphertext can still be decrypted on demand — but those ciphertext objects are never silently rewritten. The auditor's conclusion is therefore wrong: rotation updated the key used going forward, but historical data was not re-encrypted unless the organization explicitly initiated a re-encryption campaign. Answer B captures this exactly. Answer A is wrong because rotation does not rewrite existing ciphertext — that would require an active, separate re-encryption job against every stored object, which is expensive and must be deliberately triggered. Answer C describes a fictitious automatic adoption process; retaining old key versions is purely for backward-compatible decryption, not for migrating ciphertext to newer versions. Answer D is wrong in the opposite direction — rotation does not destroy decryption capability for old data, because older key versions are intentionally preserved. A useful rule of thumb: rotation = new default version for encryption; it does not equal re-encryption. On exam questions, watch for language that conflates "key rotation" with "data re-encryption" — they are separate, independent operations.

Question 10

An organization will archive highly sensitive files with a cloud storage provider. Its requirement states that no storage-provider service or storage-provider administrator should be able to obtain plaintext, even if the provider's storage account and managed key service are compromised.

Which design most directly satisfies this requirement?

  1. Enable provider-managed server-side encryption and restrict access to the storage account through private endpoints.
  2. Use a customer-created key in the provider's key service and grant the storage service permission to decrypt it.
  3. Use HTTPS for every transfer and rely on the provider to encrypt each file after receiving it.
  4. Encrypt files before upload and retain the decryption keys in a system outside the storage provider's control. (correct answer)
Explanation: When a question asks who can access plaintext "even if the provider is compromised," you're being tested on the concept of client-side encryption versus provider-controlled encryption. The key question to ask yourself is: at what point does encryption occur, and who holds the keys? If encryption happens before data ever reaches the provider — and the keys live in a system the provider cannot touch — then a compromised provider account, key service, or administrator gains nothing but ciphertext. This is exactly what D describes. The organization encrypts files locally and stores keys in an environment entirely outside the provider's infrastructure. No provider-side compromise can expose plaintext because the provider never had access to it. A is wrong because private endpoints only restrict network access to the storage account. They do nothing to limit what a compromised administrator or key service can see once they're inside. The data is still decryptable by the provider. B is a common trap. Customer-created keys sound like customer control, but when those keys are stored in the provider's key service and the storage service has permission to decrypt, the provider's infrastructure still touches plaintext during decryption. A compromised key service breaks this model entirely. C only protects data in transit. HTTPS terminates at the provider's endpoint, after which the provider receives and stores plaintext (or encrypts it themselves). This offers zero protection against a compromised provider. Study tip: Watch for the phrase "even if the provider is compromised" — it's a signal that only client-side encryption with externally held keys satisfies the requirement. Any solution where the provider manages keys or performs decryption will fail this test.