SY0-701 Security Architecture 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.

• ✓

  Scan images for known vulnerabilities before they are promoted to production.

  Why this is correct

  Image scanning leverages CVE databases to identify known vulnerabilities in the image's packages and libraries during the CI/CD pipeline. This proactive control ensures that only images passing defined security policies, such as a maximum allowed severity score, are promoted to production. It also enables early remediation at a stage where fixes are relatively inexpensive and before attackers can exploit the flaws.

• ✓

  Use trusted minimal base images and remove unnecessary packages.

  Why this is correct

  Using base images from official, trusted repositories ensures they receive timely security patches and are less likely to contain embedded malicious software. Removing unnecessary packages via minimal or distroless images reduces the attack surface and the risk of unpatched components, as fewer libraries mean fewer potential CVEs. This practice also makes vulnerability scanning and maintenance more efficient because the scope is smaller.

• ✗

  Run containers as root by default to simplify troubleshooting.

  Why it's wrong here

  Running containers as root is dangerous because the root user inside a container retains all Linux capabilities unless explicitly dropped, enabling a potential escape to the host via kernel vulnerabilities (e.g., CVE-2022-0185). Even if the container is compromised, an attacker gains root privileges and can read or tamper with files the container has access to, increasing the blast radius. Secure designs use a non-root user, drop all capabilities, and rely on seccomp and AppArmor to constrain the container. Troubleshooting convenience never justifies granting elevated privileges.

• ✗

  Mount the host operating system filesystem into every container.

  Why it's wrong here

  Mounting the host's filesystem into a container exposes sensitive directories like /etc, /var, or /root, allowing the container to modify or view host system files directly, thus bypassing filesystem and namespace isolation. This effectively collapses the security boundary between the container and its host, so any process in the container can disrupt the underlying infrastructure or leak confidential data. Even read-only mounts can leak information and should be avoided unless absolutely necessary, and then only through specific, carefully scoped mounts.

• ✗

  Deploy images using the latest tag without reviewing version history.

  Why it's wrong here

  Using the mutable 'latest' tag means that the same tag may point to different images over time, destroying reproducibility and auditability of deployments. Without pinning to a digest or an immutable version tag, you cannot verify the exact contents of the image, and validation like signing or vulnerability scanning may be applied to a different image than the one actually deployed. This makes rollbacks and incident response difficult because you cannot reconstruct what exactly was running. Secure practices require pinning images to unique digests or specific version tags that are also cryptographically signed.