An engineer defines a group named pop-common under the groups hierarchy with shared NTP and syslog settings, and commits the change. On the router itself, though, neither service reflects any of the new settings. What is the most likely explanation?
Select an answer to reveal the explanation.
Short Explanation
Writing a group is like drafting a template — it just sits there until you actually tell the router to use it. Without an apply-groups statement pointing at that template, nothing changes.
Full Explanation
Defining a configuration group under the groups hierarchy only creates a named, reusable template of configuration statements; it has no effect on the router's actual, active behavior until a separate apply-groups statement references that group name at some level of the configuration hierarchy. Skipping that reference is a common and easy mistake, and it exactly explains why the committed group's NTP and syslog lines never showed up in the running configuration. Groups are never activated automatically simply by being defined and committed; automatic activation would make it impossible to stage a group's contents before deciding where to apply them, which is one of the feature's intended uses. NTP and syslog are ordinary system services with no special global-inheritance behavior for groups; every group requires an explicit apply-groups reference regardless of which service it configures. A missing rescue configuration has no bearing on whether a commit succeeds or on group activation; the two features are unrelated. The operational check is show configuration | display inheritance, or simply confirming an apply-groups line exists somewhere in the configuration that names pop-common — its absence is the smoking gun.