A legacy permitting module will be packaged in containers. Which security implication should the architect call out?

Packaging a legacy permitting module in containers can improve workload isolation and deployment consistency compared with an unmanaged shared host, but it introduces image trust and registry supply-chain risks that the architect must manage. Images are build artifacts: they must be scanned, preferably signed, drawn from trusted registries, and rebuilt when base layers or dependencies change. Registry compromise, unvetted base images, and secrets baked into layers become first-class concerns. Security+ container topics therefore pair isolation benefits with image/registry governance rather than treating containers as automatically finished security.

Claiming containerization eliminates patching and scanning because images never change is false—images evolve, vulnerabilities appear in base layers, and unscanned images silently ship known CVEs. Requiring that network policies be disabled so pods can freely reach every municipal subnet maximizes lateral movement and contradicts least privilege between workloads. Declaring registry security unnecessary if developers build on personal laptops ignores malware, dependency confusion, and uncontrolled toolchains that feed production clusters.

Exam caveat: container answers usually keep both sides—isolation potential plus image/registry risk—not "images never change" or "open all networks." Operationally, use approved registries, enforce image scanning in CI before promote, restrict pod network policies to needed peers, avoid privileged containers by default, and rotate any credentials that ever lived in legacy image layers.