CCNA Data Protection Questions

Enabling automatic rotation in AWS Secrets Manager and specifying a Lambda rotation function is the correct approach. Secrets Manager invokes the Lambda function on a configurable schedule (e.g., every 30 days), and the function follows the rotation protocol—creating a new credential, updating the database user/password, and storing the new value as a version of the secret. This allows applications to automatically retrieve the new credential via the secret ARN while keeping the database credential synchronized, and it supports multi-user or single-user rotation strategies.

The KMS key policy is the resource policy attached to a KMS key and is the authoritative control for access. In AWS KMS, an IAM policy alone does not grant permission; the key policy must explicitly allow the IAM user (or allow the account's IAM policies to take effect) for kms:Decrypt. Because the key policy here lacks such an allowance, the request is denied with AccessDenied even if the IAM identity policy appears permissive. Therefore, the missing key-policy grant for this user is the direct cause of the failure.

The policy's `s3:PutObject` statement carries a `StringNotEquals` condition on `s3:x-amz-server-side-encryption` with value `aws:kms`, so any upload lacking the SSE-KMS header is explicitly denied. This satisfies the stem's constraint by permitting only requests specifying SSE-KMS encryption, blocking SSE-S3 and unencrypted writes.

Enabling EBS encryption by default causes all newly created EBS volumes and snapshots to be encrypted automatically. When no custom key is specified, AWS uses the AWS managed key with alias 'aws/ebs' to perform encryption, which is transparent and requires no additional configuration. This satisfies encryption-at-rest requirements with minimal operational overhead and is the simplest valid option.

A customer managed CMK is the correct choice because the customer controls the key, including its rotation schedule, access policies, and auditability, which meets financial services compliance demands. When you create a DynamoDB table with a customer managed CMK and enable automatic key rotation, DynamoDB uses that key to encrypt the base table and all GSIs automatically, as GSIs inherit the table's encryption settings. This provides unified, customer-controlled encryption with rotation, fully satisfying the requirement.

AWS Site-to-Site VPN creates encrypted IPsec tunnels between an on-premises customer gateway device and an AWS virtual private gateway or transit gateway attachment. It automatically provisions two tunnels for high availability, encrypts traffic as it traverses the public internet, and supports dynamic BGP or static routing. This directly satisfies the requirement to protect data in transit between the on-premises network and the VPC.

Enabling encryption by default for new EBS volumes is a foundational data-at-rest protection control because it automatically encrypts the underlying volume and its snapshots with an AWS KMS key, without requiring per-volume configuration. This prevents raw storage from being accessed if an unauthorized party gains access to the physical media, and it also ensures that any future snapshots derived from these volumes inherit the same encryption, which is mandatory for many compliance frameworks.

AWS CloudTrail records S3 data events such as GetObject and PutObject, capturing the identity, source IP, timestamp and request details for each object-level API call. This satisfies the requirement to audit who accessed which objects, provided data events are explicitly enabled on the trail.

SSE-S3 uses a multi-layer envelope encryption scheme in which Amazon S3 creates a unique data key for each object and encrypts that data key with a S3-owned master key that AWS automatically rotates. The customer needs no key material, no KMS configuration, and no key lifecycle management, making this the straightforward option for delegating key management entirely to AWS. It is the only option listed that relies purely on AWS-managed keys with no customer-controlled key configuration.

Requesting a public certificate from AWS Certificate Manager is the correct, fully managed way to implement HTTPS on an Application Load Balancer. ACM's public certificates are issued by trusted CAs (such as Amazon Trust Services), are free of charge, and are automatically renewed as long as you maintain the required DNS validation or email validation records. After ACM validates your domain, you simply attach the certificate to the ALB's HTTPS listener, and the ALB handles TLS termination. This avoids any self-managed CA infrastructure and is aligned with AWS best practices for securing a web application.

AWS CloudTrail records all KMS API requests as audit events, including both management-plane actions (such as CreateKey, EnableKeyRotation, and DescribeCustomKeyStores) and data-plane operations like Encrypt, Decrypt, and GenerateDataKey. Each CloudTrail event captures the caller's IAM identity, source IP address, key ID, request parameters, and timestamp, and can be delivered to Amazon S3 or CloudWatch Logs for long-term retention and analysis. CloudTrail is therefore the authoritative service for auditing all access to a KMS custom key store or the keys associated with it.

Amazon Macie is a fully managed data security service that uses machine learning and pattern matching to automatically discover, classify, and protect sensitive data stored in S3. It identifies data types such as personally identifiable information (PII), financial data, and credentials, then surfaces findings in dashboards and EventBridge events. For this use case, Macie is correct because it continuously scans and reports on sensitive data without requiring custom tooling or manual inspection.

Creating a cross-Region read replica with encryption enabled gives you a continuously updated, readable copy of the primary database in another AWS Region. RDS automatically replicates changes from the primary using its asynchronous replication engine, and in a disaster you simply promote the replica to a standalone master with a few clicks, minimizing RTO. For encryption, the primary must be encrypted and you specify an AWS KMS key in the destination Region when creating the replica, so the DR copy is encrypted in transit and at rest.

Setting require_secure_transport to 1 in the custom DB parameter group instructs the MySQL server to reject any connection that does not use a secure transport protocol such as TLS/SSL. This enforces encryption in transit at the server level, meaning clients that request plaintext are refused immediately. It directly addresses the requirement to prevent all unencrypted traffic, regardless of client-side settings.

The correct behavior is that the request fails with AccessDenied. S3 MFA Delete requires an MFA-authenticated request to permanently delete an object version. Since the request does not include the x-amz-mfa header with a valid MFA code, S3 denies the DeleteObject call. This prevents any deletion, including creation of delete markers.

A customer managed key provides the administrative control needed to satisfy the requirement, and KMS supports automatic rotation with a configurable period between 90 and 2560 days for symmetric keys generated in KMS. By creating a customer managed key with KMS-generated key material and setting its automatic rotation period to 365 days, the company achieves seamless annual rotation while decrypting data with previous key versions as needed.

Using HTTPS (TLS) endpoints for S3 requests encrypts the entire request payload, the headers, and the response in transit between the client and S3. TLS provides confidentiality, integrity, and authentication, preventing eavesdropping and tampering. This is the correct approach because it ensures each object upload is protected end-to-end at the application layer, regardless of network path.

Enable automatic rotation on the KMS key. AWS KMS automatically rotates the backing key material one year after the key is created and then every year thereafter, while keeping the same key ID and metadata, so Redshift continues to use the key without any reconfiguration. The old key material is retained to decrypt existing ciphertext, ensuring that all data encrypted under prior versions remains accessible. This meets the requirement of key rotation with minimal effort and no application changes.

Enabling S3 Block Public Access adds a strong, explicit layer of protection that can block public reading or writing through bucket policies, ACLs, or object ACLs, even if those public grants are unintentionally set. This control operates at both bucket and account levels and is a primary safeguard against data exposure caused by misconfigurations, making it essential for sensitive data.

This is correct because launching a cross-account encrypted AMI requires three separate sharing actions: the AMI itself via ModifyImageAttribute, each backing snapshot via ModifySnapshotAttribute, and the KMS key via a key policy update that grants the target account decrypt permissions. The target account's IAM roles or users must be able to call kms:Decrypt (and kms:CreateGrant for the launch to create a grant) on the source CMK. After these steps, the target can launch the instance and optionally re-encrypt the resulting volumes with its own KMS key. This layered authorization is the standard, supported pattern for sharing encrypted AMIs across accounts.

Enabling S3 Versioning together with MFA Delete is the correct answer because versioning preserves every overwrite and deletion as a previous version, while MFA Delete adds a second-factor requirement for permanently erasing versions or changing the bucket's versioning state. When an object is deleted, S3 simply creates a delete marker and the prior versions remain recoverable; without the MFA token, even the AWS account root user cannot permanently delete a version, which effectively prevents accidental or malicious deletion.

If the engineer updated the security policy on one listener but the application uses another listener (e.g., a different port), clients connecting to the unchanged listener could still use TLS 1.0. This is a common misconfiguration where changes are applied to the wrong listener or the listener is not updated. The scenario states that some clients can use TLS 1.0, indicating that a listener with a permissive policy is still active.

With SSE-KMS, S3 invokes kms:Decrypt using the requesting user's credentials every time an encrypted object is read. The KMS key policy is the resource-based policy that controls which principals can use the key; if it does not grant the user (or the user's role) kms:Decrypt, the KMS call is denied even when the user's IAM policy allows s3:GetObject. That denial manifests as an AccessDenied error during object retrieval.

This is the correct condition because the x-amz-server-side-encryption request header, when set to 'aws:kms', explicitly instructs S3 to encrypt the object with an AWS KMS-managed CMK upon upload. A bucket policy or IAM policy condition that checks this key and value will deny requests that specify a different encryption mode, but note that a robust enforcement policy should also explicitly deny requests that omit the header entirely (using a StringNotEquals condition) to prevent unencrypted uploads.

The s3:x-amz-server-side-encryption condition key is the correct way to enforce encryption in an S3 bucket policy, as it directly evaluates the x-amz-server-side-encryption header that clients must include in PutObject requests. You can combine it with StringEquals to require a specific value such as aws:kms or AES256, and use a Deny effect to reject any upload lacking the required encryption header. This condition key is evaluated by S3 during the request, making it a precise, application-level control that cannot be bypassed by network or regional context.

Amazon Macie is a fully managed data security and privacy service that uses machine learning and pattern matching to automatically discover, classify, and protect sensitive data in Amazon S3, including PII, PHI, and financial information. It supports DLP by generating custom findings and sending alerts via Amazon EventBridge or AWS Security Hub, and it can integrate with AWS Organizations to scale across multiple accounts. Macie provides both managed data identifiers and custom identifiers so customers can detect proprietary or regulatory data types.

The command invokes the KMS Encrypt API by taking the plaintext bytes from secret.txt, sending them with the specified key ID, and writing the returned base64-encoded `CiphertextBlob` to encrypted_secret.txt. This is the direct encryption of the file's contents under the given KMS key, producing ciphertext that can later be decrypted only with the same key (and any required encryption context). Because KMS Encrypt accepts plaintext up to only 4 KB, this approach is appropriate for small secrets like passwords or configuration values, not for large files.

Correct. S3 Batch Operations can re-encrypt existing objects with a new key, and the old key remains active for decryption.

SSE-S3 (Server-Side Encryption with Amazon S3-Managed Keys) is a built-in S3 feature that uses AES-256 to encrypt each object at rest with a unique data key, and the data key itself is encrypted with a regularly rotated master key managed by S3. You enable it by setting the x-amz-server-side-encryption header to AES256 or by applying a bucket default encryption policy, and S3 fully handles the key lifecycle—requiring no customer key management or extra cost.

Native RDS encryption at rest is a one-way, create-time configuration: you specify a customer-managed AWS KMS key (or the default aws/rds key) when launching the DB instance, and RDS uses envelope encryption to encrypt the instance's storage, automated backups, snapshots, and read replicas. Because the encryption decision is baked into the underlying storage during provisioning, it cannot be retroactively applied to an already-running instance. This is the simplest and most operationally transparent way to meet an at-rest encryption requirement for Amazon RDS.

The Amazon S3 encryption client performs all cryptographic operations locally, encrypting the object's plaintext with a data key before anything is transmitted; the resulting ciphertext and an encrypted copy of the data key are then uploaded. The plaintext data key is never sent to AWS, and you can choose to wrap the data key with a KMS key or an internal master key that remains entirely under your control. This design is exactly what is needed when only the customer should ever possess the unencrypted form of the data.

CloudHSM automatically stores encrypted backups of each HSM partition in Amazon S3, and you can schedule backups on a regular basis to protect against hardware failure or cluster loss. These backups capture the HSM's key material and data in an encrypted, point-in-time snapshot that can be restored to a new cluster in the same region. By regularly backing up, you ensure that if the cluster becomes unavailable, you can launch a new cluster and restore the backup, preserving access to the keys. This is the supported disaster-recovery mechanism for CloudHSM.

Because the RDS MySQL instance already has encryption at rest enabled with a KMS key, all automated backups and manual DB snapshots are encrypted automatically using that same KMS key. AWS handles this at the storage layer with no further input from you, so backup encryption is inherently included.

AWS Secrets Manager is a purpose-built service for storing and managing database credentials, API keys, and other sensitive values. It natively supports automatic rotation of secrets using a customizable AWS Lambda function, with one-click integration for Amazon RDS, Redshift, and DocumentDB to rotate the password on the datastore as well. Because it combines secure storage, fine-grained IAM access control, secret versioning, and scheduled rotation, it directly meets the stated requirement for securely storing database credentials with automatic rotation.

AWS CloudTrail is the only service listed that natively records the KMS API calls, including the Decrypt operation used when S3 fetches an SSE-KMS-encrypted object. Each KMS event in CloudTrail includes the key ARN, the IAM identity of the caller, the source IP address, and the encryption context, which together provide the complete audit trail required for security investigations. By default, KMS data-plane events like Decrypt are captured in the CloudTrail event history, and you can optionally set up a trail to deliver them to an S3 bucket or CloudWatch Logs for long-term retention.

Customer managed KMS keys with automatic rotation satisfy both mandates: RDS backups inherit the instance's encryption at rest, and KMS rotates the key annually. AWS managed keys do not offer customer-controlled rotation, so they fail the compliance requirement.

The AWS/SecretsManager namespace provides SecretRotationSucceeded, which is published after each automatic rotation attempt for a secret and increments when the rotation callback completes successfully. The complementary SecretRotationFailed metric reports failures; by using an alarm on SecretRotationSucceeded with a period and statistic appropriate for the rotation schedule, you can detect missed or unsuccessful rotations. Because this metric is emitted by the Secrets Manager service directly from the rotation process, it is the most precise signal for verifying that rotation is working as configured. For example, you can alarm when SecretRotationSucceeded equals zero for the expected rotation interval.

Launching an encrypted RDS instance with a customer-managed KMS key ensures data at rest is protected by an encryption key you create and control. Enabling automated backups provides point-in-time recovery, while a cross-region read replica serves as a disaster recovery target that can be promoted to a primary database in a regional outage. This combination fully meets the requirements for encryption, availability, and automated recovery.

Including a statement that allows the account root user full KMS permissions is the standard way to enable IAM policies in that account to control access to the key. Without this, IAM policies alone cannot grant access. This statement effectively delegates control to IAM for principals in the same account, which is necessary for same-account access.

SSE-S3 (Server-Side Encryption with S3-Managed Keys) encrypts objects at rest using S3's native AES-256 encryption, where Amazon S3 fully manages the encryption keys on the customer's behalf. When enabled, S3 automatically encrypts all new objects before persisting them and decrypts them on retrieval, with no additional configuration, key management cost, or KMS API usage. It is the simplest and most lightweight way to meet an encryption-at-rest compliance requirement for S3 data.

SSE-KMS integrates with AWS KMS to provide granular IAM and key policies that separate permissions for who can use a key (e.g., kms:Encrypt, kms:Decrypt) from who can administer it (e.g., kms:PutKeyPolicy, kms:ScheduleKeyDeletion). Additionally, every KMS API call is recorded in AWS CloudTrail, enabling robust audit trails of encryption key usage—something SSE-S3 cannot offer because S3 manages the keys entirely behind the scenes. This separation of duties and auditability is essential for many compliance frameworks, making it the correct benefit.

SSE-KMS encrypts CloudTrail log files with a customer-managed KMS key, giving you explicit control over decryption permissions and key rotation. CloudTrail log file integrity validation then publishes signed digest files containing SHA-256 hashes of each log file, allowing you to cryptographically verify that files were not altered or deleted after delivery. The two features together satisfy confidentiality and tamper detection.

Enable EBS encryption by default establishes that every newly created EBS volume and snapshot is encrypted with the volume's key—the AWS managed key with alias aws/ebs—without requiring per-volume configuration. Because this is an AWS managed key, AWS rotates it automatically and handles the key material, so the company does not need to manage lifecycle or permissions. This satisfies the requirement to encrypt data at rest in the EBS volume directly at the block-storage layer.

This is correct because the KMS key policy is the authoritative control for who can use the customer-managed key, and CloudWatch Logs calls KMS on behalf of the Lambda function when encrypting/decrypting log data. Adding a statement with Principal as logs.amazonaws.com and a condition using kms:ViaService logs.<region>.amazonaws.com restricts the key's use to calls that come through the CloudWatch Logs service endpoint. To ensure the request is tied to the specific Lambda function, you would also include a condition such as aws:SourceArn matching the Lambda function ARN or an EncryptionContext condition on the log group ARN, so the key cannot be used for unrelated log groups or services.

The CLI output shows SSEAlgorithm set to 'AES256', which is the exact algorithm identifier that Amazon S3 uses to represent SSE-S3 in a bucket default encryption configuration. With SSE-S3, S3 automatically manages all encryption keys, encrypts each object with a unique key, and wraps that key with a regularly rotated master key, requiring no customer action or KMS involvement. This precisely matches the output shown, confirming that the bucket is configured for SSE-S3.

SSE-KMS with a customer-managed AWS KMS key that has automatic rotation enabled satisfies the requirement because S3 Glacier applies server-side encryption using KMS, and KMS automatically rotates the underlying key material on an annual basis without any manual action. The CMK remains the same logical key, so object references and permissions are unchanged while the encryption material is refreshed, meeting compliance policies that demand automatic key rotation. This is the most flexible option when you need separate permissions and audit trails.

Denying requests lacking `aws:SecureTransport` enforces TLS on every S3 API call, satisfying the in-transit encryption requirement. The condition evaluates the transport protocol of each request, so any IAM user or role attempting plain HTTP access is rejected regardless of identity permissions. This protects sensitive documents during transmission without altering stored object encryption.

AWS CloudTrail is the only service here that natively captures every KMS API operation as an audit event, including both management-plane calls like CreateKey and PutKeyPolicy and data-plane cryptographic calls such as Encrypt, Decrypt, and GenerateDataKey when data events are enabled. Each log entry contains the requesting IAM principal, source IP, request parameters, and response elements, and even records access-denied events from failed authorization attempts, giving security teams a complete, tamper-evident trail for compliance investigations. Because CloudTrail delivers events to an S3 bucket and optionally to CloudWatch Logs, it provides the durable, centralized audit history required by regulators, whereas the other options do not capture KMS API calls directly.

A customer managed KMS key allows the security team to control rotation. Enabling automatic rotation with a one-year period meets the annual rotation requirement. When creating the DynamoDB table, specifying this key ensures all data is encrypted with it. The Lambda function's IAM role must have permissions to use the key for encrypt and decrypt operations.

The API response shows "ApplyServerSideEncryptionByDefault" with "SSEAlgorithm": "AES256", which directly maps to S3-managed keys, i.e., SSE-S3. With SSE-S3 default encryption enabled, any object uploaded without an encryption header is automatically encrypted at rest using S3's AES-256 encryption. This is exactly what the get-bucket-encryption output demonstrates, making this the correct interpretation.

Creating a new DB instance with encryption enabled is the correct approach because RDS encryption at rest is enabled at launch using an AWS KMS customer managed key. Once enabled, Amazon RDS transparently encrypts the underlying storage, automated backups, read replicas, and snapshots without requiring any application changes. After the new encrypted instance is created, migrate data from the existing source—either by restoring from an encrypted snapshot or using native database export/import tools—to complete the transition.

AWS Key Management Service (KMS) is the correct service for encrypting Amazon RDS data at rest. When you enable RDS encryption, you select a KMS customer master key (CMK) — either the AWS-managed key (aws/rds) or a customer-managed CMK — which encrypts the underlying storage, automated backups, snapshots, and read replicas. KMS also provides fine-grained access control and AWS CloudTrail auditing for every key use, making it the native integration point for RDS storage encryption.

A KMS key policy is the resource-based policy that ultimately defines which principals are allowed to use the key. By adding a condition such as aws:PrincipalArn to the kms:Decrypt action, you can limit the permission to a specific IAM role ARN, ensuring that no other principal can invoke decrypt even if they have IAM permissions. The key policy, not IAM, is the controlling restriction here. Always include a statement allowing the account root user to administer the key so you don't lock yourself out.

Enable EBS encryption by default at the account or region level, either through the EC2 console or the API (EnableEbsEncryptionByDefault). This setting automatically encrypts all newly created volumes, snapshots, and volumes created from those snapshots, using either the default AWS-managed key or a custom KMS key you specify. Because it is enforced at creation time, it is a preventive control that eliminates the risk of accidentally leaving new volumes unencrypted, which is exactly what the security requirement demands.

A presigned URL is generated by using AWS Signature Version 4 to sign a request for a specific S3 object action, such as GetObject, using the caller's credentials. With a 24-hour expiration, the embedded X-Amz-Expires parameter causes S3 to reject the URL after one day, so the recipient never needs the IAM user's actual secret key. The underlying object stays private because access still passes through S3's authorization layer; the URL only carries the cryptographic signature that proves the request was authorized.

The security domain is the encrypted root-of-trust material generated when a CloudHSM cluster is initialized, and it is required to decrypt cluster backups and recover the keys stored in the HSM. By exporting the security domain from the source cluster and importing or supplying it during the initialization of a new cluster in the target region, you give the new cluster the ability to unlock the restored backup and retrieve the original key material. This is the correct disaster-recovery action, and it must be paired with copying and restoring a CloudHSM backup to that region.

CloudHSM is a dedicated hardware security module that provides FIPS 140-2 Level 3 validated, tamper-resistant devices for generating, storing, and using cryptographic keys. Unlike KMS, CloudHSM gives you exclusive, root-level control over your own HSMs and the entire key lifecycle, independent of AWS-operated key infrastructure.

This enforces use of the specific KMS key for all operations.

The web application must explicitly request TLS because RDS defaults to allowing both encrypted and unencrypted connections depending on the client. Adding an SSL/TLS option to the connection string—such as 'sslMode=require' or 'sslmode=verify-full'—forces the client to negotiate an encrypted channel. This is the only option that directly controls the confidentiality of data as it travels from the application to the RDS database.

When a customer-managed KMS key is scheduled for deletion, KMS enforces a mandatory waiting period (7 to 30 days, configurable) during which the key can be restored using the CancelKeyDeletion operation, which returns the key to its previous enabled state. As long as the original key is restored before the deletion completes, any ciphertext encrypted under that key—including data keys wrapped by the key—remains decryptable, so your data is not lost. The waiting period is designed exactly for this recovery scenario; after it expires, deletion is irreversible and no recovery path exists.

AWS Site-to-Site VPN establishes a secure IPsec tunnel between your on-premises gateway and a virtual private gateway or transit gateway in AWS. Using IKEv2 and AES encryption, it encrypts all IP traffic traversing the public internet, ensuring confidentiality and integrity for data in transit. This is a core service for hybrid cloud connectivity and a valid method for protecting data.

SSE-S3 (server-side encryption with Amazon S3 managed keys) is the correct option because it uses strong AES-256 encryption with keys that are managed entirely by Amazon S3. Each object is encrypted with a unique data key, and the data key is wrapped by a regular rotating S3-managed key. This gives S3 the responsibility for encrypting confidential documents with no additional cost, no key rotation overhead, and no need for the customer to supply or manage keys.

This is the correct policy because it uses `StringNotEquals` on the `s3:x-amz-server-side-encryption` header to deny any upload that does not specify `aws:kms`. Requests that omit the encryption header or use `AES256` (SSE-S3) will have a condition that evaluates to true, triggering the Deny, while requests that explicitly send `aws:kms` are permitted. This narrowly enforces SSE-KMS for all new objects without blocking compliant uploads.

Enforcing HTTPS for web traffic is a critical best practice because HTTPS runs HTTP over TLS, providing confidentiality, integrity, and server authentication for every request and response. Redirecting all HTTP requests to HTTPS and applying HTTP Strict Transport Security (HSTS) ensures clients never send or accept plaintext web communication, mitigating man-in-the-middle and session-hijacking attacks. This should be the baseline for every public-facing web workload and ideally applied to internal web consoles and APIs as well.

HTTPS endpoints for S3 API calls use Transport Layer Security (TLS) to encrypt the entire HTTP request and response payload between the on-premises client and the S3 service. This protects the confidentiality and integrity of data in transit, preventing eavesdropping and tampering. Using HTTPS is the standard, built-in mechanism for securing S3 API traffic, and it applies regardless of whether the client is in your VPC or on-premises.

The role can decrypt objects in S3 because the policy grants kms:Decrypt and includes a condition that limits the key's use to the S3 service in us-east-1 (for example, kms:ViaService with s3.us-east-1.amazonaws.com). This allows S3 to use the key to decrypt SSE-KMS-encrypted objects. However, the same condition prevents any other service (such as EC2, Lambda, or EBS) from using the key, even within us-east-1. The role also cannot use the key with S3 in other regions, so the overall scope is exactly S3 in us-east-1 for the allowed actions.

To enable encryption-at-rest on an existing unencrypted Amazon RDS DB instance, you must create a manual snapshot, make an encrypted copy of that snapshot (either with the default AWS-managed key or a customer-managed KMS key), and then restore a new DB instance from the encrypted snapshot. During the snapshot copy you can also specify a KMS key; the restored instance will be encrypted, and you can then update your applications' connection strings to point to the new endpoint. This is the documented and only supported approach, since encryption cannot be added in place.

To add encryption to an existing Redshift cluster, take a snapshot of the source cluster and restore it as a new cluster while specifying a KMS key in the restore settings. The restore operation initializes a fresh cluster with encryption enabled at the storage layer, then you can update your application's JDBC/ODBC connection strings and DNS to point to the new endpoint. Once verified, you can retire the old cluster. This is the only AWS-supported path for retrofitting encryption.

The policy's Deny effect on s3:PutObject with a condition checking that the encryption header is absent or not SSE-KMS means any upload lacking SSE-KMS encryption is rejected. Requests specifying SSE-KMS satisfy the condition and are permitted.

S3 Versioning is the correct data-protection mechanism because a regular DELETE on a versioned object only inserts a null-version delete marker while preserving all prior versions, allowing recovery by deleting that marker. Granting the s3:DeleteObjectVersion permission (only where appropriate) enables administrators to permanently purge specific object versions when retention or compliance demands actual deletion, while ordinary deletions remain reversible. This creates a two-tier deletion model where accidental deletes can be untangled and legitimate permanent deletes are still possible, exactly matching the requirement.

Setting default encryption on the bucket is the correct way to ensure that all objects are encrypted at rest automatically. When enabled, Amazon S3 applies server-side encryption (SSE-S3 by default, or SSE-KMS if configured) to every object uploaded to the bucket, even if the upload request does not include an encryption header. This provides a security baseline for sensitive documents and guarantees that no object is stored in an unencrypted state. Unlike policies or lifecycle rules, default encryption directly acts on the data itself at write time.

Service control policies set permission guardrails across every account in AWS Organizations, so an SCP denying s3:CreateBucket without default encryption blocks non-compliant buckets organisation-wide. This satisfies the requirement to enforce encryption centrally in all accounts, which bucket policies cannot do.

Using an AWS managed key such as the aws/s3 key automatically satisfies the rotation requirement because AWS KMS rotates AWS managed keys automatically every year (approximately 365 days) without any customer action. These keys are provisioned and managed by AWS, so the restrictive customer key policy on the existing customer managed key does not apply, and you cannot disable or alter their automatic rotation. For S3 server-side encryption with KMS, simply selecting the aws/s3 managed key encrypts objects with a key that is automatically rotated.