A cooperative creates a new local user account for a technician on a POP router but forgets to assign a login class before committing. What is the practical consequence?
Select an answer to reveal the explanation.
Short Explanation
Junos doesn't quietly guess what a new account should be allowed to do — no class means the configuration is incomplete, plain and simple. It'll stop you at commit time rather than let an unscoped account slip through.
Full Explanation
The class statement is a mandatory element of a complete user account definition in Junos, not an optional refinement — an account definition missing a class statement is treated as an incomplete configuration, and the commit operation rejects it with an error rather than silently accepting a partial definition. There is no default class Junos substitutes on the administrator's behalf: it doesn't assume super-user, which would be a serious, silent privilege-escalation risk, and it doesn't fall back to unauthorized or operator either. The reason Junos enforces this explicitly is that access control decisions — what an account can see and do — should never be implicit or accidental, especially for a cooperative managing many technician accounts across many devices. This differs from other optional statements like a full name or SSH key configuration, which can genuinely be added later without blocking a commit. Operationally, the fix is simple: add a class statement referencing either a built-in class such as operator, read-only, or super-user, or a custom one the co-op has defined, then re-attempt the commit — and it's worth double-checking new account definitions specifically for this omission, since the failure only surfaces at commit time, not while typing the account block.