The city’s prebuilt CD path already builds, pushes, and rolls container images into Kubernetes. How should a new Meraki webhook consumer integrate into that environment?
Select an answer to reveal the explanation.
Short Explanation
The prebuilt conveyor already moves sealed crates—images—into the cluster. Hand-carrying loose source onto each node is not “integrate into the CD.”
Full Explanation
Integrating a new Meraki webhook consumer into a prebuilt CD path that already builds, pushes, and rolls container images means producing a container image, pushing it to the registry the cluster already trusts, and rolling that tag through the existing path. The municipal platform’s conveyor already moves sealed images into Kubernetes; the new consumer must become one more image on that belt rather than a bespoke host install.
SSHing to each worker and pip installing into system Python on every node abandons the image-based contract and creates snowflake nodes that drift from the CD path. Copying source trees with scp and running under systemd only likewise bypasses build, push, and roll. Asking operators to install the language runtime on VMs before any container exists reintroduces host-managed runtimes the prebuilt CD was designed to eliminate.
Exam caveat: “integrate into a prebuilt CD environment” means fit the existing image→registry→roll path, not redesign delivery with ad-hoc SSH or a second toolchain. Operational check: build the Meraki webhook consumer image, push to the trusted registry, update the workload to the new tag, and confirm pods schedule without node-local pip or scp steps.