The compost lab wants a Fluent Bit-style logging sidecar next to its grader container without adopting Kubernetes. What is the supporting-role pattern on Azure Container Instances?
Select an answer to reveal the explanation.
Short Explanation
Two containers, one group—that is the ACI sidecar pattern. You do not need Kubernetes homework just to sit a log shipper beside the grader.
Full Explanation
The Azure Container Instances supporting-role pattern is the multi-container group. Add the Fluent Bit-style logging sidecar to the same ACI container group as the compost lab’s grader so logs ship beside the main process without adopting Kubernetes. Both containers share lifecycle and local networking, which is exactly how ACI expresses a sidecar without Helm or node pools.
Requiring a Helm chart and AKS because “ACI cannot run more than one container” is false; multi-container groups are a first-class ACI feature for small companions. Running the sidecar only in ACR Tasks captures nothing useful at runtime—Tasks build and push images, they do not sit next to a live grader shipping logs. Replacing the sidecar with a second public IP on the grader only changes network exposure; it does not create a companion process that tails and forwards log streams.
Exam caveat: sidecars still consume the group’s CPU and memory budget and share restart behavior. Size the group for both containers and decide whether log-shipper failure should recycle the grader as well.
Operational check: deploy grader plus Fluent Bit in one group, generate known log lines from the grader, confirm the sidecar forwards them to the chosen destination, and verify that stopping the group stops both containers together.