A regional cooperative offers wholesale broadband service to several smaller downstream providers over the same core routers, and wants each downstream provider's routes kept completely separate from the co-op's own internal backbone routes on the same device. Which routing concept most directly supports this kind of separation?
Select an answer to reveal the explanation.
Short Explanation
When you need to keep different customers' routes from ever mixing on shared hardware, a routing instance is the wall you build between them. Each downstream provider gets its own logically separate table, so the co-op's backbone routes stay untouched.
Full Explanation
Assigning each downstream provider's routes to a separate routing instance gives the co-op exactly the isolation described: distinct routing tables on the same physical router, so one provider's routes and the co-op's own backbone routes don't mix by default. This is the standard introductory use case for routing instances — segregating traffic domains that share hardware but shouldn't share reachability. Raising the preference of the backbone's OSPF routes only changes which route wins when multiple routes to the same destination compete within a single table; it doesn't create any separation between different customers' route sets at all. Discard next-hops silently drop matched traffic, which would break connectivity for downstream routes rather than isolate them from the backbone. Making reject the default next-hop action isn't a real, generally applicable Junos default-behavior setting, and even conceptually it would mean actively refusing traffic rather than logically separating routing tables. The scope caveat for JN0-106 is that recognizing routing instances as the right tool for this scenario is what's tested, not the detailed configuration steps for building one. A conceptual check is verifying that a route visible in one provider's routing instance is not visible in another's, confirming the separation is actually in effect.