School lab PCs run an agent that periodically fetches the latest approved baseline from a central store. Which automation model is in use?
Select an answer to reveal the explanation.
Short Explanation
Pull agents are like students checking the classroom board for today's assignment on a timer. School labs that fetch baselines from a central store are using pull. Push-only silence or decade-apart imaging vans are different animals.
Full Explanation
School lab PCs that run an agent periodically fetching the latest approved baseline from a central store are using a pull automation model. In pull, the endpoint initiates contact on a schedule or trigger, retrieves desired state, and applies it locally. That pattern suits large lab fleets where always-on agents continuously enforce images, lockdown, and software policy without requiring the server to know the exact moment each lab PC is powered on.
A push-only model where labs never initiate contact with the server fails the description: the stem's agents periodically fetch, which is pull initiation. Manual imaging vans that visit campuses once per decade fail as continuous automation—they are rare physical interventions, not periodic agent retrieval. Out-of-band SMS commands typed by students into BIOS fail on security, authority, and technical model; students are not config managers and SMS-to-BIOS is not approved baseline pull.
Exam caveat: pull agents still require a trustworthy central store and authentication; "pull" does not mean unauthenticated self-service. Distinguish initiation direction (agent fetches) from content authority (central approved baseline).
Operational check: watch agent logs for periodic retrieve-and-apply cycles, change a baseline in the central store and confirm labs converge on the next pull interval, and ensure no operational dependency on decade-spaced imaging vans for routine policy updates.