Controller-Level vs Device-Level Infrastructure Management

200-901 By islever Editorial Last updated

Short answer

B Controller-level management exposes APIs that simplify the developer experience, whereas device-level management uses traditional protocols.

Question

What is a difference between device-level and controller-level infrastructure management?
  1. Device-level management uses NETCONF, whereas controller-level management does not support NETCONF to automate the infrastructure.
  2. Controller-level management uses APIs to simplify the developer experience, whereas device-level management uses traditional management protocols. Correct Answer
  3. Controller-level management is more widely supported because it is standards-based, whereas device-level management is proprietary to each vendor.
  4. Controller-level management exposes northbound, southbound, eastbound, and westbound APIs, easing integration with other technologies, whereas device-level management does not use a controller-based API.

Key Takeaways

The distinguishing factor is the abstraction an API provides: a controller exposes a programmatic northbound interface, whereas device-level management still means configuring each device directly with protocols such as CLI, SNMP or NETCONF.

Controller-level management abstracts the network behind a controller whose APIs hide device-by-device complexity, so developers express intent once instead of issuing traditional protocol commands to each device. Device-level management keeps working on individual devices with legacy protocols and offers no controller API.

Common mistake: Believing a controller exposes eastbound and westbound APIs in addition to northbound and southbound; controllers standardly provide northbound and southbound interfaces only, so the four-direction option overstates the model.

Expert Analysis

Why the Answer Is Correct

At the controller level a single controller manages many devices and exposes APIs that abstract away per-device detail, so developers work with a simplified, programmatic interface instead of the underlying boxes. Device-level management has no such controller API; it relies on traditional management protocols applied device by device. Option B states exactly this difference in developer experience versus management model.

Why the Other Options Are Wrong

Option A is wrong because NETCONF is a device-facing protocol that device-level management does use, so claiming controllers cannot use NETCONF mischaracterises the relationship. Option C inverts vendor reality: controller platforms such as Cisco DNA Center are vendor-specific, while many device-level protocols are standards-based, so being 'more widely supported because standards-based' is not a controller property. Option D overstates the interface set — controllers expose northbound and southbound APIs, not all four directions, so its description of controller-based APIs is inaccurate.

Community Comment Notes

The majority selected the API-versus-protocol answer, and one highly-liked comment reasoned that a controller is proprietary rather than standards-based and exposes only northbound and southbound APIs, dismissing the other choices on those grounds. A second commenter argued for the four-direction option, but that choice remains incorrect because it claims four API directions instead of two.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

Memorise the abstraction idea — controllers give programmatic APIs and hide device detail, while device-level management uses traditional protocols like CLI, SNMP and NETCONF directly. Eliminate options that mislabel controllers as standards-based or as exposing four API directions.

Frequently Asked Questions

Do controllers expose eastbound and westbound APIs?

Standard controller architectures expose northbound and southbound APIs; eastbound and westbound interfaces are not part of the usual controller model, so that description is inaccurate.

Why is controller-level management described as better for developers?

The controller's programmatic APIs abstract many devices behind one interface, so a developer expresses intent once instead of configuring each device with traditional protocols.

More 200-901 FAQ →

Community Votes

B
83%
D
17%

83% of anonymous learners picked answer B. Votes are pick records left by other test-takers — they are not the verified answer.

Discussion 3 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 3

  1. kymoni 👍 2 Answered B
    B is correct A is wrong - We don't use NETCONF for device-level management C is wrong - Controller is not standards-based, it is proprietary to each vendor (for example Cisco DNA Center) D is wrong - Controller exposes only Northbound and Southbound APIs
  2. kymoni 👍 1 Answered D
    D is the only one that makes sense. Opinions?
  3. RonAdams 👍 3 Answered B
    B, as per chatgpt.

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Benefits of Edge Computing Architecture

S-grade

Capability of Model-Driven Programmability

S-grade

AXL API Configures Phone Books and Contacts

S-grade

OAuth Authentication for an Administrator API

S-grade

Practice All 200-901 Questions

Access 105 questions with complete answers and detailed explanations.

View Full 200-901 Practice Test →

← Back to 200-901 Study Guide