CCNA Data Protection Questions

Options B, D, and E are correct. B: Enabling automatic key rotation annually is a best practice to ensure keys are rotated regularly without manual intervention. D: Using key policies to restrict which IAM roles can use the key follows the principle of least privilege.

E: Enabling AWS CloudTrail logging to record KMS key usage provides an audit trail for security monitoring. Option A is incorrect because deleting a KMS key immediately can cause permanent data loss; instead, you should schedule key deletion. Option C is incorrect because exporting KMS key material and storing it in an S3 bucket would expose the key material and defeat the purpose of using a managed service like KMS.

A VPC endpoint for AWS KMS allows KMS API calls to be routed through the VPC, ensuring traffic does not traverse the public internet. Option E is correct because you can modify the KMS key policy to include a condition using the kms:SourceVpc key, which restricts use of the KMS key to requests originating from the specified VPC. Option B is incorrect because IAM policies cannot directly restrict based on VPC for KMS; such restrictions must be in the key policy.

Option C is incorrect because a VPC endpoint for Amazon S3 does not restrict KMS calls. Option D is incorrect because S3 bucket policies control access to S3 objects, not KMS key usage.

A bucket policy with a Deny effect on s3:PutObject when the condition `s3:x-amz-server-side-encryption` is not equal to `aws:kms` enforces SSE-KMS for all uploads. Option A is incorrect because default encryption using SSE-S3 can be overridden by the PUT request, and it does not enforce KMS. Option C is incorrect because SCPs apply at the account or organizational unit level, not to individual buckets, and are less direct than bucket policies.

Option D is incorrect because requiring the `x-amz-server-side-encryption` header alone does not mandate the value `aws:kms`; a requester could set it to `AES256` (SSE-S3).

The bucket policy includes a Deny effect with a condition 'StringNotEquals': {'s3:x-amz-server-side-encryption': 'aws:kms'}. This condition denies requests only when the x-amz-server-side-encryption header is present in the request and its value is not 'aws:kms'. If the header is absent (as when the user does not specify encryption), the condition evaluates to false, meaning the Deny rule does not apply.

Therefore, the upload is not denied by this policy. Since new S3 buckets have default encryption enabled with SSE-S3, the object will be encrypted with SSE-S3, and the upload succeeds. Option A is incorrect because the policy does not deny all requests; it only denies those that include a supported but non-matching encryption header.

Option C is incorrect because it assumes the Deny applies when the header is absent, which is not the case for 'StringNotEquals' (without 'IfExists'). Option D is similar to B but B is the more precise statement.

Options D and E are correct. D: Enabling EBS encryption by default in AWS Account settings ensures that all new EBS volumes are encrypted at rest. E: Using encrypted EBS volumes with AWS KMS customer-managed keys provides granular control over encryption keys.

Option A is incorrect because EBS snapshots are not automatically encrypted by default; they can be encrypted during copy or by enabling encryption by default for volumes. Option B is incorrect because encryption at rest is independent of instance type; any instance type can use encrypted EBS volumes. Option C is incorrect because configuring the OS to use encrypted file systems is not the primary method for protecting data at rest on EBS; EBS encryption at the volume level is more appropriate.

The current bucket encryption configuration uses SSE-S3 (AES256). To meet the policy requiring KMS with a customer managed key, the engineer must update the bucket's default encryption settings to use SSE-KMS (aws:kms) and specify the KMS key ID. Option C correctly describes this.

Option A is incorrect because enabling the bucket key with SSE-S3 does not change the encryption algorithm to KMS. Option B is incorrect because client-side encryption with a KMS key is not a bucket-level configuration; it is applied by the client before upload and does not modify the default server-side encryption setting. Option D is incorrect because adding a bucket policy that requires kms:Encrypt permission for PutObject requests does not enforce server-side encryption with KMS; it only authorizes KMS encryption if used, but objects could still be uploaded without specifying KMS encryption.

SSL/TLS is the appropriate solution to encrypt data in transit between the EC2 instance and the RDS database. It ensures that data is encrypted during transmission, preventing eavesdropping or tampering. Option A is incorrect because a VPN connection encrypts traffic between networks but is unnecessary for direct connectivity within the same VPC; SSL/TLS is more straightforward.

Option B is incorrect because encryption at rest protects data stored on disk, not data in motion. Option D is incorrect because client-side encryption would require modifying the application to encrypt data before sending, which does not guarantee encryption of the entire communication channel.

S3 Object Lock in Governance mode prevents objects from being deleted or overwritten during the retention period, and a lifecycle policy can automatically expire objects after 7 years to meet the retention requirement. Option A is incorrect because Object Lock in Compliance mode also prevents deletion and overwriting, but without specifying a retention period, it does not enforce the 7-year retention; additionally, Compliance mode cannot be overridden, which may be too restrictive. Option B is incorrect because S3 Intelligent-Tiering and lifecycle policies manage storage costs and transitions, not protection against deletion or overwriting.

Option C is incorrect because versioning and MFA Delete protect against accidental deletion and preserve overwritten versions, but do not guarantee a 7-year retention period; lifecycle policies would be needed to enforce it.

Option C is correct because it explicitly denies PutObject unless the request includes both the x-amz-server-side-encryption header with value AES256 (which requests SSE-S3) and the encryption type is SSE-S3. This ensures only objects encrypted with SSE-S3 can be uploaded. Option A is incorrect because it only checks for the header value AES256; while AES256 is specific to SSE-S3 and would also enforce SSE-S3, Option C provides a more explicit condition.

Option B is incorrect because it denies all PutObject requests. Option D is incorrect because an Allow statement cannot enforce a denial; a Deny statement is required to block unencrypted uploads.

Creating a multi-Region key replicates the key material to another AWS Region, providing a backup that can be used if the primary key is accidentally deleted. Enabling automatic key rotation further enhances security by regularly rotating the backing keys, but it does not prevent deletion. However, the multi-Region key approach allows recovery from accidental deletion by using the replica in another Region.

Option A is incorrect because disabling the key only prevents its use, not its deletion; the deletion waiting period allows recovery only if the deletion is canceled within the waiting period. Option B is incorrect because automatic key rotation does not prevent deletion; it only creates new cryptographic material. Option D is incorrect because AWS CloudHSM does not directly integrate with S3 server-side encryption using KMS (SSE-KMS) for automatic encryption; it requires custom applications.

Downloading the RDS CA certificate to the EC2 instance and configuring the database client to use SSL with certificate verification ensures that the data in transit is encrypted and that the server's identity is verified, preventing man-in-the-middle attacks. Option A is incorrect because a self-signed certificate without proper verification does not provide a trusted chain of identity. Option B is incorrect because encryption at rest protects data stored on disk, not data in transit.

Option D is incorrect because IAM policies can require SSL but cannot enforce the actual encryption of the connection; the client must still be configured to use SSL.

Options C and E are correct. Option C uses an S3 bucket policy with a condition requiring requests to include a specific KMS key ID, ensuring that only requests using that key can access the objects. This enforces encryption at rest (objects encrypted with that key) and in transit (HTTPS with KMS).

Option E grants the third party's AWS account permission to use that KMS key for decrypt operations, allowing them to decrypt the files. Together, they provide encryption key control and the ability to rotate the key or its policy every 30 days. Option A (cross-account IAM role) does not enforce encryption key control and requires the third party to assume a role, but credential rotation is managed via role trust policy, not directly.

Option B (S3 Cross-Region Replication) replicates objects but does not enforce key-specific access or encryption at rest in the destination. Option D (presigned URLs) provides time-limited access but does not enforce encryption key control and cannot be easily rotated every 30 days without regenerating URLs.

You can create a new KMS key and modify the RDS instance to use the new key. This action re-encrypts the database and its automated snapshots with the new key, providing on-demand key rotation. The re-encryption is performed automatically during the modification.

Option A is incorrect because RDS does not allow specifying a separate KMS key for backups; backups use the same key as the instance. Option B is incorrect because disabling the old KMS key would break access to existing backups that are still encrypted with that key. Option C is incorrect because automatic key rotation in KMS does not trigger re-encryption of existing data; it only generates new key material for future encryption operations.

The key policy does not grant Alice any permissions, and it does not enable IAM policies to allow access (no statement allowing root account to delegate via IAM). Since KMS requires explicit key policy authorization unless the key policy enables IAM policies, Alice cannot encrypt data even with full IAM permissions. Option D correctly identifies this.

Option A is wrong because the key policy does not need a separate statement to allow IAM policies unless it explicitly enables IAM policy delegation. Option B is wrong because Alice has kms:Encrypt via IAM policy, but the key policy is restrictive. Option C is wrong because the root account is included (the Root principal).

Options D and E are correct. MFA Delete adds an extra authentication factor for delete operations, providing protection against accidental or unauthorized deletion. S3 Versioning allows recovery of deleted or overwritten objects by preserving previous versions.

Option A is incorrect because S3 Object Lock with retention mode prevents object deletion or overwrite for a fixed period, but it is not specifically designed to protect against accidental deletion; it is more for compliance. Option B is incorrect because cross-region replication replicates objects to another bucket, but it does not prevent deletion in the source bucket; it only creates copies. Option C is incorrect because a bucket policy that denies s3:DeleteObject for all principals would prevent all delete operations, which is overly restrictive and not a practical solution for protecting against accidental deletion while still allowing necessary administrative actions.

An S3 bucket policy that denies PutObject if the object is not encrypted using SSE-S3 or SSE-KMS ensures that any upload attempt without proper server-side encryption is blocked. Option A is incorrect because enabling default encryption does not deny unencrypted uploads if the request explicitly sets encryption to none. Option B is incorrect because the 's3:x-amz-server-side-encryption' condition key can require encryption but does not cover all cases; using a deny statement for unencrypted uploads is more robust.

Option D is incorrect because AWS Config can only detect non-compliance, not deny the upload in real-time.

Options B and D are correct. To allow decryption by a specific AWS account, you must configure the KMS key policy to grant the target account permission to use the key for decrypt (option B). Additionally, the target account must create an IAM policy that allows its users to call the kms:Decrypt action (option D).

Option A is incorrect because S3 bucket policies cannot grant KMS decryption permissions; they only control S3 operations. Option C is incorrect because using a separate KMS key per object adds unnecessary complexity and does not solve the cross-account requirement. Option E is incorrect because enabling S3 default encryption with a KMS key does not restrict decryption to a specific account; it only ensures encryption is applied.

Enabling encryption at rest on the RDS instance using a customer managed KMS key and enabling automatic key rotation in KMS provides annual key rotation, satisfying the compliance requirement. Option A is incorrect because an encrypted read replica inherits the source instance's encryption key and does not provide independent backup encryption or key rotation. Option B is incorrect because S3 server-side encryption is not relevant to RDS automated backups; RDS encrypts backups using the KMS key associated with the DB instance, and S3 lifecycle policies rotate objects, not encryption keys.

Option C is incorrect because although an AWS managed KMS key encrypts the RDS instance and backups, its automatic key rotation occurs every three years, not annually as required.

When a KMS key is deleted and you have a backup of the key material, you can import that material into a new KMS key. Even though the new key has a different key ID, because the cryptographic material is identical, it can decrypt the data keys that were encrypted with the original key. S3 Batch Operations can then re-encrypt all objects under the new key, restoring access.

Option A is incorrect because the objects were encrypted with SSE-KMS, meaning the data key itself is encrypted by KMS and cannot be decrypted without the KMS key. Option C is incorrect because KMS does not allow you to specify the key ID when creating a new key; AWS generates a unique key ID. Option D is incorrect because CloudHSM is a separate service for generating and storing keys; it is not used to back up KMS keys.

Using a kms:ViaService condition in the key policy restricts the key usage to requests coming from Amazon S3, and the IAM role's permissions to decrypt are granted via the key policy, ensuring only that role can decrypt via S3. Option A is wrong because without the key policy granting decrypt to the role, the IAM policy alone is insufficient. Option B is wrong because it grants blanket decrypt access to the role without the S3 service restriction, allowing decryption outside S3.

Option C is wrong because grants are not the recommended way to control access for IAM roles with S3; key policies with conditions are more appropriate.

It uses a bucket policy with the 's3:x-amz-server-side-encryption-aws-kms-key-id' condition key to deny requests that do not include the specific KMS key ID in the 'x-amz-server-side-encryption-aws-kms-key-id' header. This enforces that only objects encrypted with the specified KMS key can be accessed. Option A is incorrect because SSE-C uses customer-provided keys and does not integrate with KMS key IDs; distributing a customer key does not enforce the specific KMS key.

Option C is incorrect because S3 Block Public Access and AWS WAF do not control access based on encryption key. Option D is incorrect because lifecycle policies do not restrict access based on encryption key.

The key is a customer managed CMK (KeyRotationEnabled: false indicates it's not an AWS managed key, as AWS managed keys have rotation enabled automatically and cannot be disabled). Enabling automatic rotation on a customer managed CMK is done via the 'aws kms enable-key-rotation' CLI command. Option B is incorrect because AWS CloudHSM is not required for key rotation; automatic rotation can be enabled directly on the CMK without manual intervention.

Option C is incorrect because replacing the key with an AWS managed key would remove control over rotation and is not a necessary action; the current key can have rotation enabled. Option D is incorrect because if key material is imported, automatic rotation is not supported; the key must be rotated manually.