A seed-catalog API compiles with a heavy SDK image, then the team ships that entire SDK image to production and wonders why pulls are huge. What image-management approach shrinks the runtime artifact?
Select an answer to reveal the explanation.
Short Explanation
Think of the SDK image as a whole construction site. Production only needs the finished house, not the cranes. A multi-stage build compiles in one stage, then copies just the published bits into a slim final image.
Full Explanation
Multi-stage Dockerfiles separate compile-time tooling from the runtime image. The builder stage produces binaries or published output; a later slim stage copies only those artifacts. Shipping the SDK image unchanged inflates pull size. Moving to ACI or AKS does not fix an oversized artifact; the build recipe must change.