At a rural broadband cooperative's NOC, an engineer edits a new SNMP community string into the configuration, but a colleague pings the router from home and confirms the old community string still works over an hour later. Which concept explains why the change hasn't taken effect yet?
Select an answer to reveal the explanation.
Short Explanation
Junos keeps two separate configs in play: the candidate you're editing, and the active one the router is actually running. Nothing takes effect until commit copies the candidate into place as the new active configuration.
Full Explanation
Junos separates the configuration being edited from the configuration the device actually enforces. Everything typed under configuration mode — set, delete, edit — modifies only the candidate configuration, a working copy held separately. The active configuration, the one the packet-forwarding engine and every running process actually obeys, is untouched until the engineer issues commit, at which point Junos validates the candidate and, if it passes, copies it over the active configuration and the change takes effect immediately. Until that commit happens, the candidate can sit edited for hours or days with zero operational impact, which is exactly what the colleague observed. A rescue configuration is a separate, manually saved fallback used for recovery, not the everyday candidate the engineer was editing, so that option describes the wrong object entirely. Junos reports obvious syntax errors at commit time rather than accepting and silently discarding a bad statement, so silent rejection doesn't fit either. SNMP configuration changes, like nearly all Junos configuration, apply on commit without a reboot. The operational check: run show configuration | compare to see the pending, uncommitted difference between candidate and active before committing.