SAP-C02 Practice Question: Accelerate Workload Migration and Modernization

Answer analysis

Option-by-option breakdown

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

• ✗

  Move the uploaded documents into the container image and write new uploads to the pod's ephemeral writable layer

  Why it's wrong here

  Storing documents in the image makes them immutable and bloats the image, and writing to the pod's ephemeral layer loses data when the pod is replaced. Neither behavior matches the existing NFS-backed storage semantics. This would also prevent horizontal scaling because each replica would have its own isolated copy of the data.

• ✗

  Bake the environment-specific property files into the container image during the CI build for each environment

  Why it's wrong here

  Baking environment-specific files into the image produces a distinct artifact per environment, which directly violates the requirement that the image must not be rebuilt per environment. It also makes promotion between environments harder to audit because the tested artifact is not the artifact that runs in production. This is an anti-pattern for container portability.

• ✓

  Store the environment-specific configuration in AWS Systems Manager Parameter Store or AWS Secrets Manager and inject the values into the pods as environment variables or mounted files at runtime

  Why this is correct

  Externalizing configuration into Parameter Store or Secrets Manager removes environment-specific values from the image, so the same image runs in every environment. Values can be injected as environment variables or mounted as files using the AWS Secrets and Configuration Provider for the Secrets Store CSI driver. This satisfies the requirement that the image must not be rebuilt per environment.

• ✗

  Replace the NFS share with an Amazon EBS volume attached to each node and expose it to the pods with a hostPath volume

  Why it's wrong here

  Amazon EBS volumes are attached to a single Availability Zone and generally to a single node, so a hostPath volume would tie pods to a specific node and break scheduling and portability. It also cannot be shared concurrently by pods on different nodes the way NFS can. This approach would not survive node replacement and does not meet the shared-storage requirement.

• ✓

  Replace the locally mounted NFS share with Amazon EFS and mount it into the pods using the Amazon EFS CSI driver with access points

  Why this is correct

  Amazon EFS provides shared, POSIX-compliant storage that multiple pods and nodes can mount concurrently, matching the semantics of the NFS share the application already uses. The Amazon EFS CSI driver supports static and dynamic provisioning, and EFS access points give each application a scoped directory with enforced POSIX identity. This makes the storage layer portable across clusters without changing application code.

Go deeper

Related to this question