What is encryption in the cloud? At rest and in transit

The plain idea: plaintext, key, ciphertext

Strip away the jargon and encryption is one operation. You start with plaintext — data anyone could read. An encryption algorithm combines it with a key — a large secret number — to produce ciphertext: output that is meaningless to anyone who inspects it. With the right key, the transformation runs in reverse and the plaintext returns; without it, the ciphertext stays noise. The algorithms are public and heavily studied; all of the secrecy lives in the key.

That last point carries the whole subject. Encryption does not make data impossible to read — it makes reading data equivalent to possessing the key. Protecting information therefore reduces to protecting keys, which is why everything later in this guide is ultimately about key management. If an attacker copies your encrypted storage but not your keys, they have taken nothing of value; if they obtain the keys, the encryption might as well not exist.

Symmetric and asymmetric encryption, simply

Symmetric encryption uses one key for both directions: the same secret encrypts and decrypts. It is fast and well suited to bulk data, which is why the contents of disks, databases and storage buckets are protected symmetrically. Its awkwardness is distribution — both parties need the same secret, and you cannot safely send a secret over a channel you have not yet secured.

Asymmetric encryption solves that with a mathematically linked pair: a public key anyone may have and a private key that never leaves its owner. What one encrypts, only the other can decrypt — so a stranger can encrypt a message to you with your public key, and only your private key can open it. The pair also enables digital signatures, proving who sent something and that it was not altered. It is slower, so real systems combine the two: TLS — the protocol behind the padlock in your browser — uses asymmetric cryptography to verify the server’s identity and agree a shared secret, then switches to symmetric encryption for the actual traffic. Handshake asymmetric, bulk data symmetric — that division of labour is worth remembering, and exams like it.

At rest and in transit: the two jobs

The two forms protect against different threats:

• Encryption at rest protects stored data — the contents of object storage, database volumes, disks and backups. If a physical drive is stolen or decommissioned carelessly, or someone obtains a raw copy of the stored bytes, they hold ciphertext. Cloud examples: enabling encryption on an S3 bucket or an EBS volume in AWS, or on an Azure storage account or managed disk — in current platforms this is typically a default or a single setting.
• Encryption in transit protects data as it moves — between your users and your services, and between services internally. It prevents eavesdropping and tampering on the wire. The workhorse is TLS: HTTPS for web traffic, TLS connections to databases and APIs, and encrypted links between components inside your own architecture.
• You need both, because each is useless against the other’s threat: TLS does nothing for a stolen disk, and disk encryption does nothing for intercepted traffic. “Encrypt in transit and at rest” is the standard baseline in AWS and Azure guidance alike, and the reflexively correct posture in exam scenarios.

Key management: the actual hard part

Because platforms have made enabling encryption easy, the substantive questions are all about keys: where they are stored, who may use them, how usage is audited, and how they are rotated. Cloud providers answer with managed key services — AWS Key Management Service (KMS) and Azure Key Vault — which generate and store keys in hardened infrastructure, enforce IAM-style permissions on every use, log each operation for audit, and handle rotation. Underneath sit hardware security modules (HSMs): tamper-resistant physical devices designed so keys can be used for cryptographic operations but never extracted. Both providers also offer dedicated HSM-backed tiers for organisations whose compliance regimes demand them.

The recurring design choice is who controls the keys. With provider-managed keys, the platform creates and manages everything invisibly — least effort, least control. With customer-managed keys, you create the key in KMS or Key Vault yourself: you set the policy saying which identities and services may use it, you control rotation, you can audit every use, and you can revoke it — a lever the provider-managed option does not give you. Some organisations go further and generate key material outside the cloud before importing it. The trade-off is uniform: more control means more responsibility, and the right choice depends on your compliance and trust requirements. Exam questions probe exactly this ladder — recognising which key arrangement a scenario’s requirements demand is a staple of security papers.

What encryption cannot do

An honest limit: encryption is necessary but not sufficient. It protects data from those who lack the keys — but authorised access paths go around it, not through it. If an application has permission to read a database, it decrypts transparently, and so does an attacker who compromises that application. If an IAM identity is allowed to read a bucket, the bucket’s encryption is invisible to it; a leaked credential defeats every layer of encryption behind it. Most real cloud data exposures are exactly this shape — not broken cryptography, but permissions that let the wrong party in the front door.

Encryption and access control therefore answer different questions: access control decides who may reach the data through legitimate paths, and encryption protects it on every other path — stolen hardware, intercepted traffic, leaked raw copies. Our identity and access management explainer covers the first half; a defensible design needs both, and treating an “encrypted” label as a substitute for tight permissions is one of the classic cloud security mistakes.

Your job in the model — and on the exams

Under the shared responsibility model, the provider supplies the machinery — the algorithms, the key services, the HSMs — but enabling encryption and configuring it sensibly is the customer’s job. Choosing to encrypt, selecting provider- or customer-managed keys, writing the key policies, enforcing TLS and deciding who may decrypt are all settings in your hands, which places them squarely on your side of the line our shared responsibility model explainer draws. Unencrypted data in the cloud is a configuration choice, not a provider failure.

For certification study, encryption is tested everywhere and deepest in security exams. AWS Cloud Practitioner (CLF-C02) expects the concepts: at rest versus in transit, and what KMS is for. The Security – Specialty (SCS-C03) goes to full depth — key policies, customer- versus provider-managed keys, rotation, envelope encryption and TLS enforcement recur throughout its data-protection domain. The Azure Administrator Associate (AZ-104) covers storage encryption and Key Vault from the operations side. Anchor the vocabulary from this guide, then take each exam’s specifics — which services, which key options, which defaults — to the per-cert revision lessons on this site.