Device-Level vs Controller-Level Management Advantage

Infrastructure and Automation
Answer Correct answer: B — Device-level management can touch every vendor-specific setting on each device, while a controller only exposes the subset its abstraction supports.

What is an advantage of device-level management as compared to controller-level management to automate the configuration of network devices?

  1. Device-level management has access to all devices from a single point on the network and controller-level management does not.
  2. Device-level management supports all subsets of the potential device settings and controller-level management does not. Correct Answer
  3. Device-level management supports REST API-enabled devices and controller-level management does not.
  4. Device-level management requires one controller per vendor and controller-level management does not.
device-level management controller-level management network automation cisco devnet automation

Community Votes

B
71%
D
29%

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

Community Insight

Tests the trade-off between granular per-device control and scalable abstraction — the trap is assuming a controller exposes more settings or REST support.

Device-level management can reach every vendor-specific setting on each device, whereas a controller abstracts the hardware and exposes only the subset it supports.

Learners pick the controller-flavoured options (single point of access, REST API support), but those describe controller-level management, not the advantage of device-level management.

Community Discussion (3 comments)

timhanley156 👍 1 Selected: B
Device-level management involves directly configuring individual devices (e.g., using CLI, NETCONF, or REST APIs). ✅ It gives full access to all features and configuration options of each specific device. Controller-level management abstracts the underlying hardware and provides a centralized way to manage multiple devices. ❌ While more scalable and simplified, it often limits access to only the features exposed through the controller's interface — not the full set of device-specific options.
Jebakavin 👍 4 Selected: B
B is correct. https://learningnetwork.cisco.com/s/question/0D56e0000Dp2PcFCQU/100-days-of-devnet-challenge
doiszeroum 👍 2 Selected: D
CHAT: The correct answer is:

Comments & Corrections

No comments 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.

Submitted for moderation before publishing. Keep it helpful and respectful.

Expert Analysis

Why the Answer Is Correct

Device-level management talks directly to each box — over CLI, NETCONF or the device's own REST API — so it can read and write the complete configuration surface, including vendor-specific and platform-specific settings. A controller works from an abstracted, vendor-neutral model and therefore only exposes the subset of settings that its model and drivers implement. The advantage that is uniquely true of device-level management is precisely that full access to every potential device setting.

Why the Other Options Are Wrong

Option A reverses the two approaches: reaching all devices from a single point is the controller's strength, not device-level management's. Option C is wrong twice over — controller platforms are built on REST APIs, and device-level automation is not limited to REST-enabled devices. Option D is simply inaccurate: device-level management needs no controller at all, and one controller per vendor is not an advantage.

Community Comment Notes

Commenters converge on this option. One learner frames it as direct configuration that gives "full access to all features and configuration options of each specific device" while controller-level management "abstracts the underlying hardware", and cites a Cisco Learning Network thread as the source. A second comment simply names the option letter and links the same discussion, which is the pattern here: the minority vote for the controller-centric option is not backed by any technical argument.

Official Reference

https://learningnetwork.cisco.com/s/question/0D56e0000Dp2PcFCQU/100-days-of-devnet-challenge

Exam Strategy

When a question contrasts device-level and controller-level management, separate the axes: granularity and vendor-specific settings favour direct device access, while scale and uniformity favour a controller.

Frequently Asked Questions

Why does a controller expose fewer settings?

A controller models devices in an abstracted, vendor-neutral way, so it can only present the settings its data model and drivers implement, not every native option.

Does device-level management support REST APIs?

Yes — many devices expose REST or NETCONF APIs directly. Option C is false because controller platforms are themselves REST-driven, not because devices lack APIs.

Related Analysis

Refer to the exhibit. A developer is using cURL to test conn

S-Grade

Refer to the exhibit. A Cisco Meraki network was recently in

A-Grade

Which tool is able to create a network design that simulates

A-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