CCNA Data Protection Questions

To control decryption of S3 objects encrypted with a CMK in KMS, you must grant kms:Decrypt permission to authorized users, typically via an IAM policy (option C). Additionally, the KMS key policy should be configured to allow only the authorized IAM roles to use the key (option B). Option A is incorrect because a bucket policy with encryption context conditions controls the encryption context during upload, not decryption.

Option D is incorrect because a VPC endpoint for S3 restricts network access but does not grant decryption permissions. Option E is incorrect because SSE-C uses a customer-provided key, not a KMS CMK.

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.

Deploying a CloudHSM cluster with at least two HSMs in different Availability Zones ensures high availability and durability by eliminating a single point of failure and providing redundancy across AZs. Option A is incorrect because AWS KMS is a different service and does not provide the same hardware-based key generation and storage as CloudHSM. Option B is incorrect because a single CloudHSM instance in one AZ is a single point of failure.

Option C is incorrect because CloudHSM does not automatically replicate data across regions; cross-region replication requires manual backup and restore processes.

AWS Secrets Manager provides built-in automatic rotation for supported secrets, allowing you to configure the rotation interval directly in the secret's settings. This approach requires no custom infrastructure, minimizing operational overhead. Option A is incorrect because creating an EventBridge rule and a custom Lambda function adds unnecessary complexity when Secrets Manager can handle the scheduling automatically.

Option B is incorrect because using a cron job with the AWS CLI is manual, error-prone, and not scalable for automated rotation. Option C is incorrect because it essentially duplicates Option A's approach (CloudWatch Events is the same as EventBridge) and is not the most streamlined method.

Options B, D, and E are correct. Using TLS listeners on Elastic Load Balancers encrypts traffic between clients and the load balancer. Configuring Amazon CloudFront to require HTTPS ensures encrypted delivery to end users.

AWS Site-to-Site VPN provides encrypted tunnels for hybrid connectivity. Option A is incorrect because VPC Peering does not natively encrypt traffic; the option 'with encryption' is not a built-in feature and can be misleading. Option C is incorrect because S3 Transfer Acceleration speeds up uploads over the public internet but does not guarantee encryption of data in transit; it uses HTTPS but the selection of this option does not inherently enforce encryption.

The correct ways to encrypt data at rest in Amazon S3 are using server-side encryption with S3 managed keys (SSE-S3) and client-side encryption before uploading. SSE-S3 encrypts objects at rest on the server side (Option B). Client-side encryption encrypts data before it is sent to S3, ensuring encryption at rest as well (Option E).

Option A is incorrect because a bucket policy can enforce encryption, but it does not actually encrypt data; it only denies uploads without encryption. Option C is wrong because encryption in transit (HTTPS) protects data during transfer, not at rest. Option D is wrong because MFA Delete provides additional protection against accidental deletion, not encryption.

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 A, C, and D are correct. Option A is correct because Amazon Redshift automatically encrypts snapshots with the same KMS key used for the cluster when encryption is enabled at creation. Option C is correct because to share snapshots cross-account, the KMS key policy must grant the target account permission to decrypt using the key.

Option D is correct because a snapshot copy grant is required to authorize the target account to use the KMS key for encrypted snapshot sharing. Option B is incorrect because a separate key is not necessary; the same key can be used if proper permissions are set. Option E is incorrect because AWS Config rules can detect unencrypted snapshots but do not directly enforce cross-account sharing security.

It uses a bucket policy condition that denies s3:PutObject unless the request includes the x-amz-server-side-encryption header with value aws:kms (though the option text shows a combined form). This enforces the use of AWS KMS customer managed key (CMK) for server-side encryption. Option A is incorrect because it only allows PutObject if the user has KMS permissions, which does not guarantee the object is encrypted with KMS; the user could still upload without encryption.

Option B configures default encryption, but it can be overridden by the uploader; it does not enforce encryption. Option C is about lifecycle policy, not encryption enforcement.

AWS CloudTrail logs all KMS API calls, and CloudWatch Alarms can be configured to trigger on specific unauthorized API calls, such as Decrypt attempts with a key the user does not have access to. Option A is incorrect because Amazon GuardDuty is a threat detection service that focuses on identifying malicious activity, but it does not provide detailed monitoring of specific KMS API calls. Option B is incorrect because AWS Config evaluates resource configurations and compliance, not API calls.

Option D is incorrect because Amazon Inspector is a vulnerability assessment service for EC2 instances and does not monitor API calls.

Options B, D, and E are correct. The client must call kms:GenerateDataKey (Option D) to obtain a data key, which is then used to encrypt the data. The encrypted data key is stored as metadata with the S3 object (Option B).

The AWS SDK Encryption Client library (Option E) handles the client-side encryption process. Option A is wrong because an S3 bucket policy forcing encryption is not required for client-side encryption; that is used for server-side encryption enforcement. Option C is wrong because the KMS key policy does not need to allow the S3 service to decrypt; client-side encryption does not involve S3 decrypting the data.

In a typical AWS environment, data in transit between an application and an RDS database can be encrypted using SSL/TLS. RDS for MySQL supports SSL/TLS connections. To meet the requirement, enable SSL/TLS on the RDS instance by downloading the certificate bundle and configuring the DB instance to require encrypted connections.

Then, configure the application to use SSL/TLS when connecting to the database. This approach encrypts data in transit with minimal overhead compared to a VPN, which can introduce latency. Option A (using AWS Certificate Manager for the RDS endpoint) is incorrect because ACM is typically used for load balancers and CloudFront, not for direct database connections.

While ACM can provide certificates for applications, RDS itself uses its own certificate authority for SSL/TLS. Option B (setting up an IPsec VPN) is unnecessary and adds complexity and latency without providing encryption specific to the database connection; SSL/TLS already meets the requirement. Option C (placing instances in the same subnet and using a NAT gateway) does not encrypt data in transit and increases latency via NAT gateway.

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.

Options A, D, and E are correct practices for securing KMS keys. Enabling automatic key rotation (A) helps reduce the impact of a compromised key. Using IAM policies and key policies to restrict access (D) follows the principle of least privilege.

Enabling CloudTrail logging for KMS API calls (E) provides an audit trail for monitoring usage. Option B is incorrect because disabling automatic key rotation is not a security best practice; rotation limits the exposure of key material. Option C is incorrect because sharing a KMS key across multiple accounts via cross-account access increases the attack surface and is not a recommended practice; instead, each account should have its own keys or use cross-account access only when necessary with strict controls.

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.

To control access to a KMS key used for RDS encryption, two steps are required. First, modify the KMS key policy to grant the specific IAM roles permission to use the key (Option B). Second, attach an IAM policy to those roles that grants the necessary KMS actions, such as kms:Encrypt and kms:Decrypt (Option A).

Option C is insufficient because it only grants decryption; both encrypt and decrypt are needed for RDS to use the key. Option D is incorrect because S3 bucket policies are not relevant to KMS key permissions. Option E is incorrect because VPC endpoint policies control network access, not key usage permissions.

You must configure the KMS key policy to allow the EFS service to use the key for encryption at rest. Option B is correct because encryption at rest is enabled by specifying a customer-managed KMS key when creating the EFS file system. Option E is correct because encryption in transit is enabled by using the TLS option when mounting the file system on the client.

Option C is incorrect because EFS does not support SSE-S3; it uses KMS for encryption at rest. Option D is incorrect because IAM policies can restrict who can create encrypted file systems, but the question specifically asks about controlling which KMS keys can be used, which is done via KMS key policies, not IAM policies.

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.

Options A and B are correct. EBS encryption can be enabled using either the AWS managed key for EBS (option A) or a customer managed KMS key (option B). Option C is incorrect because EBS encryption is not performed by a script on the EC2 instance; it is handled by AWS KMS.

Option D is incorrect because CloudHSM is not directly used for EBS encryption (though it can be used as a key source via KMS custom key stores, it is not a direct option for encrypting EBS volumes). Option E is incorrect because S3 server-side encryption applies to objects in S3, not to EBS snapshots; EBS snapshots can be encrypted using KMS keys.

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.

(SSE-C) is correct because SSE-C allows the customer to provide their own encryption keys, meeting the compliance requirement that keys be managed by the company and not by AWS. Option B (SSE-S3) is incorrect because AWS manages the keys. Option D (SSE-KMS) is incorrect because even with customer-managed keys, AWS KMS stores and manages the keys.

Option C (client-side encryption) is not server-side encryption and would require the customer to manage encryption before upload, but the question specifically asks for encryption at rest on S3, and server-side options are appropriate; SSE-C is the only server-side option where AWS does not manage the keys.

(Enable default encryption on the S3 bucket with SSE-KMS) ensures all objects are encrypted at rest. Option D (Use a KMS key policy that allows the Lambda execution role to use the key) grants the necessary permissions at the key level. Option E (Grant the Lambda execution role kms:GenerateDataKey and kms:Decrypt permissions) provides the minimum permissions needed for Lambda to write encrypted data (GenerateDataKey) and read encrypted data (Decrypt).

Option B is incorrect because kms:Encrypt alone is insufficient; GenerateDataKey is required for writing. Option C is incorrect because kms:CreateKey is a key management action, not needed for usage.

To prevent KMS keys from being used outside the account, you need to enforce that only principals within the account can use the key. Option C adds a key policy statement that denies kms:* actions for principals from other AWS accounts, effectively blocking cross-account access. Option E restricts the key policy to allow only specific IAM roles within the account, ensuring that only authorized roles can use the key.

Options A (tagging) and B (enabling automatic key rotation) do not restrict usage. Option D (disabling automatic key rotation) also does not restrict usage. Therefore, the correct answers are C and E.

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.

Options C and E are correct. Option C (Enable S3 Block Public Access) prevents accidental public exposure of data, which is a key security measure. Option E (Enable default encryption) ensures that all new objects are encrypted at rest, protecting data from unauthorized access even if the underlying storage is compromised.

Option A (S3 Transfer Acceleration) is designed to speed up data transfers, not enhance security. Option B (S3 event notifications to Amazon SNS) enables automation workflows but does not protect data. Option D (S3 Object Lock) prevents object deletion or modification over a retention period, which addresses data governance and ransomware protection, not unauthorized access.