200-901

200-901 DevNet Associate Exam Details

Domain Weight Breakdown

About DevNet Associate

The Cisco Certified DevNet Associate certification validates your ability to develop and maintain applications built on Cisco platforms, use Cisco APIs and modern development tools, and apply software development best practices to automate infrastructure. This is an associate-level certification in the Cisco DevNet track, positioned alongside CCNA as a starting point for network programmability and automation careers.

Unlike traditional networking certifications, DevNet focuses on the intersection of software development and network infrastructure. Candidates should be comfortable with at least one programming language (Python is strongly recommended), understand REST API concepts, and have a basic grasp of networking fundamentals. After passing, candidates can pursue Cisco Certified DevNet Professional or DevNet Specialist certifications.

Tip: APIs (Domain 2) and Infrastructure & Automation (Domain 5) together account for 40% of the exam. Focus your study time on REST API consumption and configuration management tools for maximum impact.

REST API Fundamentals

REST (Representational State Transfer) is an architectural style for designing networked applications. RESTful APIs use standard HTTP methods to perform CRUD operations on resources identified by URIs. REST is stateless, meaning each request contains all the information needed to process it.

HTTP Status Codes

REST vs SOAP Comparison

Tip: The DevNet exam heavily focuses on REST APIs. SOAP appears only in comparison questions. Know that REST uses JSON by convention and is stateless, while SOAP uses XML envelopes with strict WSDL contracts.

API Authentication Methods

OAuth 2.0 Grant Types: Authorization Code (web apps with server backend), Implicit (deprecated, formerly for SPAs), Client Credentials (machine-to-machine, no user involved), Resource Owner Password (direct username/password exchange, discouraged).

API Documentation & Data Formats

Swagger / OpenAPI Specification: The industry standard for describing REST APIs. An OpenAPI document (YAML or JSON) defines endpoints, methods, parameters, request/response schemas, and authentication. Swagger UI renders interactive documentation from the spec. Cisco DevNet uses OpenAPI specs for many platform APIs.

Python requests Library for API Calls

The Python requests library is the standard tool for consuming REST APIs on the DevNet exam. Key concepts to know:

• requests.get(url, headers=headers) – Retrieve data from an API endpoint
• requests.post(url, json=payload, headers=headers) – Send JSON data to create a resource
• requests.put(url, json=payload) – Full replacement update of a resource
• requests.delete(url, headers=headers) – Remove a resource
• response.status_code – Integer HTTP status code (200, 404, etc.)
• response.json() – Parse response body as Python dictionary
• response.text – Raw response body as string
• response.raise_for_status() – Raise exception for 4xx/5xx responses
• verify=False – Disable SSL certificate verification (lab environments only)

Tip: Exam questions often show code snippets using the requests library. Know the difference between passing data with json= (auto-serializes dict and sets Content-Type) vs data= (sends raw string/form-encoded).

Cisco DNA Center

Cisco DNA Center (now Catalyst Center) is Cisco's centralized network controller and management platform for intent-based networking. It provides REST APIs for programmatic access to network automation, assurance, and policy management.

• Authentication: POST to /dna/system/api/v1/auth/token with Basic Auth to receive a bearer token
• Network Discovery: GET /dna/intent/api/v1/network-device returns all managed devices
• Path Trace: POST to /dna/intent/api/v1/flow-analysis to trace packet flow between hosts
• Command Runner: Execute CLI commands on devices remotely via API
• Template Programmer: Deploy configuration templates to devices at scale

Tip: DNA Center uses token-based authentication. You must first obtain a token via Basic Auth, then include it as X-Auth-Token in subsequent API requests.

Cisco Meraki Dashboard API

Meraki is Cisco's cloud-managed networking solution. The Meraki Dashboard API is a fully RESTful API accessed at https://api.meraki.com/api/v1/.

• Authentication: API key passed in the X-Cisco-Meraki-API-Key header
• Hierarchy: Organizations → Networks → Devices (understand this hierarchy for API paths)
• Rate Limiting: 5 calls per second per organization; API returns 429 if exceeded
• Webhooks: Meraki can send HTTP POST alerts for network events to your server
• Action Batches: Group multiple API calls into a single asynchronous batch operation

Cisco ACI (Application Centric Infrastructure)

ACI is Cisco's SDN solution for data centers, managed by the Application Policy Infrastructure Controller (APIC). ACI uses a policy-based model with a Management Information Tree (MIT) structure.

• Authentication: POST to /api/aaaLogin.json to get a session cookie/token
• Object Model: Tenant → VRF → Bridge Domain → Subnet → EPG (Endpoint Group)
• API Format: REST API supporting both JSON and XML at https://apic/api/
• Cobra SDK: Python SDK for ACI that maps the object model to Python classes

Cisco Webex APIs

Webex provides REST APIs for messaging, meetings, and devices. The API base URL is https://webexapis.com/v1/.

• Authentication: OAuth 2.0 with Bearer token in Authorization header
• Webhooks: Subscribe to events (new message, room membership changes) via callback URL
• Bots: Automated users that can post messages, respond to commands, and integrate with external services
• Adaptive Cards: Rich interactive card layouts sent as message attachments
• Resources: People, Rooms, Messages, Teams, Memberships, Webhooks

IOS-XE Programmability: RESTCONF & NETCONF

YANG Models: YANG is a data modeling language used by both RESTCONF and NETCONF to define the structure of configuration and operational data. Cisco IOS-XE supports native YANG models (Cisco-specific) and IETF/OpenConfig standard models. Use pyang to visualize YANG model tree structures.

Cisco UCS & Intersight

Cisco UCS Manager: Manages Cisco Unified Computing System (blade and rack servers). Provides an XML-based API for automating server provisioning, firmware management, and service profiles. The Python SDK (ucsmsdk) simplifies interaction.

Cisco Intersight: Cloud-based infrastructure management platform for UCS and HyperFlex. Provides REST APIs with API key + secret key authentication (HMAC-SHA256 signed requests). Intersight can manage on-premises infrastructure through a lightweight connector appliance called Device Connector.

Python Fundamentals for DevNet

Python is the primary programming language for the DevNet exam. You should be comfortable reading, understanding, and debugging Python code.

Git Version Control

Git is a distributed version control system essential for collaborative development. The exam tests understanding of core Git workflows and commands.

Branching Strategy: The main/master branch holds production code. Feature branches are created for new work, then merged back via pull requests. Know the difference between git merge (creates merge commit, preserves history) and git rebase (replays commits, creates linear history).

CI/CD Concepts

Continuous Integration (CI): Developers frequently merge code changes into a shared repository. Each merge triggers automated builds and tests to catch integration issues early. Tools: Jenkins, GitHub Actions, GitLab CI, Travis CI.

Continuous Delivery (CD): Code changes are automatically built, tested, and prepared for release to production. Deployment to production requires manual approval. Ensures code is always in a deployable state.

Continuous Deployment: Extends Continuous Delivery by automatically deploying every change that passes all pipeline stages directly to production with no manual intervention.

• Pipeline stages: Source → Build → Test (unit, integration, functional) → Deploy (staging) → Deploy (production)
• Artifacts: Build outputs (compiled code, Docker images) stored in registries for deployment
• Infrastructure as Code (IaC): Pipeline definitions stored alongside application code in version control

Unit Testing

Unit tests verify individual functions or methods in isolation. Python's built-in unittest module and the popular pytest framework are commonly used.

• Assertions: assertEqual, assertTrue, assertRaises, assertIn – verify expected outcomes
• Mocking: unittest.mock replaces external dependencies (API calls, databases) with controlled test doubles
• Test-Driven Development (TDD): Write tests first (they fail), then write code to make them pass, then refactor
• Code Coverage: Percentage of code executed by tests; aim for high coverage but focus on critical paths

OWASP Top Security Risks

Secret Management

Secrets (API keys, passwords, tokens, certificates) must never be hardcoded in source code or committed to version control.

• Environment Variables: Store secrets in OS environment variables, accessed via os.environ['KEY'] in Python
• Vault Solutions: HashiCorp Vault, AWS Secrets Manager, Azure Key Vault provide centralized, audited secret storage
• .gitignore: Always exclude .env files, credential files, and private keys from version control
• Rotation: Regularly rotate API keys and tokens; automate rotation where possible
• Least Privilege: Grant only the minimum permissions required for each API key or service account

Tip: If a question asks about securely storing API credentials in a Python application, the correct answer is environment variables or a secret management tool – never hardcoded strings or config files committed to Git.

Configuration Management Tools

Tip: Ansible is the most tested automation tool on DevNet. Know that it is agentless (uses SSH), uses YAML playbooks, and is idempotent. It does not require any software installed on managed devices.

Ansible Playbook Structure

An Ansible playbook is a YAML file containing one or more plays. Each play targets a group of hosts and defines a list of ordered tasks.

• Inventory: Defines managed hosts and groups (INI or YAML format), default file: /etc/ansible/hosts
• Playbook: YAML file with plays – each play has hosts, vars, tasks, and optional handlers
• Tasks: Individual actions using modules (e.g., ios_config, ios_command, uri, copy, template)
• Modules: Pre-built units of work – Cisco modules include ios_config, nxos_config, aci_*, meraki_*
• Roles: Reusable bundles of tasks, vars, templates, and handlers organized in a directory structure
• Variables: Defined in playbooks, inventory, group_vars, host_vars, or at runtime with -e flag
• Jinja2 Templates: Use {{ variable }} syntax for dynamic configuration files
• Handlers: Tasks triggered by notify; run only once at the end of a play (e.g., restart service)

Ansible vs Python Automation

Terraform & Infrastructure as Code

Terraform by HashiCorp is a declarative Infrastructure as Code (IaC) tool that provisions and manages infrastructure across multiple cloud providers and platforms.

• Language: HashiCorp Configuration Language (HCL) – declarative, defines desired end-state
• Providers: Plugins for AWS, Azure, GCP, Cisco ACI, Meraki, DNA Center, and 3000+ platforms
• State File: terraform.tfstate tracks current infrastructure state; used to calculate changes
• Workflow: terraform init → terraform plan (preview) → terraform apply (execute) → terraform destroy (teardown)
• Key Difference from Ansible: Terraform excels at provisioning infrastructure (creating/destroying resources), while Ansible excels at configuration management (configuring existing resources)

Docker Containers

Docker packages applications and dependencies into lightweight, portable containers that run consistently across environments.

• Dockerfile: Text file with instructions to build an image (FROM, RUN, COPY, CMD, EXPOSE, ENV)
• Image: Read-only template built from a Dockerfile; stored in registries (Docker Hub, private registries)
• Container: Running instance of an image; isolated process with its own filesystem, networking, and PID space
• docker build -t name . – Build an image from Dockerfile in current directory
• docker run -d -p 8080:80 name – Run container in detached mode, map port 8080 to container port 80
• docker-compose: Define multi-container applications in a YAML file; manage services, networks, and volumes together
• Containers vs VMs: Containers share the host OS kernel (lightweight, fast startup); VMs include a full guest OS (heavier, stronger isolation)

Network Automation with Python

Python libraries commonly used for network automation on the DevNet exam:

Model-Driven Programmability

Model-driven programmability uses structured data models (YANG) to define configuration and operational data, replacing unstructured CLI screen-scraping with predictable, machine-readable interfaces.

• YANG: Data modeling language (RFC 7950) that defines the structure, constraints, and semantics of network configuration and state data
• YANG Model Types: Native (vendor-specific, e.g., Cisco-IOS-XE-native), IETF (standards-based, e.g., ietf-interfaces), OpenConfig (vendor-neutral, multi-platform)
• YANG Constructs: container, list, leaf, leaf-list, grouping, augment, typedef
• Model-Driven Telemetry: Devices push operational data (CPU, interface stats, routing tables) to collectors in real-time, replacing periodic SNMP polling
• gRPC: High-performance RPC framework used for model-driven telemetry streaming; more efficient than SNMP for real-time monitoring

Tip: Model-driven programmability is a core DevNet concept. Remember the flow: YANG model defines structure → NETCONF/RESTCONF provides transport → Python (ncclient/requests) provides the client → device returns structured XML/JSON data.

RESTCONF vs NETCONF

Synchronous vs Asynchronous APIs

Webhooks vs Polling

Containers vs Virtual Machines

Cisco Platform API Quick Reference

Tip: Memorize which authentication method each Cisco platform uses – this is one of the most frequently tested topics. DNA Center = token via Basic Auth, Meraki = API key in header, Webex = OAuth 2.0, ACI = token via login POST.

Provisioning vs Configuration Management

In practice: Terraform and Ansible are often used together. Terraform provisions the infrastructure (servers, networks, load balancers), then Ansible configures the software and services running on that infrastructure. This separation of concerns is a common DevOps pattern tested on the exam.