After a static route is added to a router's configuration at a rural ISP's aggregation site and the configuration is committed, the route needs to actually be used to forward live subscriber traffic. Which sequence correctly describes how that route becomes usable for forwarding?

When a static route is committed, the Routing Engine adds it to the routing table alongside any other routes known for that destination, then runs route selection - based on preference and other tie-breaking criteria - to determine the single best route. Only that selected, active route gets installed into the forwarding table, which the Routing Engine then downloads to the Packet Forwarding Engine's hardware so it can actually be used to forward live traffic. This sequence is what connects a configuration change to real forwarding behavior, and it is also why a committed route sometimes does not appear in the forwarding table - a competing route with better preference may have been selected instead. The distractors skip real steps in this process: nothing in Junos forwards traffic based on configuration text before a commit and route selection occur; the management process handles configuration acceptance, not forwarding-table installation, which is a Routing Engine and forwarding-plane function; and the chassis process is concerned with hardware component health, not with evaluating whether a route can be installed. A useful operational check after adding any static route is confirming it was actually selected as the best route and appears in the forwarding table, rather than assuming a successful commit alone guarantees it is being used.