Data encryption protects your information by converting it into an unreadable format, so even if someone steals the file or intercepts the network traffic, they see only gibberish. For the AWS Certified Data Engineer Associate DEA-C01 exam, you must understand two distinct scenarios: protecting data stored on disk (at rest) and protecting data moving across networks (in transit). AWS Key Management Service (KMS) and AWS Certificate Manager (ACM) are the primary services that make this possible, and knowing how they work together is essential for passing the exam.
Jump to a section
A simple way to picture Data Encryption at Rest and in Transit with AWS KMS and ACM
Your home office, where you keep your most important documents—birth certificates, property deeds, a will. You decide to lock these in a personal safe (at-rest encryption). The safe has a unique key (a customer master key, or CMK, managed by AWS KMS) that only you control. You can set rules: only certain family members can open it, and only between 9 AM and 5 PM.
Now you need to send a copy of your property deed to a lawyer across town. You don't just toss it in the mail—anyone could intercept it. Instead, you call a bonded courier service (AWS Certificate Manager, or ACM). They provide a tamper-proof, sealed envelope (a TLS/SSL certificate). You place the document inside, seal it, and the courier hand-delivers it. The lawyer verifies the seal is intact and uses their own key to open it (in-transit encryption). The envelope itself is also locked with a temporary key (a data key) that was generated by your safe (KMS) just for this trip. Once delivered, that temporary key is destroyed.
The key insight: your safe protects the document when it's sitting still, and the courier envelope protects it while moving. KMS manages the safe and the temporary keys; ACM manages the courier's envelopes. Neither works alone—you need both for complete protection.
Encryption is the process of transforming readable data (plaintext) into an unreadable format (ciphertext) using a cryptographic algorithm and a secret key. Only someone with the correct key can reverse (decrypt) the ciphertext back into plaintext. For data engineers on AWS, encryption applies in two main areas: when data is stored (at rest) and when data is moving (in transit).
Data at rest includes anything stored persistently: Amazon S3 buckets, Amazon EBS volumes (virtual hard drives for EC2 instances), Amazon RDS databases (relational databases), and Amazon DynamoDB tables (NoSQL databases). Without encryption, if someone gains physical access to the disk drive or a backup tape, they can read the data directly. With encryption, the file system or database engine encrypts every byte before writing it to disk, and decrypts it on the fly when a legitimate user requests it.
Data in transit covers all communication between systems: an application sending an API request to an S3 bucket, a web browser connecting to a web server, or two databases replicating data across regions. Without encryption, an attacker on the same network (think of a coffee shop Wi-Fi or a compromised router) can eavesdrop and capture everything—this is called a man-in-the-middle attack. Encryption in transit typically uses the Transport Layer Security protocol (TLS, formerly known as SSL). When you visit a website with HTTPS, the 'S' means your browser and the server have negotiated a TLS session, and all data exchanged is encrypted.
AWS Key Management Service (KMS) is a managed service that creates, stores, and controls access to encryption keys. It does not perform the actual encryption of your data—that happens in your application or within the AWS service you are using (e.g., S3, RDS). What KMS does is provide the keys that those services use. The most important concept in KMS is the customer master key (CMK). A CMK is a logical object that contains the key material (the actual secret bits), a unique identifier, and a set of permissions that control which users or services can use the key for encryption or decryption. You can create CMKs in KMS, or you can import your own key material from an existing on-premises system (bring your own key, or BYOK).
KMS also generates data keys, which are temporary symmetric keys used directly by applications to encrypt data. The process works like this: you tell KMS 'I need a data key', KMS returns two versions of the same key—a plaintext version (used immediately for encryption) and an encrypted version (wrapped by your CMK, stored alongside the data). The plaintext key is used to encrypt the data and is then discarded or stored only in memory temporarily. The encrypted version is stored with the ciphertext. When you need to decrypt, the application sends the encrypted data key to KMS, which uses the CMK to unwrap it, returns the plaintext key, and the application decrypts the data. This means the CMK itself never leaves KMS, and the data key is only usable for a short time.
AWS Certificate Manager (ACM) handles the other half of the puzzle: it provisions, manages, and deploys TLS/SSL certificates for use with AWS services like Elastic Load Balancing (ELB), Amazon CloudFront (content delivery network), and Amazon API Gateway (for APIs). A TLS certificate is a digital document that binds a cryptographic key pair to an organisation or domain name, verified by a trusted third party called a certificate authority (CA). When a client connects to an ACM-protected endpoint, the server presents its certificate, the client verifies that the certificate was issued by a known CA and matches the domain name, and then both sides use the certificate's public key to negotiate an encrypted session. ACM automatically renews these certificates, so you do not have to track expiration dates.
For the DEA-C01 exam, you need to know that KMS is the correct service for encryption at rest (managing CMKs and data keys), and ACM is the correct service for encryption in transit (managing TLS certificates). However, they often work together. For example, when you enable encryption for an Amazon RDS database, RDS uses KMS to generate and manage the keys that encrypt the database storage, but the application connecting to that database over the internet should use ACM-issued certificates to encrypt the connection itself. A common exam scenario: 'A company wants to encrypt all data stored in an S3 bucket and also ensure that data transferred between EC2 instances and the S3 bucket is encrypted. What combination of services should be used?' The answer is KMS for the bucket-level encryption (server-side encryption with KMS, or SSE-KMS) and ACM for the TLS connection (the EC2 instance can use an ACM certificate to establish an HTTPS connection to the S3 endpoint).
Key security concepts to remember. Symmetric encryption uses the same key for encryption and decryption (fast, used for bulk data). Asymmetric encryption uses a public key for encryption and a private key for decryption (slower, used for key exchange and digital signatures). KMS supports both, but data keys are symmetric. Rotation is the process of replacing an existing key with a new one; KMS can automatically rotate CMKs every year. Envelope encryption refers to the practice of using a master key (CMK) to encrypt data keys, which in turn encrypt the actual data—this allows you to encrypt huge amounts of data without the performance penalty of using the CMK directly. The exam will expect you to know these terms and how they fit together.
Create a Customer Master Key (CMK) in KMS
Log in to the AWS KMS console and choose 'Create a key'. Select a symmetric key (used for most encryption tasks). Give it a meaningful alias like 'app-data-key'. Define a key policy that specifies which IAM roles or users can use the key. This step is the foundation for all at-rest encryption because the CMK will be used to generate and encrypt data keys used by other services.
Enable Server-Side Encryption on an S3 Bucket Using SSE-KMS
In the S3 bucket properties, choose 'Default encryption' and select 'SSE-KMS'. From the dropdown, pick the CMK you created. Now any object uploaded to this bucket will be automatically encrypted at rest using a data key generated by KMS and wrapped by your CMK. This ensures that even if someone downloads the object file directly, they cannot read it without the permissions to decrypt using the CMK.
Encrypt an Amazon RDS Database Instance with KMS
When creating a new RDS instance (or modifying an existing one), enable 'Encryption' and choose the same CMK. This encrypts the database's underlying storage, automated backups, read replicas, and snapshots. Note that after encryption is enabled, you cannot disable it—you must take a snapshot, copy it to an unencrypted one, and restore. This step protects data at rest inside the database.
Request a TLS Certificate from ACM for a Public-Facing Application
In ACM, choose 'Request a public certificate' and enter your domain name (e.g., 'app.shopsimple.com'). Choose DNS validation (simpler) or email validation. After validation, ACM issues and automatically renews the certificate. This certificate will be used by an AWS service like a load balancer to encrypt traffic between clients and your application.
Attach the ACM Certificate to an Application Load Balancer (ALB) for HTTPS
Create an ALB and configure a HTTPS listener. In the listener settings, select the ACM certificate you requested. The ALB now terminates TLS connections from clients: clients connect via HTTPS, the ALB decrypts the traffic, inspects it (for routing rules), and then forwards it to EC2 instances (which can be over HTTP or HTTPS). This ensures all data in transit between the client and the ALB is encrypted.
Configure EC2 Instances to Encrypt Traffic to S3 Using the AWS SDK
In your application code (running on EC2), when using the AWS SDK to upload objects to S3, specify the endpoint as 'https://' (the default). The SDK automatically uses the system's trust store to verify S3's TLS certificate (issued by Amazon, not your ACM). This encrypts the data in transit between EC2 and S3. Additionally, S3 will encrypt the object at rest using your KMS CMK because the bucket has SSE-KMS enabled.
Imagine you are a data engineer at an online retail company called ShopSimple. The company uses Amazon S3 to store customer order histories, Amazon RDS for MySQL to store customer account details, and EC2 instances running a web application that processes payments. The security team has mandated that all customer data must be encrypted both at rest and in transit.
Here is what you actually do step by step:
First, you create a customer master key (CMK) in KMS specifically for the e-commerce application. You give it a friendly name like 'shop-simple-cmk'. You also set a key policy—a JSON document that defines exactly which IAM roles and users can use the key. For example, you allow the application's EC2 instance role to use the key for encryption and decryption, but you deny the same role from deleting the key.
Next, you enable encryption on the S3 bucket. In the S3 console, you select 'SSE-KMS' (server-side encryption with KMS) and choose your new CMK. Now, every object uploaded to that bucket is automatically encrypted before being written to disk. The S3 service handles the decryption transparently when a legitimate user or service reads the object.
For the RDS database, during the initial launch or via a modification, you enable encryption by selecting the same KMS key. This encrypts the database's storage, automated backups, read replicas, and snapshots. The database engine itself is never aware of the encryption—it's handled at the storage layer.
For the web application connecting to RDS, you need encryption in transit. You request a public TLS certificate from ACM (it is free for AWS resources). You then attach that certificate to an Application Load Balancer (ALB) that sits in front of your EC2 instances. The ALB terminates the TLS connection—clients connect to the ALB over HTTPS, and the traffic between the ALB and the EC2 instances can also be encrypted using a self-signed certificate or a private certificate from ACM. The ALB uses the ACM certificate to present a valid TLS handshake to the client's browser.
Finally, you configure the EC2 instances to encrypt traffic to S3. When the application writes a file to the S3 bucket using the AWS SDK, you set the endpoint to use HTTPS. The SDK uses the system's trust store (which inherently trusts Amazon's public certificate) to establish a TLS session with S3. The data is encrypted in transit using that session, and then at rest using the KMS key.
A real-world complication: the company also has a partner that sends data via a legacy SFTP (SSH File Transfer Protocol) server. You would set up an AWS Transfer Family server that uses ACM to bring your own TLS certificate for encrypting the control channel, and you can still use KMS to encrypt the files after they land in S3.
On the exam, scenario-based questions will ask you to pick the correct service for each task. For example: 'A data engineer needs to encrypt files in an S3 bucket but wants to control access to the encryption key separately from the bucket permissions. Which option should be used?' The answer is SSE-KMS, not SSE-S3 (where Amazon manages the key) or client-side encryption (where you encrypt before uploading). Another common question: 'An application uses an AWS SDK to encrypt data locally before storing it in S3. Which AWS service generates the encryption key used by the SDK?' The answer is KMS, because the SDK calls GenerateDataKey to get a plaintext and encrypted key, uses the plaintext key for encryption, stores the encrypted key alongside the data, and later calls Decrypt on KMS to unwrap it for reading.
The DEA-C01 exam tests your understanding of encryption services in two main question formats: scenario-based multiple choice and matching/ordering tasks. Approximately 5-8 questions will directly involve KMS, ACM, or the differences between encryption at rest and in transit. You must be able to identify the correct service for a given requirement without hesitation.
Key areas the exam focuses on:
Difference between server-side encryption (SSE-S3, SSE-KMS, SSE-C) and client-side encryption.
When to use each SSE option: SSE-S3 for simple S3 encryption where S3 manages the key; SSE-KMS when you need separate permissions, audit trails, or automatic key rotation; SSE-C when you want to supply your own key but have AWS do the encryption.
KMS key types: Customer managed key (created by you, most control), AWS managed key (created automatically by an AWS service for your account, less control), and AWS owned key (shared across accounts, least control). The exam will ask which key type provides the most control or is the most cost-effective.
Key policies versus IAM policies: both can grant permissions to use a KMS key, but key policies are attached directly to the key and are always evaluated. The exam tests the concept of 'granting cross-account access'—you need a key policy that allows another account to use the key.
Automatic key rotation: KMS can automatically rotate customer managed keys once per year (not AWS managed keys). The exam may ask whether rotation re-encrypts existing data (answer: no, it only affects new encryption calls).
Envelope encryption: understand that a CMK encrypts data keys, not the actual data. Data keys encrypt the data. This is why decryption involves two steps: decrypt the data key, then decrypt the data.
ACM certificate types: public certificates (for public-facing websites, automatically validated by AWS), private certificates (for internal resources, require a private certificate authority). The exam tests when to use each.
ACM integration: ACM certificates integrate with Elastic Load Balancing, CloudFront, API Gateway, and AWS Elastic Beanstalk. You cannot export the private key of an ACM-managed certificate (it is stored securely in ACM). If you need to install a certificate on an EC2 instance directly, you must use a different source (like a self-signed certificate or a certificate from a third-party CA).
Encryption in transit for S3: you can enforce HTTPS-only access using a bucket policy that denies requests without a secure transport (like aws:SecureTransport condition key). The exam loves this constraint.
KMS key deletion: you cannot delete a CMK immediately—you must schedule deletion (minimum 7 days, maximum 30 days). During this period, the key is disabled, and any service using it will fail decryption requests. The exam tests the implication: if you schedule key deletion before all encrypted data is re-encrypted under a new key, that data becomes permanently unreadable.
Common traps:
Confusing 'server-side encryption' with 'client-side encryption'. The correct answer for 'encrypt data before sending to S3' is client-side encryption, not SSE-KMS.
Thinking ACM encrypts data at rest—it does not, it only handles TLS certificates for in-transit encryption.
Assuming KMS can be used to encrypt data directly in bulk—it cannot; KMS has a request rate limit and is designed for key management, not bulk encryption.
Picking 'SSE-S3' when the scenario requires separate permissions for the key (e.g., an auditor can see the bucket but cannot decrypt objects). SSE-S3 gives you no such granularity; SSE-KMS does.
Memorise these exact concepts:
KMS: GenerateDataKey, Encrypt, Decrypt, ReEncrypt, CMK, key policy, envelope encryption.
ACM: RequestCertificate, DescribeCertificate, GetCertificate, TLS, public vs private CA.
SSE-KMS bucket encryption requires the s3:PutObject permission along with kms:GenerateDataKey and kms:Decrypt.
An encrypted RDS instance cannot be made unencrypted—you must take a snapshot, copy it to an unencrypted snapshot, and restore from that copy.
CloudWatch Logs can be encrypted with KMS using a key that the logs service can access (via a key policy).
Data at rest means stored data (S3, EBS, RDS, DynamoDB), encrypted using KMS keys or native server-side encryption options like SSE-S3, SSE-KMS, or SSE-C.
Data in transit means data moving across a network, encrypted using TLS certificates managed by ACM or other sources.
AWS KMS handles key management and provides CMKs for at-rest encryption; it does not perform the encryption itself but generates data keys used by services.
Envelope encryption uses a CMK to encrypt a data key, which then encrypts the actual data—this improves performance and reduces CMK usage costs.
ACM provisions and automatically renews TLS certificates for use with AWS services such as ELB, CloudFront, and API Gateway, but it cannot encrypt storage volumes.
You cannot export the private key of an ACM-managed public certificate; if you need the private key (e.g., for an on-premises server), you must obtain the certificate from another CA or use ACM Private CA.
When you enable encryption on an S3 bucket, existing objects remain unencrypted; you must copy them to apply encryption.
KMS key rotation (automatic or manual) does not re-encrypt existing data—it only affects new encryption calls, and the old backing key is retained for decryption.
These come up on the exam all the time. Here's how to tell them apart.
Server-Side Encryption with KMS (SSE-KMS)
You control the CMK and can set separate permissions (key policy) for using the key.
Audit trails via AWS CloudTrail for every key usage.
Supports automatic key rotation (once per year) for the CMK.
Server-Side Encryption with S3-Managed Keys (SSE-S3)
S3 manages the encryption key entirely; you have no visibility or control.
No separate audit of key usage—only S3 API calls are recorded.
Key rotation is handled by S3 automatically, but you cannot change the schedule.
Encryption at Rest
Protects data stored on disk: S3, EBS, RDS, DynamoDB, etc.
Uses encryption keys (CMKs) from KMS or native server-side encryption.
Does not protect data while it is being transmitted over a network.
Encryption in Transit
Protects data moving across networks: between clients and servers, or between AWS services.
Uses TLS/SSL certificates from ACM or other certificate authorities.
Does not protect data after it has been written to storage at the destination.
ACM Public Certificate
Issued for public-facing domains; trusted automatically by browsers and operating systems.
Validation required (DNS or email) to prove domain ownership.
Cannot export the private key; certificate is used only within integrated AWS services.
ACM Private Certificate (Private CA)
Issued for internal-only resources (e.g., internal microservices); not trusted by public CAs.
You control the issuing CA entirely; no public validation needed.
The private key can be exported for use outside AWS (e.g., on-premises servers).
Mistake
Encrypting data in transit automatically encrypts it at rest as well.
Correct
Encryption in transit (TLS) protects data only while it is moving across the network. Once data reaches the destination server, it is stored in plaintext unless separate at-rest encryption is applied (e.g., via KMS or S3 SSE).
The term 'encrypted connection' sounds like a single holistic protection, but in reality TLS ends at the server, and the data is then written to disk. Beginners conflate the two layers.
Mistake
You can use ACM certificates directly on EC2 instances to encrypt the instance storage volume.
Correct
ACM cannot be used to encrypt EBS volumes or instance storage. ACM provides TLS certificates for network encryption (in transit). For at-rest encryption of EBS volumes, you use KMS with an EBS-managed key or a customer managed key.
Both KMS and ACM deal with encryption, and beginners assume 'certificate = encryption = everything'. The distinction between network-level and storage-level encryption is subtle but critical for the exam.
Mistake
When you enable encryption on an existing S3 bucket, all existing objects are automatically encrypted.
Correct
Enabling default bucket encryption (SSE-S3, SSE-KMS, or SSE-C) only applies to new objects uploaded after the setting is turned on. Existing objects remain unencrypted unless you explicitly copy them (e.g., using aws s3 cp with the --sse flag) or set a lifecycle policy to rewrite them.
Bucket properties feel like a switch that should affect everything inside, but encryption is applied per-object at the time of upload. Beginners confuse the bucket-level setting with an object-level operation.
Mistake
KMS automatically re-encrypts existing data when a customer master key is rotated.
Correct
KMS rotation creates a new backing key (the actual cryptographic material) for the CMK, but any data encrypted under the old key remains encrypted under that old key. The CMK's metadata still points to the old key for decryption requests. Existing data is not touched—only new encryption operations use the new key.
The word 'rotation' sounds like you are swapping out the lock on a door and turning all the keys, but in security, you keep both old and new keys available so you can still decrypt old data. This nuance is a common exam trap.
Mistake
If you schedule KMS key deletion, you can restore the key immediately within the waiting period.
Correct
You cannot restore a key once you confirm deletion. During the pending deletion period (7-30 days), the key is in a 'Pending Deletion' state and is disabled; you can cancel the deletion only before the scheduled date. After that date, the key and all data encrypted under it become permanently unrecoverable.
Many users think the waiting period is a grace period for restoration, but it is actually a cooldown to prevent accidental deletion and to allow you to re-encrypt data under another key. The key is effectively dead during that time.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
SSE-S3 uses keys managed entirely by S3; you cannot control the key or view audits. SSE-KMS uses a customer master key (CMK) in KMS, giving you separate permissions and audit trails. SSE-C lets you provide your own encryption key, which S3 uses and then discards, but you must manage the key yourself.
Yes, you can reuse a single CMK across multiple services (S3, RDS, EBS, etc.). However, each service uses the CMK to generate its own data keys, so the underlying data is encrypted with different data keys. Using one CMK simplifies key management, but you lose granular control if you need to revoke access for only one service.
For public certificates, it depends on the validation method. DNS validation can complete in minutes (once the DNS record propagates), while email validation may take hours. ACM automatically renews certificates 60 days before expiration, so you do not need to worry about expiry after the initial setup.
You cannot delete a CMK without scheduling deletion (7-30 day waiting period). During that period, the key is disabled in a 'Pending Deletion' state; any service using it will fail encryption or decryption requests. After the waiting period, the key is permanently deleted, and any data encrypted under it becomes unreadable forever.
No. Default bucket encryption only applies to new objects uploaded after the setting is enabled. To encrypt existing objects, you must copy them (e.g., use the AWS CLI with 'aws s3 cp --sse aws:kms') or use lifecycle policies that rewrite them.
Technically, you can export the certificate if you are using ACM Private CA (which allows certificate export). For public ACM certificates, the private key is not exportable, so you cannot install them directly on an EC2 instance. Instead, you would use a certificate from a third-party CA or generate a self-signed certificate for that purpose.
You've finished Data Encryption at Rest and in Transit with AWS KMS and ACM. Continue through the DEA-C01 study guide to build a complete picture of the exam.
Done with this chapter?