A rural ISP is bringing up a new subscriber aggregation switch, and an engineer notes that once an interface is configured with an IP address and enabled, a specific Junos daemon is responsible for applying that configuration to the actual interface and bringing it into an operational up state. Which daemon performs this role?

The device control process, dcd, is the Junos daemon responsible for taking committed interface configuration - IP addressing, encapsulation, and enabling or disabling the interface - and applying it to bring the interface into its operational state. This is a distinct responsibility from configuration acceptance itself, which the management process handles, and from route computation, which the routing protocol process handles once an interface is actually up and usable. The distractors misattribute the function: the routing protocol process depends on interfaces being operational to form adjacencies over them, but it does not itself bring interfaces up; the chassis process is concerned with physical component health such as power and cooling, not logical interface state; and the management process validates and commits the configuration syntax but hands off the actual application of interface-specific settings to dcd. This daemon separation is useful for troubleshooting: if a newly committed interface configuration was accepted without error but the interface still will not come up, the issue likely sits with device control process behavior or the physical layer beneath it, rather than with configuration syntax. A practical operational check is confirming both the administrative and physical layer states of an interface after any configuration change, since dcd's job spans both.