Task 2.2: Implement encryption by using AWS services

• AAsk for a higher plaintext size limit for the Encrypt operation

  Incorrect

  Encrypt accepts at most 4,096 bytes of plaintext. It is meant for small data such as keys and passwords, not for files.

• BCall GenerateDataKey, encrypt locally, and keep the encrypted data key

  Correct

  This is envelope encryption: one call returns a plaintext data key for local encryption and a copy encrypted under the KMS key. The plaintext key is erased after use, and Decrypt recovers it later.

• CSplit each file into 4 KB chunks and call Encrypt once for every chunk

  Incorrect

  This needs thousands of KMS calls per file. Data keys exist so that large data is encrypted outside AWS KMS with a single key request.

• DCall GenerateDataKeyWithoutPlaintext and encrypt the file with the returned key

  Incorrect

  That operation returns only the encrypted copy of the data key, which cannot encrypt anything until it is decrypted with another call.

KMS keys encrypt small payloads; data keys from GenerateDataKey encrypt large data locally, with only the encrypted data key stored next to it.

• ATurn on S3 Versioning for the bucket so that every object version is kept

  Incorrect

  Versioning keeps every version of an object so that it can be recovered. It does not control transport or encryption.

• BDeny all S3 actions in the bucket policy when aws:SecureTransport is false

  Correct

  Denying requests where aws:SecureTransport is false allows only encrypted connections over HTTPS (TLS), as S3 security best practices recommend.

• CTurn on S3 Object Lock in compliance mode with a default retention period

  Incorrect

  Object Lock stores objects as write-once-read-many to prevent deletion or overwrites. It does not encrypt them.

• DHave the uploading code send its own encryption keys with SSE-C on every request

  Incorrect

  SSE-C uses keys that the caller supplies, not the company's KMS key, and S3 now turns SSE-C off by default for new general purpose buckets.

• ESet the bucket's default encryption to SSE-KMS with the customer managed key

  Correct

  Default encryption applies to new objects whose requests specify no encryption, and SSE-KMS lets the bucket use the chosen customer managed key.

Encryption in transit is enforced with the aws:SecureTransport condition; encryption at rest with a chosen key is set by default bucket encryption.

• AAllow kms:Decrypt on the customer managed key for the function's execution role

  Incorrect

  kms:Decrypt is what reading an SSE-KMS object needs. A PutObject request that encrypts with a KMS key needs a different permission.

• BTurn off S3 Block Public Access on the reports bucket

  Incorrect

  Block Public Access limits public access through policies and ACLs. The function is not a public caller, so it is not the cause.

• CSend the reports with SSE-C keys so that AWS KMS is not involved

  Incorrect

  SSE-C would use keys the function supplies instead of the required KMS key, and S3 turns SSE-C off by default for new general purpose buckets.

• DAllow kms:GenerateDataKey on the customer managed key for the execution role

  Correct

  To make a PutObject request that encrypts an object with a KMS key, the caller needs kms:GenerateDataKey permission on that key.

SSE-KMS adds KMS permissions to S3 calls: kms:GenerateDataKey to write and kms:Decrypt to read.

• ATurn on automatic key rotation for the customer managed key

  Correct

  Automatic rotation creates new key material on a schedule (every 365 days by default) under the same key. Decrypt picks the material that encrypted each ciphertext, so old data still decrypts.

• BCreate a new KMS key every year and delete the previous one

  Incorrect

  A new key has a new key ID, and once a KMS key is deleted, data encrypted under it can no longer be decrypted.

• CRun ReEncrypt over all stored ciphertext once a year with the same key

  Incorrect

  ReEncrypt decrypts and re-encrypts ciphertext inside AWS KMS. It does not create new key material, and it means re-encrypting all the old data.

• DDo nothing, because AWS rotates customer managed keys every year

  Incorrect

  AWS rotates AWS managed keys every year. For customer managed keys, automatic rotation is optional and must be turned on.

Rotation changes only the key material; the KMS key keeps its key ID and other properties, and AWS KMS uses the original material to decrypt older ciphertext.

• AIn eu-west-1, the Region where the API is deployed

  Incorrect

  That is where the API lives, but an edge-optimized custom domain name needs its certificate in a different, fixed Region.

• BAs a client certificate generated on the API's stage

  Incorrect

  An API Gateway-generated client certificate lets a backend verify that requests come from API Gateway. It does not serve HTTPS to clients.

• CIn us-east-1, the US East (N. Virginia) Region

  Correct

  For an edge-optimized custom domain name, the certificate must be requested or imported in us-east-1, as for other CloudFront-based endpoints.

• DIn whichever Region is closest to most of the clients

  Incorrect

  Edge-optimized endpoints are served from edge locations, but the certificate still has to be in us-east-1, whatever the clients' location.

An edge-optimized custom domain name needs its ACM certificate in us-east-1, wherever the API itself is deployed.

• AAdd the SSE-C headers with a key generated by the application

  Incorrect

  SSE-C makes the team manage and supply keys, which the requirement rules out.

• BEncrypt each file in the application before uploading it

  Incorrect

  Client-side encryption adds key management work that is not needed for encryption at rest in S3.

• CNothing, because new uploads are encrypted with SSE-S3 by default

  Correct

  Since January 5, 2023, Amazon S3 automatically encrypts all new object uploads with SSE-S3 at no additional cost.

• DSwitch the bucket's default encryption to SSE-KMS with a new customer managed key

  Incorrect

  SSE-KMS works, but it adds AWS KMS keys and request charges that the requirement does not ask for.

SSE-S3 is the base level of encryption for every bucket; choose SSE-KMS only when you need control over the keys.

• ADecrypt with key A in the application, then call Encrypt with key B

  Incorrect

  This returns the plaintext to the application between the two calls, which the requirement rules out.

• BThe ReEncrypt operation with key B as the destination key

  Correct

  ReEncrypt decrypts the ciphertext and encrypts it again entirely within AWS KMS under the destination key.

• CTurn on automatic key rotation for key A

  Incorrect

  Rotation creates new key material for key A; it does not move the ciphertext to key B.

• DCreate an alias for key B with key A's alias name

  Incorrect

  Aliases are friendly names; repointing one does not change which key protects existing ciphertext.

ReEncrypt changes the key that protects ciphertext without exposing the plaintext outside AWS KMS.

• AAdd a second HTTPS listener on the load balancer for port 8443

  Incorrect

  Listeners handle client-to-load-balancer traffic; the connection to the targets still uses the target group's protocol.

• BTurn on access logs for the load balancer

  Incorrect

  Access logs record requests; they do not encrypt traffic to targets.

• CRestrict the instances' security group so that it allows only the load balancer

  Incorrect

  Security groups filter traffic, but they do not encrypt it.

• DUse an HTTPS target group and serve TLS on the instances

  Correct

  The load balancer routes requests to targets with the target group's protocol, so an HTTPS target group encrypts that leg.

End-to-end encryption behind an ALB needs HTTPS listeners for clients and HTTPS target groups for the instances.

• AIAM policies take up to a day to apply to KMS keys

  Incorrect

  There is no such delay; the IAM policy has no effect because the key policy does not enable IAM policies.

• Bkms:Decrypt can only be granted through grants

  Incorrect

  Key policies and IAM policies can allow kms:Decrypt; grants are one more option.

• CThe key policy does not let the account use IAM policies for the key

  Correct

  Without the statement that gives the account access, IAM policies that allow access to the key are ineffective.

• DThe role also needs kms:GenerateDataKey permission before any Decrypt call can succeed

  Incorrect

  Decrypt does not depend on GenerateDataKey; the missing piece is in the key policy.

KMS key policies do not automatically trust the account; IAM policies only work when the key policy enables them.

• AEncrypt every record directly with the AWS KMS Encrypt operation instead

  Incorrect

  This still makes a KMS request for every record, so the request volume does not fall.

• BUse one hardcoded data key in the code for all records

  Incorrect

  A key in code is exposed to anyone who can read the code and never changes, which defeats envelope encryption.

• CTurn on automatic rotation for the KMS key

  Incorrect

  Rotation changes key material over time; it does not reduce the number of KMS requests.

• DTurn on data key caching in the AWS Encryption SDK with limits

  Correct

  Data key caching reuses data keys from a cache instead of generating a new one each time; it is optional and should be used with care.

Data key caching trades some key reuse for fewer KMS calls; set limits that match the team's security requirements.