Data Protection practice questions

A company stores sensitive data in Amazon S3 and wants to ensure that all objects are encrypted at rest. The security team has enabled default encryption on the S3 bucket using SSE-S3. However, an audit reveals that some objects are stored with SSE-KMS. How can the company enforce that only SSE-S3 is used for all future uploads, while still allowing existing SSE-KMS objects to be read?

Trap 1: Configure a bucket policy that denies s3:PutObject with…

A bucket policy that denies s3:PutObject when the condition key s3:x-amz-server-side-encryption-aws:kms equals "aws:kms" only blocks uploads that explicitly request SSE-KMS; it does not require SSE-S3, because requests with no encryption header or with AES256 would not match the condition and would be permitted. Existing SSE-KMS objects remain readable, so this does not enforce a uniform encryption standard and can even allow unencrypted PUTs if no default encryption is set.

Trap 2: Use an S3 Lifecycle policy to transition existing SSE-KMS objects…

S3 Lifecycle policies only transition the storage class of an object (for example, from S3 Standard to S3 Glacier Deep Archive) and never rewrite or replace the object's encryption settings. To change existing objects from SSE-KMS to SSE-S3, you must programmatically copy each object to itself or to a new key while specifying the desired server-side encryption, then delete the original — a lifecycle rule cannot perform that operation.

Trap 3: Disable SSE-KMS in the AWS KMS key policy to prevent its use.

Disabling the AWS KMS key in its key policy (or via the console) makes the key unusable, which means S3 cannot decrypt any existing objects that were encrypted with that customer-managed key, causing GET calls to fail with an AccessDenied error. This also prevents all new uses of the key, including non-S3 services, and does nothing to require AES256 encryption; instead you would need to re-encrypt objects with a new key or use bucket policy to enforce SSE-S3.

A
Configure a bucket policy that denies s3:PutObject with s3:x-amz-server-side-encryption-aws:kms.
Why wrong: A bucket policy that denies s3:PutObject when the condition key s3:x-amz-server-side-encryption-aws:kms equals "aws:kms" only blocks uploads that explicitly request SSE-KMS; it does not require SSE-S3, because requests with no encryption header or with AES256 would not match the condition and would be permitted. Existing SSE-KMS objects remain readable, so this does not enforce a uniform encryption standard and can even allow unencrypted PUTs if no default encryption is set.
B
Use an S3 Lifecycle policy to transition existing SSE-KMS objects to SSE-S3.
Why wrong: S3 Lifecycle policies only transition the storage class of an object (for example, from S3 Standard to S3 Glacier Deep Archive) and never rewrite or replace the object's encryption settings. To change existing objects from SSE-KMS to SSE-S3, you must programmatically copy each object to itself or to a new key while specifying the desired server-side encryption, then delete the original — a lifecycle rule cannot perform that operation.
C
Apply a bucket policy that denies s3:PutObject unless the x-amz-server-side-encryption header is AES256.
This bucket policy uses the condition key s3:x-amz-server-side-encryption with a StringNotEquals condition equal to "AES256" to deny any s3:PutObject request whose encryption header is not exactly AES256. Because the denial is scoped to PutObject, existing objects and GET/read operations are unaffected, and the policy enforces SSE-S3 for new uploads only; note that without a bucket default encryption, a request with no header would be denied, forcing clients to explicitly set the header.
D
Disable SSE-KMS in the AWS KMS key policy to prevent its use.
Why wrong: Disabling the AWS KMS key in its key policy (or via the console) makes the key unusable, which means S3 cannot decrypt any existing objects that were encrypted with that customer-managed key, causing GET calls to fail with an AccessDenied error. This also prevents all new uses of the key, including non-S3 services, and does nothing to require AES256 encryption; instead you would need to re-encrypt objects with a new key or use bucket policy to enforce SSE-S3.

Question 2mediummulti select

A company is designing a data protection strategy for its Amazon S3 bucket that stores sensitive documents. The security team requires that all data be encrypted in transit and at rest, and that any accidental deletion of objects can be reversed within 30 days. Additionally, the company must be able to audit all access attempts to the bucket, including failed attempts. Which TWO actions should the company take to meet these requirements? (Choose two.)

Trap 1: Enable default encryption on the bucket using SSE-S3.

Default encryption with SSE-S3 encrypts objects at rest using an Amazon-managed AES-256 key, but it does not protect data in transit; you must also enforce TLS/HTTPS for uploads and downloads. Encryption addresses confidentiality only—it has no effect on preservation, deletion recovery, or access auditing. Therefore, SSE-S3 alone cannot satisfy a data protection strategy that requires retention and forensic visibility.

Trap 2: Enable S3 server access logs and send them to a separate bucket.

S3 server access logs are delivered on a best-effort basis to a destination bucket and can be subject to delay, incompleteness, and missing entries for denied requests, making them unreliable for security forensics. They also require a separate logging bucket and careful lifecycle management to avoid unbounded log growth. For audit-grade trails, CloudTrail data events are preferred because they log all API calls deterministically, including failures.

Trap 3: Enable MFA Delete on the bucket.

MFA Delete protects against unauthorized permanent deletion by requiring a one-time authentication code for destructive versioning operations, such as permanently deleting a version or suspending versioning. However, it is not a recovery mechanism—if an object was deleted before versioning was enabled, or if MFA validation succeeds for an authorized action, that deletion cannot be undone by MFA Delete. Versioning is what provides the retained copies that make recovery possible; MFA Delete only adds a stronger permissions barrier.

A
Enable default encryption on the bucket using SSE-S3.
Why wrong: Default encryption with SSE-S3 encrypts objects at rest using an Amazon-managed AES-256 key, but it does not protect data in transit; you must also enforce TLS/HTTPS for uploads and downloads. Encryption addresses confidentiality only—it has no effect on preservation, deletion recovery, or access auditing. Therefore, SSE-S3 alone cannot satisfy a data protection strategy that requires retention and forensic visibility.
B
Enable AWS CloudTrail with data events for S3.
Enabling CloudTrail with data events for an S3 bucket records object-level operations such as GetObject, PutObject, DeleteObject, and HeadObject, capturing the IAM principal, source IP, and whether the request succeeded or failed. This creates an authoritative, queryable audit trail that can be searched in CloudTrail Lake or Athena and is essential for incident investigation, compliance reporting, and detecting compromised credentials. Unlike server access logs, CloudTrail data events reliably include failed attempts.
C
Enable S3 Versioning on the bucket.
Versioning causes every PutObject to create a new version rather than overwrite, and a DeleteObject operation inserts a delete marker while retaining all prior versions. If the marker is removed, the original object returns, enabling recovery after accidental deletion, ransomware overwrites, or application errors. This is the primary recovery control because it preserves data itself; however, lifecycle rules may permanently delete old versions, so expiration policies must match your recovery point objectives.
D
Enable S3 server access logs and send them to a separate bucket.
Why wrong: S3 server access logs are delivered on a best-effort basis to a destination bucket and can be subject to delay, incompleteness, and missing entries for denied requests, making them unreliable for security forensics. They also require a separate logging bucket and careful lifecycle management to avoid unbounded log growth. For audit-grade trails, CloudTrail data events are preferred because they log all API calls deterministically, including failures.
E
Enable MFA Delete on the bucket.
Why wrong: MFA Delete protects against unauthorized permanent deletion by requiring a one-time authentication code for destructive versioning operations, such as permanently deleting a version or suspending versioning. However, it is not a recovery mechanism—if an object was deleted before versioning was enabled, or if MFA validation succeeds for an authorized action, that deletion cannot be undone by MFA Delete. Versioning is what provides the retained copies that make recovery possible; MFA Delete only adds a stronger permissions barrier.

Question 3mediummultiple choice

A company uses AWS KMS to encrypt data at rest in Amazon S3. The security team requires that all encryption keys be automatically rotated every year. Which solution meets this requirement?

Trap 1: Use an AWS managed key and enable automatic rotation.

AWS managed keys already have automatic rotation enabled by the service, so enabling it is not an action you can take; more importantly, their fixed rotation schedule is not aligned with a yearly requirement, as AWS rotates these keys on a longer fixed cycle rather than annually. This option fails because you have no configuration control over the rotation period of an AWS managed key, and the stated yearly requirement would not be met.

Trap 2: Use a customer managed key with imported key material and enable…

Although a customer managed key is the right key family, imported key material disqualifies it from automatic rotation; KMS does not support automatic rotation for symmetric customer managed keys whose key material was imported. To use automatic rotation with a 365-day period, the key material must be generated and maintained by AWS KMS. This option therefore cannot meet the company's yearly rotation goal.

Trap 3: Use an AWS managed key and manually rotate it every year.

Manual rotation of an AWS managed key is not a supported operation because AWS owns and manages the entire lifecycle of these keys. You cannot create a new key version, replace key material, or trigger rotation on demand for an AWS managed key; only customer managed keys support manual rotation through alias updates or new key creation. Therefore, attempting to manually rotate an AWS managed key each year is invalid and cannot satisfy the compliance requirement.

A
Use an AWS managed key and enable automatic rotation.
Why wrong: AWS managed keys already have automatic rotation enabled by the service, so enabling it is not an action you can take; more importantly, their fixed rotation schedule is not aligned with a yearly requirement, as AWS rotates these keys on a longer fixed cycle rather than annually. This option fails because you have no configuration control over the rotation period of an AWS managed key, and the stated yearly requirement would not be met.
B
Use a customer managed key with imported key material and enable automatic rotation.
Why wrong: Although a customer managed key is the right key family, imported key material disqualifies it from automatic rotation; KMS does not support automatic rotation for symmetric customer managed keys whose key material was imported. To use automatic rotation with a 365-day period, the key material must be generated and maintained by AWS KMS. This option therefore cannot meet the company's yearly rotation goal.
C
Use a customer managed key and enable automatic rotation with a yearly rotation period.
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.
D
Use an AWS managed key and manually rotate it every year.
Why wrong: Manual rotation of an AWS managed key is not a supported operation because AWS owns and manages the entire lifecycle of these keys. You cannot create a new key version, replace key material, or trigger rotation on demand for an AWS managed key; only customer managed keys support manual rotation through alias updates or new key creation. Therefore, attempting to manually rotate an AWS managed key each year is invalid and cannot satisfy the compliance requirement.

Question 4easymultiple choice

Refer to the exhibit. An AWS KMS key policy includes the statement shown. The AdminRole tries to decrypt a ciphertext that was encrypted using the same KMS key with encryption context 'department=engineering'. What will happen?

Exhibit

Refer to the exhibit.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/AdminRole"
      },
      "Action": "kms:Decrypt",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:EncryptionContext:department": "finance"
        }
      }
    }
  ]
}

Trap 1: The decrypt operation succeeds because the role has kms:Decrypt…

An IAM policy that grants kms:Decrypt is not sufficient on its own because KMS authorization is the intersection of IAM permissions, the key policy, and grants. Even when the role is allowed to call Decrypt, the key policy's condition must also hold. Here, the key policy requires an encryption context of department=finance, and the request's context does not match, so the effective authorization fails and KMS denies the call.

Trap 2: The decrypt operation succeeds because the encryption context is…

Encryption context is not ignored during decryption; KMS treats it as authenticated data and uses it as an authorization condition. At encryption time, the context is cryptographically bound to the ciphertext, and the same context must be provided on decryption. If it differs, KMS rejects the request both because the authenticated data does not match and because the key policy condition cannot be satisfied, so the context cannot be disregarded.

Trap 3: The decrypt operation fails because the policy does not allow…

This statement mischaracterizes the failure. The key policy does allow kms:Decrypt, but only conditionally when the kms:EncryptionContext:department key equals finance. The problem is not that an unconditional Decrypt grant is missing; it is that the condition evaluates to false for the supplied encryption context. KMS therefore denies the operation because the policy's condition is not met, not because the policy fails to mention Decrypt.

A
The decrypt operation succeeds because the role has kms:Decrypt permission.
Why wrong: An IAM policy that grants kms:Decrypt is not sufficient on its own because KMS authorization is the intersection of IAM permissions, the key policy, and grants. Even when the role is allowed to call Decrypt, the key policy's condition must also hold. Here, the key policy requires an encryption context of department=finance, and the request's context does not match, so the effective authorization fails and KMS denies the call.
B
The decrypt operation succeeds because the encryption context is ignored during decryption.
Why wrong: Encryption context is not ignored during decryption; KMS treats it as authenticated data and uses it as an authorization condition. At encryption time, the context is cryptographically bound to the ciphertext, and the same context must be provided on decryption. If it differs, KMS rejects the request both because the authenticated data does not match and because the key policy condition cannot be satisfied, so the context cannot be disregarded.
C
The decrypt operation fails because the policy does not allow kms:Decrypt without matching context.
Why wrong: This statement mischaracterizes the failure. The key policy does allow kms:Decrypt, but only conditionally when the kms:EncryptionContext:department key equals finance. The problem is not that an unconditional Decrypt grant is missing; it is that the condition evaluates to false for the supplied encryption context. KMS therefore denies the operation because the policy's condition is not met, not because the policy fails to mention Decrypt.
D
The decrypt operation fails because the encryption context does not match the condition.
The key policy scopes kms:Decrypt to calls whose encryption context contains department=finance. The decrypt request supplies a different encryption context, so the kms:EncryptionContext:department condition key does not match. As a result, the condition in the key policy is false and KMS denies the Decrypt operation. This is expected behavior: encryption context conditions are a way to limit key usage to specific data or workloads.

Read the full NAT/PAT explanation →

Question 5mediumdrag order

Drag and drop the steps to configure a VPC with private subnets and NAT gateway for outbound internet access in the correct order.

Drag steps to the numbered slots on the right, or tap a step then tap a slot.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

5Step 5

Trap 1: Create VPC, then create subnets, then create NAT Gateway, then…

This is incorrect because the NAT Gateway requires a public subnet with a route to an Internet Gateway to function. If the Internet Gateway is created after the NAT Gateway, the NAT Gateway cannot be properly associated with a public subnet, leading to failure.

Trap 2: Create VPC, then create subnets, then create and attach Internet…

This is incorrect because updating route tables before creating the NAT Gateway results in a missing target for the private subnet route. The route tables need the NAT Gateway ID to be specified, which is not available until the NAT Gateway is created.

Trap 3: Create VPC, then create NAT Gateway, then create subnets, then…

This order is invalid because a NAT Gateway cannot be provisioned without an existing subnet ID — AWS returns an error if the subnet does not exist, since the gateway is deployed as an elastic network interface inside that subnet. Even if creation were possible, the NAT Gateway must be placed in a public subnet that already has an attached Internet Gateway and a default (0.0.0.0/0) route to it, which is not present at this stage. The NAT Gateway would therefore be orphaned with no outbound path, and the later route table update for private subnets would reference a NAT device that cannot function.

A
Create VPC, then create subnets, then create and attach Internet Gateway, then create NAT Gateway, then update route tables.
This order ensures that the VPC exists, subnets are available for resources, the Internet Gateway is attached to allow public access, the NAT Gateway is deployed in a public subnet, and finally route tables are configured to route private subnet traffic through the NAT Gateway for outbound internet access.
B
Create VPC, then create subnets, then create NAT Gateway, then create and attach Internet Gateway, then update route tables.
Why wrong: This is incorrect because the NAT Gateway requires a public subnet with a route to an Internet Gateway to function. If the Internet Gateway is created after the NAT Gateway, the NAT Gateway cannot be properly associated with a public subnet, leading to failure.
C
Create VPC, then create subnets, then create and attach Internet Gateway, then update route tables, then create NAT Gateway.
Why wrong: This is incorrect because updating route tables before creating the NAT Gateway results in a missing target for the private subnet route. The route tables need the NAT Gateway ID to be specified, which is not available until the NAT Gateway is created.
D
Create VPC, then create NAT Gateway, then create subnets, then create and attach Internet Gateway, then update route tables.
Why wrong: This order is invalid because a NAT Gateway cannot be provisioned without an existing subnet ID — AWS returns an error if the subnet does not exist, since the gateway is deployed as an elastic network interface inside that subnet. Even if creation were possible, the NAT Gateway must be placed in a public subnet that already has an attached Internet Gateway and a default (0.0.0.0/0) route to it, which is not present at this stage. The NAT Gateway would therefore be orphaned with no outbound path, and the later route table update for private subnets would reference a NAT device that cannot function.

Question 6mediummatching

Match each AWS security-related acronym to its definition.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Center for Internet Security

Payment Card Industry Data Security Standard

Health Insurance Portability and Accountability Act

System and Organization Controls

International standard for information security management

Trap 1: SOC: US law designed to provide privacy standards to protect…

This definition actually describes HIPAA, not SOC. SOC (System and Organization Controls) reports attest to service organization controls against AICPA trust service criteria; they have nothing to do with medical-record privacy or US healthcare law. The privacy and confidentiality protections for patients' medical records and other health information are codified in HIPAA, not in any SOC report published under AICPA attestation standards.

Trap 2: PCI DSS: US government program that standardizes security…

This definition confuses PCI DSS with FedRAMP. PCI DSS is not a US government program or a cloud-authorization framework; it is a private-sector security standard required by the payment-card brands for organizations handling cardholder data. FedRAMP, in contrast, standardizes security assessment, authorization, and continuous monitoring specifically for cloud products and services used by federal agencies.

A
SOC: Report on controls at a service organization relevant to security, availability, processing integrity, confidentiality, or privacy.
SOC reports (System and Organization Controls) are independent attestation reports issued by a CPA firm, examining controls at a service organization against the AICPA Trust Services Criteria (security, availability, processing integrity, confidentiality, privacy). SOC 1 focuses on controls relevant to user entities' internal control over financial reporting (ICFR), while SOC 2 and SOC 3 focus on the five trust service criteria; they are not laws or government programs but bridge audited evidence for customers.
B
PCI DSS: Set of security standards designed to ensure that all companies that accept, process, store or transmit credit card information maintain a secure environment.
The Payment Card Industry Data Security Standard (PCI DSS) is a contractual/industry standard mandated by the card brands (Visa, Mastercard, etc.), not a US law or government program. It applies to any entity that stores, processes, or transmits cardholder data, and sets twelve baseline requirements spanning network security, encryption, access control, and ongoing monitoring. Compliance is validated via self-assessment questionnaires (SAQ) or a Report on Compliance (ROC) by an approved scanning vendor/assessor.
C
HIPAA: US law designed to provide privacy standards to protect patients' medical records and other health information.
The Health Insurance Portability and Accountability Act is a US federal statute enacted in 1996 that created national privacy and security rules for protected health information (PHI). Its Privacy Rule governs permissible uses and disclosures of PHI by covered entities and business associates, while the Security Rule mandates administrative, physical, and technical safeguards for electronic PHI (e-PHI). HIPAA is enforced by the HHS Office for Civil Rights, not a security assessment framework for cloud services.
D
FedRAMP: US government program that standardizes security assessment, authorization, and continuous monitoring for cloud products and services.
The Federal Risk and Authorization Management Program (FedRAMP) is a US government initiative established to provide a standardized, repeatable approach for assessing, authorizing, and continuously monitoring cloud service offerings used by federal agencies. It relies on NIST SP 800-53 controls and requires a third-party assessment organization (3PAO) to validate an SSP and produce deliverables that allow a Joint Authorization Board (JAB) or agency to grant an Authority to Operate (ATO). It is neither a law nor a data-specific standard, but an accreditation process for cloud providers.
E
SOC: US law designed to provide privacy standards to protect patients' medical records and other health information.
Why wrong: This definition actually describes HIPAA, not SOC. SOC (System and Organization Controls) reports attest to service organization controls against AICPA trust service criteria; they have nothing to do with medical-record privacy or US healthcare law. The privacy and confidentiality protections for patients' medical records and other health information are codified in HIPAA, not in any SOC report published under AICPA attestation standards.
F
PCI DSS: US government program that standardizes security assessment, authorization, and continuous monitoring for cloud products and services.
Why wrong: This definition confuses PCI DSS with FedRAMP. PCI DSS is not a US government program or a cloud-authorization framework; it is a private-sector security standard required by the payment-card brands for organizations handling cardholder data. FedRAMP, in contrast, standardizes security assessment, authorization, and continuous monitoring specifically for cloud products and services used by federal agencies.

Question 7easymultiple choice

A company wants to protect data at rest for an Amazon RDS for PostgreSQL database. Which AWS service should be used to manage the encryption keys?

Trap 1: AWS CloudHSM

AWS CloudHSM provides dedicated single-tenant hardware security modules where you control the HSMs and manage your own keys. However, Amazon RDS does not use CloudHSM as its default or supported encryption mechanism for data at rest; RDS encryption must use keys managed through AWS KMS. While CloudHSM is a valid option for other high-control encryption scenarios, it cannot be used to encrypt RDS storage natively, so this answer is incorrect.

Trap 2: AWS Certificate Manager (ACM)

AWS Certificate Manager (ACM) issues and manages public or private TLS/SSL certificates that are used to encrypt data in transit, such as connections between your application and an RDS instance. While ACM can provision certificates that RDS uses for TLS connections to the database, it does not perform or manage encryption of the physical data files on disk. Because the question specifically asks about protecting data at rest, ACM's transport-layer role is unrelated, making it an incorrect choice.

Trap 3: AWS Secrets Manager

AWS Secrets Manager is designed to centrally store and rotate database credentials, API keys, and other secrets, not to manage the underlying encryption keys that decrypt your RDS data volumes. Even though RDS encryption involves managing passwords for access, Secrets Manager does not create or control the KMS CMKs that RDS uses for encrypting data at rest. Therefore, while Secrets Manager is a security-related service, it does not satisfy the data-at-rest encryption key requirement, so it is incorrect.

A
AWS CloudHSM
Why wrong: AWS CloudHSM provides dedicated single-tenant hardware security modules where you control the HSMs and manage your own keys. However, Amazon RDS does not use CloudHSM as its default or supported encryption mechanism for data at rest; RDS encryption must use keys managed through AWS KMS. While CloudHSM is a valid option for other high-control encryption scenarios, it cannot be used to encrypt RDS storage natively, so this answer is incorrect.
B
AWS Key Management Service (KMS)
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.
C
AWS Certificate Manager (ACM)
Why wrong: AWS Certificate Manager (ACM) issues and manages public or private TLS/SSL certificates that are used to encrypt data in transit, such as connections between your application and an RDS instance. While ACM can provision certificates that RDS uses for TLS connections to the database, it does not perform or manage encryption of the physical data files on disk. Because the question specifically asks about protecting data at rest, ACM's transport-layer role is unrelated, making it an incorrect choice.
D
AWS Secrets Manager
Why wrong: AWS Secrets Manager is designed to centrally store and rotate database credentials, API keys, and other secrets, not to manage the underlying encryption keys that decrypt your RDS data volumes. Even though RDS encryption involves managing passwords for access, Secrets Manager does not create or control the KMS CMKs that RDS uses for encrypting data at rest. Therefore, while Secrets Manager is a security-related service, it does not satisfy the data-at-rest encryption key requirement, so it is incorrect.

Question 8hardmulti select

A company has a requirement to automatically rotate encryption keys for S3 objects every 90 days. They are using SSE-KMS with a customer managed key. Which combination of actions will meet the requirement without breaking access to existing objects? (Choose two.)

Trap 1: Configure an S3 lifecycle policy to re-encrypt objects

Incorrect. An S3 lifecycle policy does not re-encrypt objects; it transitions objects to different storage classes or expires them.

Trap 2: Manually rotate the key every 90 days and re-encrypt all objects

Incorrect. Manually rotating the key and re-encrypting all objects is not a combination; it is a single action, and the question asks for two actions. Additionally, manual rotation is not automatic.

Trap 3: Delete the existing key and create a new one each 90 days

Incorrect. Deleting the existing key breaks access to existing objects, as they cannot be decrypted.

A
Configure an S3 lifecycle policy to re-encrypt objects
Why wrong: Incorrect. An S3 lifecycle policy does not re-encrypt objects; it transitions objects to different storage classes or expires them.
B
Use S3 Batch Operations to re-encrypt existing objects with the new key
Correct. S3 Batch Operations can re-encrypt existing objects with a new key, and the old key remains active for decryption.
C
Manually rotate the key every 90 days and re-encrypt all objects
Why wrong: Incorrect. Manually rotating the key and re-encrypting all objects is not a combination; it is a single action, and the question asks for two actions. Additionally, manual rotation is not automatic.
D
Delete the existing key and create a new one each 90 days
Why wrong: Incorrect. Deleting the existing key breaks access to existing objects, as they cannot be decrypted.
E
Enable automatic key rotation in AWS KMS for the customer managed key
Why wrong: Incorrect. AWS KMS automatic key rotation for customer managed keys is annual (365 days), not every 90 days, so it does not satisfy the requirement.

Question 9mediummultiple choice

A company uses AWS KMS to encrypt EBS volumes. The security team wants to ensure that when an EC2 instance is launched, the attached EBS volumes are always encrypted using a specific customer managed key. Which action will enforce this?

Trap 1: Create an IAM role that requires the ec2:RunInstances action to…

An IAM role merely defines a set of permissions that a principal can assume; it does not globally enforce encryption key selection. While you can attach an IAM policy to a role that uses a kms:KeyId condition on ec2:RunInstances, that policy only affects the role's own permissions and can be bypassed by any user or service that does not assume the role or that has an alternative allow. Moreover, the proposed approach conflates roles with policies—the condition belongs on an IAM policy, not on the role itself, and it still would not cover all launch paths such as EC2 launch templates or the console.

Trap 2: Configure the KMS key policy to allow only the specific key for EBS…

A KMS key policy determines which principals can use that specific key for cryptographic operations, but it cannot control which key a caller chooses when launching an EC2 instance. The condition in a key policy only applies to requests that target that key; it has no authority over requests that use a different key or the default EBS key. To enforce a specific key, you need a policy that is evaluated at the EC2 RunInstances action, such as an SCP, not a key policy attached to the key itself.

Trap 3: Enable encryption by default for EBS volumes in the account

EBS encryption by default causes all new volumes to be encrypted, but it uses the service default key (aws/ebs) unless a different key is explicitly specified in the launch request. The requirement is to force a particular customer managed key, which default encryption does not do—an instance can still be launched with the default key or another valid key. Default encryption is a baseline data-at-rest control, not an enforcement mechanism for a specific key choice; an SCP with a kms:KeyId condition is needed to constrain that choice.

A
Use a service control policy (SCP) to deny ec2:RunInstances if the volume encryption key is not the required key
An SCP attached to the account, organizational unit, or root can deny ec2:RunInstances when the kms:KeyId condition key does not match the required customer managed key ARN. This works at the AWS Organizations level, so it applies to every principal in the account, including the root user, and cannot be overridden by an IAM policy. It is the only preventive control among these options that consistently enforces use of the specific key for every new EBS volume at launch.
B
Create an IAM role that requires the ec2:RunInstances action to include the kms:KeyId condition
Why wrong: An IAM role merely defines a set of permissions that a principal can assume; it does not globally enforce encryption key selection. While you can attach an IAM policy to a role that uses a kms:KeyId condition on ec2:RunInstances, that policy only affects the role's own permissions and can be bypassed by any user or service that does not assume the role or that has an alternative allow. Moreover, the proposed approach conflates roles with policies—the condition belongs on an IAM policy, not on the role itself, and it still would not cover all launch paths such as EC2 launch templates or the console.
C
Configure the KMS key policy to allow only the specific key for EBS encryption
Why wrong: A KMS key policy determines which principals can use that specific key for cryptographic operations, but it cannot control which key a caller chooses when launching an EC2 instance. The condition in a key policy only applies to requests that target that key; it has no authority over requests that use a different key or the default EBS key. To enforce a specific key, you need a policy that is evaluated at the EC2 RunInstances action, such as an SCP, not a key policy attached to the key itself.
D
Enable encryption by default for EBS volumes in the account
Why wrong: EBS encryption by default causes all new volumes to be encrypted, but it uses the service default key (aws/ebs) unless a different key is explicitly specified in the launch request. The requirement is to force a particular customer managed key, which default encryption does not do—an instance can still be launched with the default key or another valid key. Default encryption is a baseline data-at-rest control, not an enforcement mechanism for a specific key choice; an SCP with a kms:KeyId condition is needed to constrain that choice.

Question 10hardmultiple choice

A company stores sensitive data in an S3 bucket with versioning enabled. They want to ensure that objects are encrypted at rest using SSE-KMS. A security audit reveals that some older object versions are encrypted with SSE-S3. What is the MOST efficient way to re-encrypt those older versions with SSE-KMS?

Trap 1: Create a lifecycle policy to transition objects to a new storage…

A lifecycle policy is designed to transition objects between storage classes or expire them, not to alter their server-side encryption attributes. When S3 transitions an object, it copies or moves it using the existing encryption settings—if the object is SSE-KMS it stays encrypted with the original KMS key, and if it's SSE-S3 it remains SSE-S3. Lifecycle actions do not accept a new KMS key or re-encrypt content, so they are irrelevant to changing the encryption method.

Trap 2: Use the AWS CLI s3 sync command with the --sse aws:kms option

The AWS CLI s3 sync command only uploads objects that are new or changed based on size and last-modified time, so objects that already exist are skipped entirely, and existing versions are never rewritten. Even with --sse aws:kms, the key is only applied to newly uploaded files, not to any current or historical versions in a versioned bucket. Sync would create a new version only if the local file is different, but it cannot enumerate and re-encrypt every existing version.

Trap 3: Manually re-upload the objects via the S3 console

Manually re-uploading via the S3 console cannot replace an existing object version in place; uploading to the same key creates a new version ID, leaving the original version with its old SSE-KMS key intact. For a versioned bucket, you would need to delete and re-upload every historical version, which also loses metadata like object tags and cannot guarantee consistent application of the new KMS key. It is also operationally unscalable if there are many objects.

A
Create a lifecycle policy to transition objects to a new storage class
Why wrong: A lifecycle policy is designed to transition objects between storage classes or expire them, not to alter their server-side encryption attributes. When S3 transitions an object, it copies or moves it using the existing encryption settings—if the object is SSE-KMS it stays encrypted with the original KMS key, and if it's SSE-S3 it remains SSE-S3. Lifecycle actions do not accept a new KMS key or re-encrypt content, so they are irrelevant to changing the encryption method.
B
Use the AWS CLI s3 sync command with the --sse aws:kms option
Why wrong: The AWS CLI s3 sync command only uploads objects that are new or changed based on size and last-modified time, so objects that already exist are skipped entirely, and existing versions are never rewritten. Even with --sse aws:kms, the key is only applied to newly uploaded files, not to any current or historical versions in a versioned bucket. Sync would create a new version only if the local file is different, but it cannot enumerate and re-encrypt every existing version.
C
Use S3 Batch Operations to copy objects with SSE-KMS encryption
S3 Batch Operations can issue a CopyObject call for every object version listed in an S3 Inventory manifest, specifying SSE-KMS with a chosen aws:kms key so that each copied version is re-encrypted. Because Batch Operations preserves the original object key and version ID when copying within the same bucket, it achieves in-place-style re-encryption without altering the logical object. It also provides a completion report, making it the only option that can systematically rewrite historical versions at scale.
D
Manually re-upload the objects via the S3 console
Why wrong: Manually re-uploading via the S3 console cannot replace an existing object version in place; uploading to the same key creates a new version ID, leaving the original version with its old SSE-KMS key intact. For a versioned bucket, you would need to delete and re-upload every historical version, which also loses metadata like object tags and cannot guarantee consistent application of the new KMS key. It is also operationally unscalable if there are many objects.

Question 11easymultiple choice

A company needs to ensure that data in transit between an on-premises data center and Amazon S3 is encrypted. Which AWS service should be used to establish a dedicated encrypted connection?

Trap 1: AWS Transit Gateway

AWS Transit Gateway is a central hub that interconnects VPCs, VPNs, and Direct Connect attachments, but it is not a connection type that by itself carries traffic from your on-premises environment. To use Transit Gateway, you must first attach a separate underlying connectivity service such as a Site-to-Site VPN or Direct Connect. It provides routing and traffic management, not the physical or encrypted data path, so it cannot be the direct answer for ensuring secure in-transit data between on-premises and AWS.

Trap 2: AWS Site-to-Site VPN

AWS Site-to-Site VPN creates an encrypted IPsec tunnel between your on-premises router and an AWS VPN endpoint, so it does protect data in transit. However, those tunnels traverse the public internet, meaning the connection is not dedicated and is subject to internet-based variability, latency, and potential congestion. If the company's requirement includes a private, dedicated link between the data center and AWS, Site-to-Site VPN alone falls short because it lacks the dedicated physical infrastructure that Direct Connect provides.

Trap 3: AWS Client VPN

AWS Client VPN is a managed, OpenVPN-based remote access service that enables individual users to securely connect from their local devices to AWS or on-premises networks. It is not designed for persistent site-to-site connectivity between an on-premises data center and AWS, which would require a network-to-network tunnel. The scenario involves interconnecting corporate networks, not remote user clients, so Client VPN is architecturally inappropriate for this requirement.

A
AWS Transit Gateway
Why wrong: AWS Transit Gateway is a central hub that interconnects VPCs, VPNs, and Direct Connect attachments, but it is not a connection type that by itself carries traffic from your on-premises environment. To use Transit Gateway, you must first attach a separate underlying connectivity service such as a Site-to-Site VPN or Direct Connect. It provides routing and traffic management, not the physical or encrypted data path, so it cannot be the direct answer for ensuring secure in-transit data between on-premises and AWS.
B
AWS Site-to-Site VPN
Why wrong: AWS Site-to-Site VPN creates an encrypted IPsec tunnel between your on-premises router and an AWS VPN endpoint, so it does protect data in transit. However, those tunnels traverse the public internet, meaning the connection is not dedicated and is subject to internet-based variability, latency, and potential congestion. If the company's requirement includes a private, dedicated link between the data center and AWS, Site-to-Site VPN alone falls short because it lacks the dedicated physical infrastructure that Direct Connect provides.
C
AWS Direct Connect with VPN
AWS Direct Connect with VPN is the correct combination because Direct Connect gives you a dedicated, private network connection that bypasses the public internet, offering consistent latency and bandwidth. Since Direct Connect alone does not encrypt your traffic, the VPN overlay (typically IPsec) is added to encrypt data in transit over that private connection. This pairing satisfies both explicit requirements: a dedicated transport path and encryption for all data between the on-premises environment and AWS.
D
AWS Client VPN
Why wrong: AWS Client VPN is a managed, OpenVPN-based remote access service that enables individual users to securely connect from their local devices to AWS or on-premises networks. It is not designed for persistent site-to-site connectivity between an on-premises data center and AWS, which would require a network-to-network tunnel. The scenario involves interconnecting corporate networks, not remote user clients, so Client VPN is architecturally inappropriate for this requirement.

Question 12hardmultiple choice

A company is designing a data protection strategy for an Amazon RDS for MySQL database. The database is 2 TB in size and stores financial data. The compliance team requires that database snapshots be encrypted at rest and that encryption keys be rotated every year. Which solution meets these requirements with the LEAST operational overhead?

Trap 1: Copy each snapshot to a new snapshot encrypted with a new KMS key

Copying each snapshot to a new snapshot encrypted with a new KMS key is a manual, one-off operation. You would need to perform this for every existing and future snapshot, promote the copied snapshots, and delete the originals; the live RDS instance's storage encryption remains tied to the original key. This approach does not provide automatic, continuous protection and introduces significant operational overhead and room for error.

Trap 2: Export snapshots to S3 and use S3 Batch Operations to re-encrypt…

Exporting RDS snapshots to Amazon S3 and running S3 Batch Operations to re-encrypt the exports adds a complex data pipeline without addressing the RDS-encrypted object itself. The export produces logical data files (e.g., Parquet) rather than the native RDS snapshot, and a restore/import would be required to apply the new encryption to the database. This is high operational overhead and not a supported method for automatically rotating the KMS key used by RDS.

Trap 3: Use a different KMS key for each snapshot and rotate the key…

Using a different KMS key for each snapshot and manually rotating the key does not match how RDS encryption keys work. A snapshot inherits the KMS key of the source RDS instance, and to change that key you would have to copy the snapshot and specify the new key, then restore the instance from that copy—there is no native per-snapshot key assignment. Manual rotation of KMS keys also fails to re-encrypt existing data automatically; RDS would continue using the original key material until you take disruptive migration steps.

A
Copy each snapshot to a new snapshot encrypted with a new KMS key
Why wrong: Copying each snapshot to a new snapshot encrypted with a new KMS key is a manual, one-off operation. You would need to perform this for every existing and future snapshot, promote the copied snapshots, and delete the originals; the live RDS instance's storage encryption remains tied to the original key. This approach does not provide automatic, continuous protection and introduces significant operational overhead and room for error.
B
Export snapshots to S3 and use S3 Batch Operations to re-encrypt them
Why wrong: Exporting RDS snapshots to Amazon S3 and running S3 Batch Operations to re-encrypt the exports adds a complex data pipeline without addressing the RDS-encrypted object itself. The export produces logical data files (e.g., Parquet) rather than the native RDS snapshot, and a restore/import would be required to apply the new encryption to the database. This is high operational overhead and not a supported method for automatically rotating the KMS key used by RDS.
C
Use a different KMS key for each snapshot and rotate the key manually
Why wrong: Using a different KMS key for each snapshot and manually rotating the key does not match how RDS encryption keys work. A snapshot inherits the KMS key of the source RDS instance, and to change that key you would have to copy the snapshot and specify the new key, then restore the instance from that copy—there is no native per-snapshot key assignment. Manual rotation of KMS keys also fails to re-encrypt existing data automatically; RDS would continue using the original key material until you take disruptive migration steps.
D
Enable automatic key rotation in AWS KMS for the KMS key used for RDS encryption
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.

Question 13easymulti select

A company wants to protect data at rest for an Amazon S3 bucket that contains sensitive data. Which combination of actions provides the MOST comprehensive protection? (Choose two.)

Trap 1: Enable versioning on the bucket

Enabling versioning preserves every version of an object, including overwrites and deletions, which can aid in recovery and audit, but it does not alter how the object's plaintext bytes are stored in S3. Versioning is a data protection control for accidental/malicious deletion or corruption, not a confidentiality control. Since S3 still stores all versions in the same underlying encrypted-or-unencrypted form, enabling versioning alone leaves data at risk of being readable if the bucket is not encrypted.

Trap 2: Enable MFA Delete on the bucket

MFA Delete adds an extra authentication requirement for permanently deleting object versions or suspending versioning on a versioned bucket, which protects against accidental or unauthorized destructive actions. It has no effect on how object data is encrypted or stored; enabling MFA Delete does not encrypt the object contents at rest, nor does it alter the physical storage representation. Thus, while valuable for integrity and availability, it is not a solution for the confidentiality requirement of protecting data at rest.

Trap 3: Configure a lifecycle policy to transition objects to Glacier

Lifecycle policies transition objects to Amazon S3 Glacier or Glacier Deep Archive based on age or other rules, which can reduce storage costs and provide another copy, but Glacier itself stores the objects in the same unencrypted-or-pre-existing-encryption state. The transition action does not apply any encryption; if the source object was SSE-S3-encrypted it remains encrypted, but if it was uploaded as plaintext it stays plaintext in Glacier unless you also configure bucket default encryption. Lifecycle management is about storage lifecycle and cost optimization, not encryption at rest.

A
Enable versioning on the bucket
Why wrong: Enabling versioning preserves every version of an object, including overwrites and deletions, which can aid in recovery and audit, but it does not alter how the object's plaintext bytes are stored in S3. Versioning is a data protection control for accidental/malicious deletion or corruption, not a confidentiality control. Since S3 still stores all versions in the same underlying encrypted-or-unencrypted form, enabling versioning alone leaves data at risk of being readable if the bucket is not encrypted.
B
Enable default encryption on the bucket with SSE-S3
Bucket default encryption with SSE-S3 ensures that every newly written object is automatically encrypted at rest using S3-managed keys, satisfying the core of the 'protect data at rest' requirement. SSE-S3 uses AES-256 to encrypt each S3 object with a unique key, which is itself encrypted by a regularly rotated root key managed by AWS. Because encryption is performed transparently on write and decryption on read, enabling this default makes encryption the bucket's baseline behavior without requiring changes to client applications.
C
Configure a bucket policy to deny requests over HTTP
A bucket policy that denies requests over HTTP (using a Condition such as aws:SecureTransport false) enforces that all API operations must arrive over HTTPS/TLS, protecting data during transit between clients and S3. However, this policy applies only to the transport channel; once data arrives, S3 still stores it as-is unless encryption at rest is separately configured. Therefore, while this is a valid and important control for encryption in transit, it does not address the stated requirement to protect data at rest.
D
Enable MFA Delete on the bucket
Why wrong: MFA Delete adds an extra authentication requirement for permanently deleting object versions or suspending versioning on a versioned bucket, which protects against accidental or unauthorized destructive actions. It has no effect on how object data is encrypted or stored; enabling MFA Delete does not encrypt the object contents at rest, nor does it alter the physical storage representation. Thus, while valuable for integrity and availability, it is not a solution for the confidentiality requirement of protecting data at rest.
E
Configure a lifecycle policy to transition objects to Glacier
Why wrong: Lifecycle policies transition objects to Amazon S3 Glacier or Glacier Deep Archive based on age or other rules, which can reduce storage costs and provide another copy, but Glacier itself stores the objects in the same unencrypted-or-pre-existing-encryption state. The transition action does not apply any encryption; if the source object was SSE-S3-encrypted it remains encrypted, but if it was uploaded as plaintext it stays plaintext in Glacier unless you also configure bucket default encryption. Lifecycle management is about storage lifecycle and cost optimization, not encryption at rest.

Question 14hardmultiple choice

A company uses AWS KMS to encrypt data in Amazon S3. The security team receives an alert that an IAM user is attempting to decrypt data using a key that they do not have access to. Which AWS service can be used to monitor and alert on such unauthorized KMS API calls?

Trap 1: Amazon GuardDuty

Amazon GuardDuty is a continuous threat detection service that ingests AWS CloudTrail management events, VPC flow logs, and DNS query logs to identify malicious activity, but it does not provide configurable, event-driven alerting on individual KMS API operations such as kms:Decrypt or kms:ScheduleKeyDeletion. While GuardDuty can flag anomalies involving IAM principals with KMS permissions, it cannot be relied upon to emit a specific alarm every time a particular KMS action occurs. For that degree of control, you need CloudTrail logs combined with CloudWatch Alarms.

Trap 2: AWS Config

AWS Config is designed to record and evaluate resource configuration changes, such as alterations to a KMS key policy or changes in key rotation status, and to trigger rules for compliance. It does not ingest or process data-plane or control-plane API calls like kms:Decrypt, kms:Encrypt, or kms:PutKeyPolicy, so it cannot generate a real-time alert based on a single historical KMS API request. CloudTrail is the correct source for KMS API activity, not AWS Config.

Trap 3: Amazon Inspector

Amazon Inspector is a vulnerability management service that performs automated security assessments on EC2 instances, ECR container images, and AWS Lambda functions, checking for software vulnerabilities, unintended network exposure, and missing patches. It has no integration with KMS key usage, no visibility into AWS API call patterns, and cannot evaluate or alarm on KMS operations such as kms:Decrypt. Inspector is therefore completely unsuitable for monitoring KMS encryption activity in S3.

A
Amazon GuardDuty
Why wrong: Amazon GuardDuty is a continuous threat detection service that ingests AWS CloudTrail management events, VPC flow logs, and DNS query logs to identify malicious activity, but it does not provide configurable, event-driven alerting on individual KMS API operations such as kms:Decrypt or kms:ScheduleKeyDeletion. While GuardDuty can flag anomalies involving IAM principals with KMS permissions, it cannot be relied upon to emit a specific alarm every time a particular KMS action occurs. For that degree of control, you need CloudTrail logs combined with CloudWatch Alarms.
B
AWS Config
Why wrong: AWS Config is designed to record and evaluate resource configuration changes, such as alterations to a KMS key policy or changes in key rotation status, and to trigger rules for compliance. It does not ingest or process data-plane or control-plane API calls like kms:Decrypt, kms:Encrypt, or kms:PutKeyPolicy, so it cannot generate a real-time alert based on a single historical KMS API request. CloudTrail is the correct source for KMS API activity, not AWS Config.
C
AWS CloudTrail with CloudWatch Alarms
AWS CloudTrail captures every KMS API request as a management event, including kms:Encrypt, kms:Decrypt, and kms:ScheduleKeyDeletion, and delivers those logs to an S3 bucket. You can then define a CloudWatch Logs metric filter on the JSON field of the CloudTrail event to match a specific KMS action, and attach a CloudWatch Alarm to that metric to trigger an SNS notification. This combination provides the required trackable, alertable audit trail for KMS API calls made when S3 encrypts objects using customer-managed KMS keys.
D
Amazon Inspector
Why wrong: Amazon Inspector is a vulnerability management service that performs automated security assessments on EC2 instances, ECR container images, and AWS Lambda functions, checking for software vulnerabilities, unintended network exposure, and missing patches. It has no integration with KMS key usage, no visibility into AWS API call patterns, and cannot evaluate or alarm on KMS operations such as kms:Decrypt. Inspector is therefore completely unsuitable for monitoring KMS encryption activity in S3.

Question 15easymultiple choice

A company needs to encrypt data in transit between an EC2 instance and an RDS database. Which option should be used?

Trap 1: Enable encryption at rest for the RDS instance

Enabling encryption at rest for an RDS instance uses AES-256 to encrypt the underlying storage volumes, automated backups, snapshots, and read replicas. That protection is entirely transparent to network traffic, so the SQL queries and credentials moving between your EC2 instance and the database endpoint can still be captured and read from the wire. This setting is required for compliance at rest, but it does nothing for data in transit.

Trap 2: Use an AWS KMS key to encrypt the connection

AWS KMS is a managed service that creates, rotates, and controls envelope encryption keys; it does not sit in the network path between EC2 and RDS. A KMS key can be used to encrypt data at rest, or to generate data keys for client-side encryption, but it cannot establish an encrypted session on the database connection itself. Encrypting the connection requires a protocol-level mechanism such as TLS, which performs its own handshake and exchanges session keys, independent of any KMS API call.

Trap 3: Enable EBS encryption on the EC2 instance

EBS encryption protects the EC2 instance's attached block device at rest by encrypting data as it is written to the underlying volume, and transparently decrypting it when read by the kernel. That is a storage-layer feature that has no effect on the network interfaces or TCP sockets used to reach the RDS database. The traffic between the EC2 instance's ENI and the RDS endpoint remains plaintext unless an application-level encryption protocol such as TLS is applied, so EBS encryption cannot prevent sniffing or eavesdropping in transit.

A
Enable encryption at rest for the RDS instance
Why wrong: Enabling encryption at rest for an RDS instance uses AES-256 to encrypt the underlying storage volumes, automated backups, snapshots, and read replicas. That protection is entirely transparent to network traffic, so the SQL queries and credentials moving between your EC2 instance and the database endpoint can still be captured and read from the wire. This setting is required for compliance at rest, but it does nothing for data in transit.
B
Configure the database to use SSL/TLS connections
To encrypt data in transit, you must configure the database client and server to negotiate a TLS session. On RDS, this means importing the Amazon RDS CA certificate into the client's trust store and setting the database parameter group's `rds.force_ssl` (PostgreSQL) or `require_secure_transport` (MySQL/MariaDB) parameter to 1. Once enabled, TLS encrypts the entire database protocol stream, including authentication, query text, and result sets, and the client can verify that it is connecting to the genuine RDS endpoint, not an impostor.
C
Use an AWS KMS key to encrypt the connection
Why wrong: AWS KMS is a managed service that creates, rotates, and controls envelope encryption keys; it does not sit in the network path between EC2 and RDS. A KMS key can be used to encrypt data at rest, or to generate data keys for client-side encryption, but it cannot establish an encrypted session on the database connection itself. Encrypting the connection requires a protocol-level mechanism such as TLS, which performs its own handshake and exchanges session keys, independent of any KMS API call.
D
Enable EBS encryption on the EC2 instance
Why wrong: EBS encryption protects the EC2 instance's attached block device at rest by encrypting data as it is written to the underlying volume, and transparently decrypting it when read by the kernel. That is a storage-layer feature that has no effect on the network interfaces or TCP sockets used to reach the RDS database. The traffic between the EC2 instance's ENI and the RDS endpoint remains plaintext unless an application-level encryption protocol such as TLS is applied, so EBS encryption cannot prevent sniffing or eavesdropping in transit.

Question 16mediummultiple choice

A company uses S3 to store confidential documents. They want to ensure that objects are encrypted at rest using customer-provided encryption keys (SSE-C). Which header must be included in every PUT request?

Trap 1: x-amz-server-side-encryption: AES256

The x-amz-server-side-encryption: AES256 header selects SSE-S3, where AWS owns and manages the encryption keys, not the caller. In an SSE-C request, the algorithm must be declared with x-amz-server-side-encryption-customer-algorithm, and this standard AES256 header does not trigger customer-key validation. It encrypts objects with S3-managed keys, so it cannot satisfy a requirement for customer-provided key material.

Trap 2: x-amz-server-side-encryption-customer-key: <key>

The x-amz-server-side-encryption-customer-key header is mandatory for SSE-C, but it is incomplete on its own because S3 requires it to be accompanied by x-amz-server-side-encryption-customer-algorithm: AES256. If you send only a key without an algorithm, Amazon S3 rejects the request with an error because a customer-supplied key without a declared cipher is ambiguous. The key value must also be base64-encoded, and optional x-amz-server-side-encryption-customer-key-MD5 can be used for integrity verification, so this header alone is not a valid SSE-C request.

Trap 3: x-amz-server-side-encryption: aws:kms

The x-amz-server-side-encryption: aws:kms header selects SSE-KMS, where a KMS key performs envelope encryption and manages the key hierarchy on AWS's side. It does not accept a customer-supplied key in the request, so it cannot be used for SSE-C scenarios. Using this header also introduces KMS API costs and requires appropriate IAM permissions and key policies, meaning the encryption key is owned and operated by AWS rather than exclusively by the company.

A
x-amz-server-side-encryption: AES256
Why wrong: The x-amz-server-side-encryption: AES256 header selects SSE-S3, where AWS owns and manages the encryption keys, not the caller. In an SSE-C request, the algorithm must be declared with x-amz-server-side-encryption-customer-algorithm, and this standard AES256 header does not trigger customer-key validation. It encrypts objects with S3-managed keys, so it cannot satisfy a requirement for customer-provided key material.
B
x-amz-server-side-encryption-customer-key: <key>
Why wrong: The x-amz-server-side-encryption-customer-key header is mandatory for SSE-C, but it is incomplete on its own because S3 requires it to be accompanied by x-amz-server-side-encryption-customer-algorithm: AES256. If you send only a key without an algorithm, Amazon S3 rejects the request with an error because a customer-supplied key without a declared cipher is ambiguous. The key value must also be base64-encoded, and optional x-amz-server-side-encryption-customer-key-MD5 can be used for integrity verification, so this header alone is not a valid SSE-C request.
C
x-amz-server-side-encryption-customer-algorithm: AES256
The x-amz-server-side-encryption-customer-algorithm: AES256 header is what activates SSE-C and instructs S3 to use a caller-supplied AES-256 key rather than AWS-managed or KMS-owned keys. Once this header is present, S3 expects the corresponding x-amz-server-side-encryption-customer-key header, uses the key to encrypt or decrypt, and does not store the raw key material after the operation. This gives the company direct control over the key material while S3 performs the cryptographic operations, which is the defining behavior of SSE-C.
D
x-amz-server-side-encryption: aws:kms
Why wrong: The x-amz-server-side-encryption: aws:kms header selects SSE-KMS, where a KMS key performs envelope encryption and manages the key hierarchy on AWS's side. It does not accept a customer-supplied key in the request, so it cannot be used for SSE-C scenarios. Using this header also introduces KMS API costs and requires appropriate IAM permissions and key policies, meaning the encryption key is owned and operated by AWS rather than exclusively by the company.

Question 17hardmultiple choice

A company has a compliance requirement to encrypt all data in Amazon S3 using keys that are managed by the company's internal security team. The keys must be stored in a hardware security module (HSM) that is FIPS 140-2 Level 3 certified. Which AWS service should be used?

Trap 1: AWS Secrets Manager

AWS Secrets Manager is a service for securely storing and rotating credentials, not a general-purpose encryption engine. When it encrypts secret values, it does so by calling AWS KMS with a customer-managed key, meaning it inherits KMS's shared HSM backing rather than providing its own dedicated, Level 3-certified HSM. It therefore cannot satisfy a requirement for dedicated hardware security modules. For that, you need CloudHSM.

Trap 2: AWS Key Management Service (KMS)

AWS KMS uses FIPS 140-2 Level 3 validated HSMs, but those HSMs are shared across multiple AWS customers in a multi-tenant region. Even with a customer-managed key (CMK), you do not get exclusive use of a physical HSM; AWS manages and operates the underlying hardware. The shared nature fails a compliance mandate that calls for dedicated HSMs. CloudHSM provides a single-tenant, dedicated HSM partition instead.

Trap 3: Amazon S3 default encryption with SSE-C

Amazon S3 default encryption with SSE-C lets you supply your own encryption keys for each S3 PUT/GET request, and S3 applies AES-256 using those keys. The customer-provided keys are not stored by AWS at all, and they never reside in an AWS HSM—S3 keeps them only in memory during the operation and then discards them. This requires you to manage key delivery and defeats the goal of using a dedicated, hardware-backed key vault. The compliance requirement asks for all data encrypted with keys stored in an HSM, which SSE-C does not do.

A
AWS Secrets Manager
Why wrong: AWS Secrets Manager is a service for securely storing and rotating credentials, not a general-purpose encryption engine. When it encrypts secret values, it does so by calling AWS KMS with a customer-managed key, meaning it inherits KMS's shared HSM backing rather than providing its own dedicated, Level 3-certified HSM. It therefore cannot satisfy a requirement for dedicated hardware security modules. For that, you need CloudHSM.
B
AWS Key Management Service (KMS)
Why wrong: AWS KMS uses FIPS 140-2 Level 3 validated HSMs, but those HSMs are shared across multiple AWS customers in a multi-tenant region. Even with a customer-managed key (CMK), you do not get exclusive use of a physical HSM; AWS manages and operates the underlying hardware. The shared nature fails a compliance mandate that calls for dedicated HSMs. CloudHSM provides a single-tenant, dedicated HSM partition instead.
C
Amazon S3 default encryption with SSE-C
Why wrong: Amazon S3 default encryption with SSE-C lets you supply your own encryption keys for each S3 PUT/GET request, and S3 applies AES-256 using those keys. The customer-provided keys are not stored by AWS at all, and they never reside in an AWS HSM—S3 keeps them only in memory during the operation and then discards them. This requires you to manage key delivery and defeats the goal of using a dedicated, hardware-backed key vault. The compliance requirement asks for all data encrypted with keys stored in an HSM, which SSE-C does not do.
D
AWS CloudHSM
AWS CloudHSM gives you dedicated, FIPS 140-2 Level 3 validated hardware security modules that run in your VPC and are exclusively yours. You can generate and store keys inside the HSM, and use it to perform cryptographic operations such as encryption and decryption, satisfying the requirement to encrypt all data using keys in a dedicated HSM. Unlike KMS's shared HSMs, there is no tenancy or key separation risk from other customers, and you retain direct control and visibility over the appliance. This makes CloudHSM the correct choice for this compliance scenario.

Question 18mediummultiple choice

A company is using AWS KMS to encrypt S3 objects. The security team wants to ensure that only a specific IAM role can decrypt objects in a particular S3 bucket. Which KMS key policy configuration should be used?

Trap 1: Use an S3 bucket policy that denies decrypt for all principals…

Incorrect. S3 bucket policies cannot deny or allow KMS actions. KMS decrypt permissions are controlled by KMS key policies and IAM policies. Additionally, the option mentions an IAM user, not a role.

Trap 2: Configure the IAM role with a policy that allows kms:Decrypt for…

Incorrect. While the IAM role can be granted kms:Decrypt via an IAM policy, the KMS key policy must also allow the role. Moreover, this approach does not restrict the decrypt to S3 only; additional conditions like kms:ViaService are needed.

Trap 3: Attach a resource-based policy to the S3 bucket that grants decrypt…

Incorrect. S3 bucket policies are resource-based policies for S3 actions, not for KMS actions. They cannot grant KMS decrypt permissions. Only KMS key policies (or IAM policies with key policy allow) can grant KMS decrypt.

A
Add a condition that allows decrypt only when kms:ViaService is s3.amazonaws.com and the caller role matches the specific role ARN.
Add a condition that allows decrypt only when kms:ViaService is s3.amazonaws.com and the caller role matches the specific role ARN using aws:PrincipalArn condition key.
B
Use an S3 bucket policy that denies decrypt for all principals except the specific IAM user.
Why wrong: Incorrect. S3 bucket policies cannot deny or allow KMS actions. KMS decrypt permissions are controlled by KMS key policies and IAM policies. Additionally, the option mentions an IAM user, not a role.
C
Configure the IAM role with a policy that allows kms:Decrypt for the specific KMS key.
Why wrong: Incorrect. While the IAM role can be granted kms:Decrypt via an IAM policy, the KMS key policy must also allow the role. Moreover, this approach does not restrict the decrypt to S3 only; additional conditions like kms:ViaService are needed.
D
Attach a resource-based policy to the S3 bucket that grants decrypt permission to the IAM role.
Why wrong: Incorrect. S3 bucket policies are resource-based policies for S3 actions, not for KMS actions. They cannot grant KMS decrypt permissions. Only KMS key policies (or IAM policies with key policy allow) can grant KMS decrypt.

Question 19hardmultiple choice

A financial services company must ensure that all data at rest in Amazon RDS for PostgreSQL is encrypted. The current database is unencrypted. What is the MOST operationally efficient way to enable encryption?

Trap 1: Export the database to S3 using pg_dump, then import into a new…

Although pg_dump can export the data and a newly created RDS instance can be encrypted at launch, this approach is manual and operationally heavy. You must manage downtime or write quiescence during the dump and import, and you lose the convenience of restoring an existing snapshot with the same instance settings, automated backup timeline, and native RDS metadata. AWS's snapshot-copy-restore path is simpler, less error-prone, and preserves the database engine configuration without requiring custom import tooling.

Trap 2: Create a read replica with encryption enabled and promote it to…

A read replica's encryption status is inherited from its source DB instance, so you cannot create an encrypted read replica from an unencrypted source. If the source is unencrypted, the replica is also unencrypted, and the AWS API/Console does not allow you to specify a KMS key for that replica. Therefore, promoting such a replica would still leave the data unencrypted at rest and does not satisfy the requirement.

Trap 3: Enable encryption directly on the existing RDS instance by…

Modifying an unencrypted Amazon RDS instance's settings to enable encryption is not possible. Encryption status is a fundamental configuration set during instance creation and cannot be altered afterwards for an unencrypted instance. This option is tempting because modifying DB instance settings is the standard procedure for changing many other parameters, such as instance class or storage. It would also be the correct method to enable encryption when creating a *new* instance, or to rotate the encryption key on an *already encrypted* instance.

A
Export the database to S3 using pg_dump, then import into a new encrypted RDS instance.
Why wrong: Although pg_dump can export the data and a newly created RDS instance can be encrypted at launch, this approach is manual and operationally heavy. You must manage downtime or write quiescence during the dump and import, and you lose the convenience of restoring an existing snapshot with the same instance settings, automated backup timeline, and native RDS metadata. AWS's snapshot-copy-restore path is simpler, less error-prone, and preserves the database engine configuration without requiring custom import tooling.
B
Create a read replica with encryption enabled and promote it to primary.
Why wrong: A read replica's encryption status is inherited from its source DB instance, so you cannot create an encrypted read replica from an unencrypted source. If the source is unencrypted, the replica is also unencrypted, and the AWS API/Console does not allow you to specify a KMS key for that replica. Therefore, promoting such a replica would still leave the data unencrypted at rest and does not satisfy the requirement.
C
Take a snapshot of the database, copy the snapshot with encryption enabled, and restore the encrypted snapshot to a new DB instance.
This is the officially supported AWS method for adding encryption at rest to an existing unencrypted RDS instance. You take a manual snapshot, copy that snapshot while specifying a KMS key (which encrypts the snapshot copy), and then restore the encrypted snapshot to a new DB instance. The restored instance is encrypted at the storage layer, and you can repoint your application to its new endpoint before decommissioning the original instance. After creation, encryption on that restored instance cannot be disabled.
D
Enable encryption directly on the existing RDS instance by modifying the DB instance settings.
Why wrong: Modifying an unencrypted Amazon RDS instance's settings to enable encryption is not possible. Encryption status is a fundamental configuration set during instance creation and cannot be altered afterwards for an unencrypted instance. This option is tempting because modifying DB instance settings is the standard procedure for changing many other parameters, such as instance class or storage. It would also be the correct method to enable encryption when creating a *new* instance, or to rotate the encryption key on an *already encrypted* instance.

Question 20easymultiple choice

A company needs to securely store database credentials for a legacy application running on Amazon EC2. The credentials are currently hardcoded in the application code. Which service should be used to rotate and retrieve secrets automatically?

Trap 1: AWS Systems Manager Parameter Store with a SecureString parameter.

AWS Systems Manager Parameter Store can store secrets as SecureString parameters encrypted with AWS KMS, but it does not natively support automatic rotation of database credentials. Because the requirement demonstrates a need for lifetime management and scheduled secret rotation, Parameter Store would require building custom Lambda-based automation and versioning logic to match Secrets Manager's built-in behavior.

Trap 2: AWS Key Management Service (KMS).

AWS Key Management Service (KMS) is a cryptographic key management service that creates and controls encryption keys, but it has no API for storing or retrieving arbitrary secrets such as database credentials. A secret like a username and password must be encrypted and persisted somewhere else, so KMS by itself cannot satisfy the requirement to securely store the credential.

Trap 3: AWS CloudHSM.

AWS CloudHSM provides dedicated hardware security modules in the cloud, allowing you to manage cryptographic keys in FIPS 140-2 validated hardware, but it does not store application credentials like database usernames or passwords. CloudHSM exposes low-level PKCS#11, JCE, or KMS APIs for key operations, not a secret storage and retrieval API, so it cannot serve as the database credential store in this architecture.

A
AWS Systems Manager Parameter Store with a SecureString parameter.
Why wrong: AWS Systems Manager Parameter Store can store secrets as SecureString parameters encrypted with AWS KMS, but it does not natively support automatic rotation of database credentials. Because the requirement demonstrates a need for lifetime management and scheduled secret rotation, Parameter Store would require building custom Lambda-based automation and versioning logic to match Secrets Manager's built-in behavior.
B
AWS Key Management Service (KMS).
Why wrong: AWS Key Management Service (KMS) is a cryptographic key management service that creates and controls encryption keys, but it has no API for storing or retrieving arbitrary secrets such as database credentials. A secret like a username and password must be encrypted and persisted somewhere else, so KMS by itself cannot satisfy the requirement to securely store the credential.
C
AWS Secrets Manager.
AWS Secrets Manager is purpose-built for this scenario, offering secure storage, fine-grained access policies, and automatic credential rotation via built-in integrations with services like Amazon RDS and Redshift. It also natively supports secret versioning and schedule-based rotation using Lambda, so database credentials can be refreshed without application downtime or manual intervention.
D
AWS CloudHSM.
Why wrong: AWS CloudHSM provides dedicated hardware security modules in the cloud, allowing you to manage cryptographic keys in FIPS 140-2 validated hardware, but it does not store application credentials like database usernames or passwords. CloudHSM exposes low-level PKCS#11, JCE, or KMS APIs for key operations, not a secret storage and retrieval API, so it cannot serve as the database credential store in this architecture.