A library knowledge base needs a nightly corpus re-embed that should not run as a long-lived HTTP service. Which Container Apps capability fits?
Select an answer to reveal the explanation.
Short Explanation
Nightly re-embed is a janitor shift, not a 24/7 front desk—Container Apps jobs fire the batch, finish, and clock out instead of leaving an empty HTTP lobby lit all night.
Full Explanation
Azure Container Apps jobs are built for finite or scheduled work: a municipal library corpus re-embed can run on a nightly trigger, process the batch, exit, and release capacity instead of occupying a long-lived HTTP revision. Jobs fit ETL-style AI maintenance—re-embedding ordinance or catalog text—where success is completion of work, not answering continuous web traffic. That is the correct Container Apps capability when the stem rejects a permanent HTTP service.
Keeping a permanent always-on Container Apps revision listening on port 80 with no work most of the day fails by concept because it models a request-driven app, not a scheduled batch; idle HTTP capacity is the wrong abstraction and cost profile. Asking librarians to click a desktop macro that SSHes into random nodes fails because it is manual, brittle, and outside managed Container Apps scheduling. Hosting the re-embed as an anonymous public Static Web App with client-side embedding only fails because Static Web Apps are for static/client sites, not privileged corpus embedding pipelines that need secure access to models and knowledge stores.
Exam caveat: Distinguish Container Apps apps/revisions (long-running ingress workloads) from jobs (run-to-completion or scheduled). Jobs may be cron-triggered or event-triggered; the exam focus is choosing jobs for nightly finite work. Re-embedding still needs identity access to storage and the embedding model—jobs do not remove security requirements.
Operational check: Create a Container Apps job with a nightly schedule, grant it managed identity rights to the library corpus and embedding endpoint, run a manual job execution first, verify embeddings update, then confirm the schedule fires and replicas return to zero between runs without an always-on HTTP revision.