A logistics scoring service must start the same way on a developer laptop, on a staging rack, and on the production floor. Rebuilding it by hand in each place has already produced mismatched libraries. What removes that mismatch?
Select an answer to reveal the explanation.
Short Explanation
The same packed lunch should open the same way in three different kitchens. You want containerization so the scoring service and its libraries start as one unit on the laptop, the staging rack, and the production floor. The trap is a scaling rule or a residency rule that never packages the service.
Full Explanation
Containerization packages the scoring service together with the libraries it depends on, and that package is the unit that starts the same way on a developer laptop, a staging rack, and the production floor. Starting that same unit is what removes the mismatched libraries left behind by hand rebuilds. A cloud scaling rule can add machines when a queue grows and remove them later, and it still says nothing about packaging the service, so each place can keep its own libraries. An on-premises residency rule constrains where customer records may sit and does not deliver the production libraries to the laptop. A training cluster spreads one large fit across machines so a job can exceed a single machine; launching this scoring service in three environments is a different problem. Exam caveat: the container is the portable unit for the service, and it does not by itself choose how many machines to run or which building may hold the data. Operational check: start the same container image on the laptop and on the staging rack, and confirm the library versions inside both match the image that the production floor starts.