CCNA Data Protection Questions

To encrypt traffic for the entire path, the ALB must terminate the client-facing TLS connection on an HTTPS listener and then originate a new TLS session to each registered target using an HTTPS target group. This ensures the request is decrypted only inside the ALB and re-encrypted before traversing any network segments to the EC2 instances. Both the listener and the target group certificate must be trusted, and health checks also run over HTTPS, maintaining encryption from edge to backend.

To encrypt an existing unencrypted database, you must provision a new DB instance with the StorageEncrypted flag set to true, using either the AWS Management Console, the AWS CLI (--storage-encrypted), or an SDK. You can choose the default aws/rds KMS key or a custom customer-managed key. After the encrypted instance is available, migrate the data from the original instance, for example by restoring an encrypted snapshot or using a logical export/import.

Seeing `SSEAlgorithm: AES256` in the bucket encryption response means default encryption is enabled with SSE-S3, where Amazon S3 manages the encryption keys. This configuration causes new objects written to the bucket to be automatically encrypted at rest with 256-bit AES using S3-managed keys, and the setting is stored as a bucket-level default rather than applied individually per object.

When the destination bucket for S3 server access logs uses SSE-KMS, the S3 log delivery service (logging.s3.amazonaws.com) must be explicitly allowed to use that KMS key to encrypt the log objects it writes. This is done by adding a bucket policy on the destination bucket that grants kms:GenerateDataKey and kms:Encrypt (as well as s3:PutObject) to the log delivery service. Additionally, the KMS key policy must also allow this service principal to use the key; otherwise, log delivery will fail with an access denied error. This is a required step, so this is the correct answer.

AWS DMS has native support for SSL/TLS encryption between the replication instance and both the source and target endpoints. For each endpoint, you can specify an SSL mode (e.g., require for Oracle, SQL Server, and PostgreSQL, or verify-ca for Aurora MySQL) so that all data transferred between the database and DMS is encrypted in transit. With SSL enabled, DMS negotiates an encrypted connection directly with the database engines, ensuring data is protected without relying on additional VPN or network manipulation. This is the most direct and appropriate way to encrypt migration traffic in AWS DMS.

An AWS Site-to-Site VPN uses IPsec to encrypt traffic between the on-premises data centre and AWS, satisfying the in-transit encryption requirement for data moving to Amazon S3. IPsec provides cryptographic protection at the network layer, covering all traffic over the connection without application changes.

If the policy permits PutObject without requiring the s3:x-amz-server-side-encryption header or a condition that forces encryption, clients can upload objects in plaintext to S3. Although the company uses KMS for encryption, that KMS key is only used when the upload explicitly requests SSE-KMS or the bucket has default encryption and the client doesn't override it. Without an explicit Deny for unencrypted uploads, some objects may remain unencrypted at rest, defeating the company's stated security intent.

A KMS key policy that explicitly lists the IAM role as Principal, optionally with a condition like aws:PrincipalArn, correctly restricts kms:Decrypt to that role. Key policies are the authoritative control for a KMS key, and when they grant access to a specific principal, IAM policies are not required for that identity to decrypt. This is the recommended approach when the desired access is limited to a particular role and you want the key policy to be self-contained and auditable. Since the key policy is evaluated first and any IAM allow is subordinate to it, this configuration unambiguously enforces the intended restriction.

Configure the key policy with a Deny statement that uses the aws:PrincipalAccount condition to block any principal whose account ID does not match the expected account. Since the key policy is the authoritative resource-based policy for the KMS key, an explicit deny overrides any IAM permissions in another account and prevents cross-account EBS volume or snapshot sharing. This directly enforces the desired account boundary.

Setting `require_secure_transport=1` on MySQL or `rds.force_ssl=1` on PostgreSQL in the RDS parameter group makes the server reject any non-TLS connection, explicitly enforcing encryption at the database layer. This server-side configuration is authoritative: only TLS-enabled clients with the appropriate CA certificate can connect, so plaintext traffic is refused regardless of client-side settings.

SSE-S3 encrypts each object with a unique key, itself encrypted by a regularly rotated root key managed entirely by AWS, using AES-256. It satisfies data-at-rest protection with no key management overhead, applied by default to every uploaded object.

Configuring an HTTPS listener and an HTTPS target group encrypts traffic at both hops, including the ALB-to-target leg. This satisfies the requirement for in-transit encryption between load balancer and targets, since the default HTTP target protocol leaves that segment unencrypted.

SSE-C allows you to provide your own encryption keys in S3 API request headers, and S3 uses them for AES-256 encryption/decryption but never stores the key material, giving you full control over the key lifecycle. Storing those keys in AWS Secrets Manager adds secure storage, centralizes access control, and enables programmatic retrieval for uploads/downloads while keeping the key material customer-owned. This directly satisfies a bring-your-own-key requirement without the overhead of client-side encryption, though you must use HTTPS and supply the key on every request.

A key policy is the resource-based policy that governs access to a KMS key. Adding an explicit Deny statement for the kms:ScheduleKeyDeletion action prevents any principal—including IAM users, roles, or the account root—from scheduling the key for deletion, because an explicit Deny overrides any Allow. This makes the key effectively non-deletable through the normal API, assuming the key policy itself cannot be altered by unauthorized principals.

CloudTrail log file integrity validation delivers a tamper-evident chain by hashing each log file with SHA-256, digitally signing the digest with a private key, and storing those digest files in the same delivery bucket. During validation, CloudTrail compares file hashes and signatures, so any modification, deletion, or replacement of delivered logs is detected, even if someone has access to the bucket. This directly addresses the requirement to prove that CloudTrail logs have not been altered.

Adding a bucket policy with a condition that denies requests when `aws:SecureTransport` is `false` enforces HTTPS by rejecting any HTTP or unencrypted requests at the S3 API level. This satisfies the stem’s requirement to ensure encryption is enforced for data in transit, as the policy explicitly blocks non-HTTPS traffic regardless of the client’s protocol choice.

Using a customer managed KMS key with EBS encryption is the correct approach because it gives you full control over the key lifecycle, key policy, and permissions, allowing you to restrict access to specific principals or services. EBS encryption uses envelope encryption where a CMK generates a data key to encrypt the volume, and you can audit key usage through CloudTrail. This provides a native, seamless encryption solution for data at rest without requiring application changes, and it supports compliance requirements that mandate customer-controlled keys.

Enabling AWS CloudTrail to log KMS API calls provides a detailed audit trail of every kms:Encrypt, kms:Decrypt, GenerateDataKey, and other KMS operation, including the IAM principal, source IP, and request timestamp. This is a detective control that lets security engineers monitor and investigate who is using the key and when, which is the correct approach when the goal is visibility into KMS usage. CloudTrail does not prevent or allow operations, so it complements, rather than replaces, access-control policies.

This is the correct policy because it denies all S3 actions (s3:*) when the request is not using secure transport, as indicated by aws:SecureTransport being false. By using Deny on the entire action set and the Bool condition, it ensures that any request over HTTP is rejected, while HTTPS requests remain unaffected. This is the standard AWS recommended pattern for enforcing encryption in transit on an S3 bucket.

DynamoDB encryption at rest integrates with AWS KMS, allowing the use of customer managed keys. This provides control over key policies, enables auditing via AWS CloudTrail, and supports automatic rotation. It requires minimal operational effort because DynamoDB manages the encryption and decryption transparently, and KMS handles key management, meeting all requirements.

The aws:SecureTransport condition key evaluates the request's protocol, so denying when it is false blocks any plain HTTP request to the bucket. This enforces TLS for data in transit between the on-premises application and S3.

Enabling automatic key rotation in AWS KMS for the customer-managed KMS key used by RDS meets the data protection requirement with minimal operational overhead. AWS KMS rotates the cryptographic backing key each year while keeping the same KMS key ID, so the RDS instance, its storage, and all future snapshots continue using the same key reference with zero manual intervention. Existing data remains decryptable via the previous backing key, and new writes automatically use the new backing key, providing continuous protection.

Multi-Region keys are a set of interoperable KMS keys in different Regions that share the same key material and key ID. They allow data encrypted in one Region to be decrypted in another without re-encryption. Creating a primary key and a replica in the second Region provides availability and low-latency access, meeting all requirements.

To satisfy a 90-day rotation requirement, you must perform manual key rotation by creating a new KMS key every 90 days and then re-encrypting your EBS volumes with that new key. A typical scripted approach creates an encrypted snapshot of each volume using the new key, creates a new volume from that snapshot, and attaches it to the instance after detaching the old volume. This changes the actual key ID and re-encrypts the volume data, which is the only way to meet a sub-yearly rotation schedule because KMS automatic rotation only occurs every year.

KMS allows you to create a customer managed key with your own cryptographic key material rather than using AWS-generated bytes. This import capability is essential for organizations needing to retain exclusive control over key material to satisfy regulatory or compliance mandates. However, once you import key material, you cannot enable automatic rotation of that KMS key, so you must plan for manual rotation or replacement.

AWS Site-to-Site VPN is the correct service because it builds an encrypted IPsec tunnel between a customer gateway and a virtual private gateway, encrypting all traffic in transit across the public internet. It uses IKE for key exchange and IPsec protocols like ESP to provide confidentiality and integrity for every packet. This directly satisfies the requirement to ensure all data transferred between the company's network and AWS is protected.