SCS-C02 Data Protection Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Configure a KMS key policy that allows the EFS service to use the key.

  Why this is correct

  The KMS key policy acts as the resource-based authorization for the key and must explicitly grant the Amazon EFS service principal (elasticfilesystem.amazonaws.com) the kms:GenerateDataKeyWithoutPlaintext, kms:Decrypt, and kms:DescribeKey permissions. Without these grants in the key policy, EFS cannot create or use data keys to encrypt or decrypt the file system, even if the IAM principal has full EFS permissions. This is a mandatory, non-optional part of enabling EFS encryption at rest — the key policy is the authoritative control over which AWS services may use the CMK. Therefore, configuring the key policy correctly is a required action, not merely a best practice.

• ✓

  Enable encryption at rest using a customer-managed KMS key when creating the EFS file system.

  Why this is correct

  When you create an Amazon EFS file system, the console or API lets you choose 'Encrypt EFS' and select a customer-managed KMS key. This setting causes EFS to use that key to encrypt all file data and metadata at rest, with each file system using its own unique data encryption key that is wrapped by the chosen KMS key. Using a customer-managed key is preferred over the AWS-managed aws/elasticfilesystem key because it gives you control over key rotation, access auditing, and revocation. Enabling this at creation time is essential because EFS does not support enabling encryption at rest later on an existing file system — you must create the file system with encryption enabled.

• ✗

  Enable default encryption on the EFS file system using SSE-S3.

  Why it's wrong here

  SSE-S3 is a server-side encryption option specific to Amazon S3, where S3 manages encryption keys using AES-256; EFS has no integration with S3's encryption infrastructure. EFS encryption at rest is implemented through AWS KMS, not through S3-managed keys, and the service will reject any attempt to specify an SSE-S3 configuration. Selecting "default encryption" on an EFS file system is conceptually valid only if it refers to the KMS-based default (aws/elasticfilesystem), but the mention of SSE-S3 makes this option categorically incorrect. Misunderstanding this can lead engineers to expect EFS to honor S3-style encryption settings, which the service simply does not use.

• ✗

  Use an IAM policy to restrict which users can create encrypted file systems.

  Why it's wrong here

  An IAM policy that restricts which users can create encrypted file systems is a useful administrative guardrail, but it does not control which KMS keys are used or how the key itself is protected. The IAM policy only governs the caller's permission to call CreateFileSystem with certain conditions; it cannot grant the EFS service the necessary kms:Decrypt and kms:GenerateDataKey permissions to actually use the key. Those service-level permissions must be granted in the KMS key policy, which is the only resource that can authorize the EFS service principal. Moreover, a restrictive IAM policy does nothing to prevent an authorized user from selecting a key that lacks proper EFS grants — that failure would occur at runtime when EFS attempts to use the key, making the security control ineffective for the actual encryption operation.

• ✓

  Enable encryption of data in transit using the mount helper's tls option on the client.

  Why this is correct

  For encryption in transit, EFS clients mount the file system using the EFS mount helper with the 'tls' option, which establishes a TLS 1.2+ session between the client and the EFS mount target. This protects data as it traverses the network, preventing eavesdropping or tampering during NFSv4.1 communication. The mount helper must be invoked with '-o tls' (and optionally 'iam' for EFS IAM authorization) to enable this protection, and the EFS security group must allow outbound/inbound traffic on port 2049 with TLS. Unlike encryption at rest, encryption in transit is enabled at the client mount level, not at the file system level, so this is a separate and complementary layer of data protection.

Go deeper

Related to this question