GSEC Container Security 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.

• ✗

  Encrypt the Dockerfile using a secret key before building.

  Why it's wrong here

  Encrypting the Dockerfile does not protect secrets inside the resulting image layers. When the container builds, the secret must be provided in plaintext to the build environment. Furthermore, the final image manifest and layers will contain the decrypted version of the data, making it retrievable by any container runtime user.

• ✓

  Use orchestrator-native secret management to inject secrets at runtime.

  Why this is correct

  Runtime injection ensures that secrets reside only in the memory of the container and are not persisted in the image layers. This prevents secrets from being exposed through registry access or image analysis, allowing for easier rotation and centralized auditing of secret usage within the containerized application environment.

• ✗

  Delete the secrets in a subsequent RUN layer during the build.

  Why it's wrong here

  Deleting a file in a later Dockerfile layer does not remove the data from the underlying image history. The data persists in previous layers and can be easily recovered using image inspection tools. To remove data truly, one must use multi-stage builds where secrets are never present in the final image.

• ✗

  Set the file permissions on the secret to 600 after copying it.

  Why it's wrong here

  Setting file permissions inside the container only restricts access to the file for processes running within that container. It does not prevent an attacker or an administrator from extracting the secret from the container image itself, as the file content is still stored permanently in the image layer metadata.