Cisco
Expert
350-901
Developing Applications Using Cisco Core Platforms and APIs
The Cisco 350-901 DEVCOR (Developing Applications Using Cisco Core Platforms and APIs) exam is the core requirement for the DevNet Professional certification. This expert-level exam validates the knowledge and skills required to develop applications using Cisco platforms and APIs including network infrastructure, collaboration, security, data center, and cloud services.
The exam covers five comprehensive domains: Software Development and Design (20%), Using APIs (20%), Cisco Platforms and Development (30%), Application Deployment and Security (20%), and Infrastructure and Automation (10%). Candidates must demonstrate proficiency in software development best practices, API interaction, Cisco platform SDKs, containerization, and security implementation for network applications.
Key skills tested include designing RESTful APIs following best practices, implementing authentication and authorization using OAuth, JWT, and API keys, consuming and creating APIs using Python requests library, developing applications using Cisco SDKs for Meraki, Webex, DNA Center, ACI, and Firepower, implementing version control with Git and CI/CD pipelines, containerizing applications using Docker and deploying to Kubernetes, implementing application security with input validation and secrets management, automating infrastructure using Ansible and Terraform, and implementing event-driven automation with webhooks and streaming data. This certification is essential for software developers and network engineers building automation and integration solutions on Cisco platforms.
Updated 2024
Development
90
Questions
6
Tests Pratiques
83%
Score de Réussite
40
Vues
0
Tentatives Totales
0%
Score Moyen
0%
Taux de Réussite
0
Discussions
350-901 Practice Exam 1
Comprehensive DEVCOR practice exam covering software development and design, using APIs, Cisco platforms and development, application deployment and security, and infrastructure and automation across 65 professional-level questions.
65 Q
120 minutes
70%
350-901 Practice Exam 2
Comprehensive DEVCOR practice exam covering software development and design, using APIs, Cisco platforms and development, application deployment and security, and infrastructure and automation across 65 professional-level questions.
65 Q
120 minutes
70%
350-901 Practice Exam 3
Comprehensive DEVCOR practice exam covering software development and design, using APIs, Cisco platforms and development, application deployment and security, and infrastructure and automation across 65 professional-level questions.
65 Q
120 minutes
70%
350-901 Practice Exam 4
Comprehensive DEVCOR practice exam covering software development and design, using APIs, Cisco platforms and development, application deployment and security, and infrastructure and automation across 65 professional-level questions.
65 Q
120 minutes
70%
350-901 Practice Exam 5
Comprehensive DEVCOR practice exam covering software development and design, using APIs, Cisco platforms and development, application deployment and security, and infrastructure and automation across 65 professional-level questions.
65 Q
120 minutes
70%
350-901 Practice Exam 6
Comprehensive DEVCOR practice exam covering software development and design, using APIs, Cisco platforms and development, application deployment and security, and infrastructure and automation across 65 professional-level questions.
65 Q
120 minutes
70%
Débloquer Tout le Contenu pour 350-901
6 Test(s) Pratique(s) + Flash Cards — accès de 3 mois
€39.99
€26.99
Économisez 30%
ou inclus avec l'abonnement Mensuel / Pack de Contenu
Aperçu (10 / 150)
What are the four pillars of object-oriented programming?
Encapsulation, abstraction, inheritance, and polymorphism. These principles promote modular, reusable, and maintainable code design.
What is the Singleton design pattern?
A creational pattern that restricts a class to one instance and provides a global access point. It is useful for shared resources like database connections.
What does the Observer design pattern do?
It defines a one-to-many dependency so when one object changes state, all dependents are notified automatically. Used in event-driven systems.
What is the Factory design pattern?
A creational pattern that defines an interface for creating objects but lets subclasses decide which class to instantiate, decoupling creation from usage.
How does the Model-View-Controller pattern work?
MVC separates an application into Model (data/logic), View (UI presentation), and Controller (input handling), improving modularity and testability.
What is the purpose of the Decorator pattern?
It dynamically adds behavior to an object without modifying its class. Decorators wrap objects, extending functionality while preserving the original interface.
What does sequence diagrams show in UML?
The time-ordered interaction between objects via messages. Lifelines represent objects and arrows represent method calls or responses exchanged over time.
What is the difference between waterfall and agile?
Waterfall follows sequential phases with no backtracking. Agile uses iterative sprints, continuous feedback, and adapts to changing requirements.
What is test-driven development?
TDD writes failing unit tests first, then implements code to pass them, then refactors. This cycle ensures code correctness from the start.
What does the DRY principle mean?
Don't Repeat Yourself. Avoid duplicating logic or data across a codebase. Instead, abstract common functionality into reusable functions or modules.
Flash Cards
cartes couvrant les concepts clés de 150 350-901
ou inclus avec l'abonnement Mensuel / Pack de Contenu
140 cartes supplémentaires disponibles après déblocage
Langues Disponibles
English
Sujets de l'Examen
1
18 Q
Software Development and Design
Apply software development methodologies, design patterns, version control, and testing strategies.
2
18 Q
Using APIs
Consume and create REST APIs, implement authentication/authorization, handle API responses and errors.
3
27 Q
Cisco Platforms and Development
Develop applications using Cisco platform APIs and SDKs for Meraki, Webex, DNA Center, ACI, and security.
4
18 Q
Application Deployment and Security
Deploy applications using containers and Kubernetes, implement security controls and secrets management.
5
9 Q
Infrastructure and Automation
Automate infrastructure using Ansible, Terraform, and Python. Implement event-driven automation.
350-901 Cheat Sheet
Guide de référence rapide - 6 sections
Cisco 350-901 DEVCOR - Developing Applications Using Cisco Core Platforms and APIs
The Cisco 350-901 DEVCOR exam is the core exam required for the Cisco Certified DevNet Professional certification. It validates your ability to develop and maintain applications built on Cisco platforms using modern software development practices, APIs, and automation frameworks. This professional-level certification targets network engineers transitioning into software-defined infrastructure roles, as well as software developers working with Cisco collaboration, security, data center, and enterprise networking products. Candidates are expected to demonstrate proficiency in software development and design patterns, working with REST APIs and other programmatic interfaces, leveraging Cisco platform APIs including DNA Center, Meraki, ACI, and collaboration platforms, deploying and securing applications using containers and CI/CD pipelines, and automating network infrastructure using YANG models with RESTCONF and NETCONF protocols. The DEVCOR exam is one of the most comprehensive Cisco developer certifications, bridging traditional networking knowledge with modern DevOps and software engineering principles. Success requires hands-on experience with Python programming, version control with Git, API consumption, data parsing in JSON and XML formats, and a solid understanding of Cisco's programmable infrastructure ecosystem. Passing DEVCOR along with one concentration exam earns the Cisco Certified DevNet Professional credential, which is highly valued as organizations adopt infrastructure-as-code and network automation at scale.
Exam Details
| Exam Code | 350-901 DEVCOR |
| Duration | 120 minutes |
| Number of Questions | 55-65 questions |
| Passing Score | Cisco does not publish passing scores (approximately 750-850 / 1000) |
| Cost | $400 USD |
| Validity | 3 years (recertify by passing any professional core exam, or earning 80 CE credits) |
| Question Types | Multiple choice, multiple select, drag-and-drop, fill-in-the-blank |
| Certification Level | Professional (core exam for DevNet Professional) |
Domain Weights
| Domain | Weight |
|---|---|
| Software Development and Design | 20% |
| Using APIs | 20% |
| Cisco Platforms and Development | 20% |
| Application Deployment and Security | 20% |
| Infrastructure and Automation | 20% |
Study Tips
- All five domains carry equal weight at 20%, so you must be well-rounded; do not skip any domain as a weak area in any one of them can prevent you from passing
- Hands-on Python coding is essential; practice writing scripts that consume REST APIs, parse JSON/XML responses, handle errors with try/except blocks, and use the requests library extensively
- Set up Cisco DevNet Sandbox environments (free) to practice with DNA Center, Meraki Dashboard, ACI APIC, and Webex APIs in real lab environments without needing your own hardware
- Master Git operations beyond basic commit and push; understand branching strategies, merge vs rebase, resolving conflicts, pull requests, and Git workflows like Gitflow and trunk-based development
- Docker and CI/CD pipelines are heavily tested; practice building Dockerfiles, running multi-container applications with docker-compose, and configuring basic CI/CD pipelines with tools like Jenkins or GitHub Actions
- YANG data models with RESTCONF and NETCONF are critical topics; use pyang to explore YANG models, and practice sending RESTCONF requests with curl or Python and NETCONF operations with ncclient
- Understand design patterns (Observer, Singleton, Factory, MVC) conceptually and know when to apply each; the exam tests pattern recognition in scenario-based questions rather than code implementation details
Software Design Patterns
| Pattern | Description |
|---|---|
| Observer | Defines a one-to-many dependency where multiple observer objects subscribe to a subject and are notified automatically when the subject's state changes; used in event-driven systems, webhooks, and publish-subscribe messaging; in network automation, used for event-based monitoring where devices notify a controller of state changes; Python implementation uses callback functions or the built-in Observer pattern from libraries; key components are Subject (maintains list of observers), Observer (interface with update method), and ConcreteObserver (implements the response to notifications) |
| Singleton | Ensures a class has only one instance and provides a global access point to it; commonly used for database connection pools, logging services, configuration managers, and API client instances; in Python, implemented using a class variable to track the single instance, __new__ method override, or module-level variables (modules are naturally singletons in Python); be cautious with thread safety in multi-threaded applications; anti-pattern concerns include tight coupling and difficulty in unit testing |
| Factory | Creates objects without specifying the exact class to instantiate; the factory method defines an interface for object creation and lets subclasses decide which class to instantiate; useful when the type of object needed depends on runtime conditions; in Cisco development, a factory can create different API client objects based on the platform type (DNA Center, Meraki, ACI); Abstract Factory extends this pattern to create families of related objects; reduces coupling between client code and concrete implementations |
| Model-View-Controller (MVC) | Separates application into three components: Model (data and business logic, interacts with database or API), View (presentation layer, renders UI), Controller (handles user input, coordinates Model and View); promotes separation of concerns and parallel development; commonly used in web frameworks like Flask and Django; in API development, the Model represents network device data, the View serializes responses (JSON/XML), and the Controller handles HTTP request routing and business logic orchestration |
| Decorator | Dynamically adds behavior to objects without modifying their class; wraps an object with additional functionality while maintaining the same interface; Python natively supports decorators using the @decorator syntax for functions and classes; common uses include logging, authentication checks, rate limiting, caching, and input validation; in API development, decorators like @app.route() in Flask or @login_required add routing and authentication behavior to endpoint functions |
Exam Tip: The DEVCOR exam frequently presents scenarios and asks you to identify which design pattern best fits. Focus on understanding when to apply each pattern rather than memorizing implementation code. Observer is for event notification, Singleton for shared resources, Factory for flexible object creation, and MVC for web application architecture.
Python Programming Concepts
| Concept | Description |
|---|---|
| Object-Oriented Programming | Classes define blueprints with attributes and methods; inheritance enables code reuse (class Child(Parent)); polymorphism allows different classes to implement the same method interface; encapsulation hides internal state using name mangling (_private, __very_private); abstract base classes (ABC) define interfaces that subclasses must implement; magic methods (__init__, __str__, __repr__, __eq__) customize object behavior; composition is generally preferred over inheritance for flexible object relationships |
| Error Handling | try/except/else/finally blocks handle exceptions gracefully; catch specific exceptions (ConnectionError, TimeoutError, json.JSONDecodeError) rather than bare except; raise custom exceptions for application-specific errors; use finally for cleanup operations like closing connections; requests library raises HTTPError (via response.raise_for_status()), ConnectionError, Timeout; always log exceptions with traceback for debugging; context managers (with statement) provide automatic resource cleanup |
| Data Parsing (JSON/XML/YAML) | JSON: json.loads() parses string to dict, json.dumps() serializes dict to string, response.json() in requests library; XML: xml.etree.ElementTree for parsing, use find(), findall(), attrib for navigation, handle namespaces with namespace dict; YAML: PyYAML library yaml.safe_load() for parsing, yaml.dump() for serialization; all three formats appear in Cisco API responses and configuration management; understand when each format is used (JSON for REST APIs, XML for NETCONF, YAML for Ansible and configuration files) |
| Unit Testing | unittest module provides TestCase base class with setUp/tearDown, assertEqual, assertTrue, assertRaises; pytest is the preferred framework with simpler syntax, fixtures, and parametrize decorators; mock objects (unittest.mock) simulate API responses for isolated testing without hitting real endpoints; patch decorator replaces objects during tests; test coverage measures percentage of code exercised by tests; test-driven development (TDD) writes tests before implementation code; integration tests verify components work together end-to-end |
Version Control with Git
| Concept | Description |
|---|---|
| Core Operations | git init (create repo), git clone (copy remote), git add (stage changes), git commit (save snapshot), git push (upload to remote), git pull (fetch and merge), git fetch (download without merge); staging area (index) sits between working directory and repository; HEAD points to current commit; .gitignore excludes files from tracking (virtual environments, __pycache__, .env files, IDE configs) |
| Branching Strategies | Feature branching: create a branch per feature, merge via pull request after code review; Gitflow: main (production), develop (integration), feature/*, release/*, hotfix/* branches with defined promotion paths; trunk-based development: short-lived branches merged frequently to main, relies on feature flags for incomplete features; merge creates a merge commit preserving branch history; rebase replays commits on top of another branch for a linear history; squash combines multiple commits into one clean commit |
| Conflict Resolution | Conflicts occur when the same lines are modified in different branches; Git marks conflicts with <<<<<<<, =======, >>>>>>> markers; resolve by editing the file to keep the desired changes, then git add and git commit; git merge --abort cancels a conflicting merge; git stash saves uncommitted changes temporarily; cherry-pick applies a specific commit from another branch; git log --graph visualizes branch history and merge points |
Exam Tip: Know the difference between git merge and git rebase. Merge preserves the complete branch history with a merge commit, while rebase rewrites commit history to create a linear sequence. Never rebase commits that have already been pushed to a shared remote branch. Understand how to read git log output and identify the relationship between branches.
Software Development Methodologies
- Agile / Scrum: Iterative development with sprints (1-4 weeks); roles include Product Owner (prioritizes backlog), Scrum Master (facilitates process), Development Team (delivers increments); ceremonies include Sprint Planning, Daily Standup, Sprint Review, Sprint Retrospective; user stories define requirements from the user perspective with acceptance criteria; burndown charts track remaining work within a sprint
- Lean Development: Eliminate waste, build quality in, create knowledge, defer commitment, deliver fast, respect people, optimize the whole; minimize work in progress (WIP); value stream mapping identifies bottlenecks; continuous improvement (kaizen) philosophy; directly influenced DevOps practices and CI/CD pipeline design
- Waterfall vs Agile: Waterfall is sequential (requirements, design, implementation, testing, deployment) with no backtracking; Agile is iterative with continuous feedback loops; Waterfall suits projects with fixed, well-understood requirements; Agile suits projects with evolving requirements and the need for frequent delivery; most modern Cisco development projects use Agile methodologies
- Code Review Best Practices: Pull requests provide a structured review process; reviewers check for code quality, adherence to standards, security vulnerabilities, test coverage, and documentation; automated linting (pylint, flake8) catches style issues before human review; pair programming provides real-time code review; small, focused pull requests are easier to review than large omnibus changes
REST API Fundamentals
| Concept | Description |
|---|---|
| HTTP Methods | GET (retrieve resource, safe and idempotent, no request body), POST (create resource, not idempotent, request body contains new resource data), PUT (replace entire resource, idempotent, full resource in body), PATCH (partial update, modify specific fields only), DELETE (remove resource, idempotent); OPTIONS returns allowed methods for a resource; HEAD returns headers only without body; understand the distinction between idempotent (GET, PUT, DELETE) and non-idempotent (POST) operations |
| HTTP Status Codes | 2xx Success: 200 OK (general success), 201 Created (resource created, often with Location header), 202 Accepted (async processing started), 204 No Content (success with no body, common for DELETE); 3xx Redirection: 301 Moved Permanently, 304 Not Modified; 4xx Client Error: 400 Bad Request (malformed syntax), 401 Unauthorized (authentication required), 403 Forbidden (authenticated but not authorized), 404 Not Found, 405 Method Not Allowed, 409 Conflict, 429 Too Many Requests (rate limited); 5xx Server Error: 500 Internal Server Error, 503 Service Unavailable |
| REST Constraints | Client-server architecture (separation of concerns), Statelessness (each request contains all needed information, no server-side session state), Cacheability (responses must declare themselves cacheable or non-cacheable), Uniform interface (resource identification via URIs, manipulation through representations, self-descriptive messages, HATEOAS), Layered system (client cannot tell if connected directly to server or intermediary), Code on demand (optional, server can extend client functionality) |
| Pagination | Offset-based: ?offset=20&limit=10 returns items 21-30; Cursor-based: ?cursor=abc123 returns the next page after the cursor token; Link headers provide next/prev/first/last page URLs; Cisco DNA Center uses startIndex and recordsCount; Meraki uses Link header with rel=next for cursor-based pagination; always check for and handle pagination in production code to avoid missing data from large result sets |
| Rate Limiting | APIs enforce request limits to prevent abuse and ensure fair usage; indicated by 429 Too Many Requests response; X-RateLimit-Limit (max requests), X-RateLimit-Remaining (requests left), X-RateLimit-Reset (when limit resets) headers; Meraki Dashboard API allows 10 requests per second per organization with a 429 Retry-After header; implement exponential backoff with jitter for retry logic; use rate limiting libraries or token bucket algorithms in client code |
Exam Tip: Understand the difference between PUT and PATCH. PUT replaces the entire resource (you must send all fields), while PATCH modifies only the specified fields. Know which HTTP method is idempotent and why. The exam frequently tests your ability to select the correct HTTP method and interpret status codes for given API scenarios.
API Authentication and Security
| Method | Description |
|---|---|
| Basic Authentication | Username:password Base64-encoded in the Authorization header (Authorization: Basic dXNlcjpwYXNz); simple but credentials sent with every request; must always use HTTPS to prevent credential interception; Python requests library supports auth=(username, password) parameter; used by Cisco IOS XE RESTCONF and some legacy APIs; not recommended for production without TLS |
| Token-Based Authentication | Client authenticates once and receives a token for subsequent requests; Authorization: Bearer <token> header; tokens have expiration times requiring refresh logic; Cisco DNA Center uses POST /dna/system/api/v1/auth/token with Basic auth to obtain a token that expires after a configurable period; reduces credential exposure compared to Basic auth; token revocation provides immediate access removal |
| API Keys | Static keys sent as a header or query parameter; Cisco Meraki uses X-Cisco-Meraki-API-Key header (now also supports Authorization: Bearer); simple to implement but difficult to rotate; should be treated as secrets and never committed to version control; .env files or environment variables for local development; secrets managers (HashiCorp Vault, AWS Secrets Manager) for production deployments |
| OAuth 2.0 | Authorization framework supporting multiple grant types; Authorization Code (for web apps with server-side backend, most secure), Client Credentials (for machine-to-machine, no user interaction), Implicit (deprecated, was for SPAs), Resource Owner Password (legacy, sends credentials directly); Cisco Webex uses OAuth 2.0 with Authorization Code grant; involves Authorization Server, Resource Server, Client, and Resource Owner roles; access tokens are short-lived, refresh tokens obtain new access tokens without re-authentication |
Webhooks and Asynchronous APIs
| Concept | Description |
|---|---|
| Webhooks | Server-to-server HTTP POST callbacks triggered by events; reverse of polling where the server pushes data to the client; the client registers a callback URL and the server sends event payloads to that URL when events occur; Cisco Webex Webhooks notify applications of new messages, room membership changes, and file uploads; Meraki Webhooks alert on network events, device status changes, and security incidents; validate webhook payloads using HMAC signatures to prevent spoofing; implement idempotent handlers since webhooks may be delivered more than once |
| Polling vs Webhooks | Polling: client repeatedly requests data at intervals; simple to implement but wasteful (most requests return no new data), introduces latency between event and detection, and wastes API rate limit quota; Webhooks: server pushes data in real-time when events occur; more efficient, lower latency, but requires a publicly accessible endpoint, handling retries, and managing delivery failures; prefer webhooks when real-time notification is needed and the API supports them |
| Asynchronous API Patterns | Long-running operations return 202 Accepted with a task URL; client polls the task URL until the operation completes; DNA Center command runner and template deployment use this pattern: POST starts the task, response includes taskId, GET /task/{taskId} returns status (IN_PROGRESS, SUCCESS, FAILURE); alternative: callback URL provided in initial request, server notifies client when complete; implement timeout logic to avoid infinite polling; async/await in Python (asyncio, aiohttp) for concurrent API calls |
API Development and Documentation
- OpenAPI / Swagger: OpenAPI Specification (OAS) defines REST APIs in a machine-readable format (JSON or YAML); describes endpoints, parameters, request/response schemas, authentication methods, and error codes; Swagger UI renders interactive API documentation from the spec file; code generators produce client SDKs and server stubs from the spec; Cisco DNA Center, ACI, and other platforms publish OpenAPI specs for their APIs; version 3.x is the current standard
- API Versioning: URL path versioning (/api/v1/resource, /api/v2/resource) is most common and explicit; header versioning (Accept: application/vnd.api+json;version=2) keeps URLs clean; query parameter versioning (?version=2) is simple but less standard; Cisco platforms predominantly use URL path versioning; always version APIs from the start to avoid breaking changes for consumers
- CRUD Operations Mapping: Create = POST, Read = GET, Update = PUT/PATCH, Delete = DELETE; resource-oriented URL design: /api/v1/devices (collection), /api/v1/devices/{id} (single resource); avoid verbs in URLs (use POST /devices not POST /createDevice); use query parameters for filtering, sorting, and pagination (/devices?status=active&sort=name&limit=10)
- Error Handling in APIs: Return consistent error response format with status code, error message, and details; use appropriate HTTP status codes (400 for bad input, 404 for missing resource, 500 for server failures); include a correlation ID for tracking errors across distributed systems; provide actionable error messages that help the consumer fix the issue; never expose internal implementation details or stack traces in production error responses
Exam Tip: The exam tests your ability to construct proper API requests including the correct URL, HTTP method, headers, and body. Practice building requests in Python using the requests library. Know the difference between path parameters (/devices/{id}), query parameters (/devices?status=active), and request body content. Understand how Content-Type and Accept headers control request and response data formats.
Cisco DNA Center (Catalyst Center) API
| Feature | Description |
|---|---|
| Authentication | Token-based: POST to /dna/system/api/v1/auth/token with Basic Authentication (username:password Base64-encoded); returns a JSON response with a Token field; include token in subsequent requests as X-Auth-Token header; tokens expire after a configurable timeout (default 60 minutes); implement token refresh logic in automation scripts; always use HTTPS as DNA Center uses self-signed certificates by default (verify=False or install the CA certificate) |
| Intent APIs | High-level APIs that abstract complex network operations into simple intent-based calls; Know Your Network APIs: /dna/intent/api/v1/network-device (list devices), /dna/intent/api/v1/site (manage sites), /dna/intent/api/v1/topology (get network topology); Site Management: create sites, buildings, and floors in the hierarchy; Device Management: inventory, health monitoring, command runner; Network Settings: DNS, DHCP, NTP, AAA, SNMP configuration through the API |
| Template Programmer | Deploy configuration templates to network devices via API; templates use Velocity or Jinja2 syntax for variable substitution; workflow: create project, create template within project, version the template, deploy template to devices with variable bindings; API: POST /dna/intent/api/v1/template-programmer/template/deploy; returns a task ID for tracking deployment status; template versioning supports rollback capabilities; bulk deployment sends configurations to multiple devices simultaneously |
| Command Runner | Execute read-only CLI commands on network devices through the API; POST /dna/intent/api/v1/network-device-poller/cli/read-request with device UUIDs and commands array; asynchronous operation returns taskId; poll GET /dna/intent/api/v1/task/{taskId} until completion; retrieve results from the task's fileId; supports show commands only (no configuration commands); useful for collecting operational data programmatically across many devices; Python SDK (dnacentersdk) simplifies these interactions |
| Event and Notification APIs | Subscribe to DNA Center events via webhooks, email, or syslog; event catalog lists all available events (device unreachable, configuration changes, assurance alerts); create event subscriptions specifying the event type and delivery destination; webhook notifications POST JSON payloads to your registered callback URL; events enable real-time integration with ITSM platforms, ChatOps tools, and custom monitoring dashboards |
Exam Tip: DNA Center API authentication is a two-step process: first obtain a token with Basic Auth, then use that token in the X-Auth-Token header for all subsequent calls. The Intent API base path is /dna/intent/api/v1/. Async operations (command runner, template deployment) require polling the task endpoint. Use the DevNet Sandbox for hands-on practice with a live DNA Center instance.
Cisco Meraki Dashboard API
| Concept | Description |
|---|---|
| API Structure | Cloud-hosted REST API at https://api.meraki.com/api/v1/; hierarchical resource model: Organizations > Networks > Devices; authentication via API key in X-Cisco-Meraki-API-Key header or Authorization: Bearer header; API must be enabled per organization in Meraki Dashboard; rate limit: 10 requests per second per organization with 429 response and Retry-After header; responses in JSON format; Python SDK available (meraki library) for simplified interactions |
| Common Endpoints | GET /organizations (list orgs), GET /organizations/{orgId}/networks (list networks), GET /networks/{netId}/devices (list devices), GET /devices/{serial}/clients (list clients on a device), PUT /devices/{serial} (update device settings), POST /organizations/{orgId}/networks (create network); Action Batches: POST /organizations/{orgId}/actionBatches to execute multiple API calls atomically; useful for bulk changes across many networks or devices |
| Webhooks and Alerts | Configure webhook receivers under network alert settings; Meraki sends HTTP POST to registered URL when events occur (device goes offline, client connects, configuration changes); payload includes alertType, organizationId, networkId, deviceSerial, and event-specific data; webhook payload includes a sharedSecret for verification; alerting is configured per network with customizable triggers; supports integration with Webex, Slack, PagerDuty, and custom endpoints |
Cisco ACI (Application Centric Infrastructure)
| Component | Description |
|---|---|
| APIC REST API | Application Policy Infrastructure Controller exposes all ACI functionality via REST API; authentication: POST to /api/aaaLogin.json with username and password returns a token cookie (APIC-cookie); all objects addressable via Distinguished Name (DN) in the MIT (Management Information Tree); base URL pattern: https://apic/api/node/mo/{dn}.json for managed objects, https://apic/api/node/class/{className}.json for class queries; supports JSON and XML response formats; every ACI object has a class and DN |
| ACI Object Model | Hierarchical MIT (Management Information Tree) with all configuration as managed objects (MOs); key objects: Tenant (top-level container), VRF (routing domain), Bridge Domain (L2 forwarding domain), Subnet, Application Profile (groups EPGs), Endpoint Group (EPG, groups endpoints with same policy), Contract (defines allowed communication between EPGs), Filter (L3/L4 rules within contracts); the object model is the foundation of all ACI API interactions |
| Cobra SDK and ACI Toolkit | Cobra SDK is the official Python SDK mapping every ACI object class to a Python class; provides full CRUD operations on the MIT; ACI Toolkit is a simplified, community-driven library with higher-level abstractions (Tenant, AppProfile, EPG, Contract classes); Toolkit is easier to learn, Cobra provides complete coverage; both handle authentication, session management, and object serialization; arya tool converts APIC JSON/XML to Cobra SDK Python code |
Cisco Collaboration and Security Platforms
- Webex APIs: RESTful API for messaging, meetings, and devices at https://webexapis.com/v1/; OAuth 2.0 authentication with personal access tokens for development and integration tokens for bots; key resources: /people, /rooms, /messages, /memberships, /webhooks, /meetings; Webex Bots listen for messages via webhooks and respond programmatically; Adaptive Cards enable rich interactive messages with buttons, forms, and formatted content; SDKs available for Python (webexteamssdk), Node.js, and Java
- Cisco Firepower / FMC API: Firepower Management Center REST API for security policy management; token-based authentication via POST /api/fmc_platform/v1/auth/generatetoken; manage access control policies, network objects, intrusion policies, and NAT rules programmatically; supports bulk operations for large-scale security deployments; API Explorer built into FMC web interface for testing endpoints
- Cisco UCS Manager API: XML-based API for Unified Computing System management; all UCS objects represented in an MIT similar to ACI; Python SDK (ucsmsdk) provides object-oriented access; manage service profiles, VLANs, policies, and firmware upgrades programmatically; used for data center compute automation and server provisioning
- Cisco SD-WAN (vManage) API: REST API for SD-WAN management via the vManage controller; token-based authentication with session cookies; manage device templates, policies, and monitoring; key endpoints include /dataservice/device for device inventory and /dataservice/template for template management; enables programmatic control of WAN overlay networks across branch offices
Docker and Containerization
| Concept | Description |
|---|---|
| Docker Fundamentals | Containers package applications with all dependencies into isolated, portable units; Docker Engine runs containers using OS-level virtualization (shared kernel, unlike VMs which include a full guest OS); images are read-only templates built from Dockerfiles; containers are running instances of images with a writable layer; Docker Hub is the default public registry for pulling and pushing images; containers are ephemeral by design, data should be persisted using volumes; lightweight compared to VMs with faster startup times and lower resource overhead |
| Dockerfile | Text file with instructions to build a Docker image; FROM sets the base image (python:3.9-slim); WORKDIR sets the working directory; COPY transfers files from host to image; RUN executes commands during build (pip install -r requirements.txt); EXPOSE documents the listening port; ENV sets environment variables; CMD defines the default command when the container starts; ENTRYPOINT sets the main executable; multi-stage builds reduce final image size by copying only artifacts from build stages; layer caching optimizes build speed by reusing unchanged layers |
| Docker Commands | docker build -t name:tag . (build image from Dockerfile), docker run -d -p 8080:80 name (run container detached with port mapping), docker ps (list running containers), docker logs container_id (view container output), docker exec -it container_id bash (interactive shell), docker stop/start/restart (lifecycle management), docker images (list local images), docker pull/push (registry operations), docker network create/ls (manage networks), docker volume create/ls (manage persistent storage) |
| Docker Compose | Define and run multi-container applications using a YAML file (docker-compose.yml); services define each container with build context, image, ports, volumes, environment variables, and dependencies; networks connect services for inter-container communication; volumes provide persistent storage shared between containers and the host; docker-compose up -d starts all services, docker-compose down stops and removes them; depends_on controls startup order; ideal for development environments and testing multi-service applications |
| Container Networking | Bridge network (default, containers on same host communicate via internal DNS), Host network (container shares host network stack, no port mapping needed), Overlay network (spans multiple Docker hosts for Swarm/distributed deployments), None (no networking, fully isolated); containers on the same user-defined bridge network can resolve each other by container name; port mapping (-p host:container) exposes container services to the host; Docker DNS resolves service names in docker-compose environments |
Exam Tip: Know the Dockerfile instruction order matters for layer caching. Place infrequently changing instructions (FROM, RUN apt-get install) before frequently changing ones (COPY application code). This ensures Docker can cache the early layers and only rebuild from the changed layer onwards, significantly speeding up builds. Understand the difference between CMD and ENTRYPOINT.
CI/CD Pipelines
| Stage | Description |
|---|---|
| Continuous Integration (CI) | Developers merge code changes frequently to a shared branch; each merge triggers automated build and test execution; CI server (Jenkins, GitHub Actions, GitLab CI, Drone) detects commits and runs the pipeline; pipeline stages typically include: checkout code, install dependencies, run linters (pylint, flake8), execute unit tests (pytest), measure code coverage, run static analysis (bandit for security); fast feedback loop catches integration issues early; build artifacts (Docker images, packages) are produced on successful CI runs |
| Continuous Delivery (CD) | Extends CI by automatically deploying to staging/production environments; deployment pipeline includes: build, test, deploy to staging, run integration/smoke tests, manual approval gate (delivery) or automatic promotion (deployment); blue-green deployment runs two identical environments and switches traffic; canary deployment routes a small percentage of traffic to the new version; rolling update gradually replaces instances; infrastructure-as-code (Terraform, Ansible) ensures consistent environment provisioning |
| Jenkins Pipeline | Jenkinsfile defines pipeline as code in Groovy DSL; declarative syntax uses pipeline{}, agent{}, stages{}, steps{} blocks; scripted syntax uses node{} with Groovy programming; stages represent logical pipeline phases (Build, Test, Deploy); post{} block defines actions for success, failure, or always conditions; environment{} block sets variables; credentials binding injects secrets securely; pipeline libraries enable code reuse across projects; triggers include SCM polling, webhook, cron schedule |
| GitHub Actions | Workflow files defined in .github/workflows/ as YAML; triggered by events (push, pull_request, schedule, workflow_dispatch); jobs run on runners (ubuntu-latest, windows-latest, macos-latest); steps use actions (reusable units: actions/checkout, actions/setup-python) or run shell commands; secrets stored in repository settings and accessed via ${{ secrets.NAME }}; matrix strategy runs jobs across multiple configurations (Python versions, OS); artifacts upload/download share data between jobs |
Application Security
| Security Concern | Description |
|---|---|
| OWASP Top 10 | Injection (SQL, command, LDAP injection from unsanitized input), Broken Authentication (weak passwords, missing MFA, session fixation), Sensitive Data Exposure (unencrypted data at rest or in transit, weak cryptography), XML External Entities (XXE parsing attacks), Broken Access Control (IDOR, privilege escalation, missing authorization checks), Security Misconfiguration (default credentials, verbose error messages, unnecessary services), Cross-Site Scripting (XSS reflected, stored, DOM-based), Insecure Deserialization (untrusted data deserialized into objects), Using Components with Known Vulnerabilities (outdated libraries), Insufficient Logging and Monitoring (failure to detect and respond to breaches) |
| Secrets Management | Never hardcode credentials, API keys, tokens, or certificates in source code; use environment variables for local development (.env files excluded via .gitignore); use secrets managers (HashiCorp Vault, AWS Secrets Manager, Cisco Vault) for production; CI/CD platforms provide secrets injection (Jenkins credentials, GitHub Secrets); rotate secrets regularly and implement automated rotation; detect accidentally committed secrets using tools like git-secrets, truffleHog, or GitHub secret scanning; revoke compromised credentials immediately |
| TLS/SSL and Certificates | Transport Layer Security encrypts data in transit between client and server; TLS 1.2 minimum, TLS 1.3 preferred; certificates issued by Certificate Authorities (CA) validate server identity; self-signed certificates used in lab environments (Cisco devices often use self-signed certs); in Python requests, verify=True validates CA certificates (default), verify=False disables verification (insecure, development only), verify='/path/to/ca-bundle.crt' uses custom CA; mutual TLS (mTLS) requires both client and server certificates for bi-directional authentication |
| Input Validation | Validate all input on the server side regardless of client-side validation; whitelist (allow known good) is more secure than blacklist (block known bad); parameterized queries prevent SQL injection; escape output to prevent XSS; validate data types, lengths, ranges, and formats; use frameworks that provide built-in protection (Django ORM, Flask-WTF); API input validation should reject requests with unexpected fields, incorrect types, or values outside acceptable ranges; return 400 Bad Request with descriptive error messages for invalid input |
Exam Tip: The exam tests your understanding of secure development practices in the context of Cisco platform integrations. When connecting to Cisco APIs with self-signed certificates in production, install the CA certificate and reference it with verify='/path/to/cert' rather than disabling verification entirely with verify=False. Know how to store and retrieve secrets securely in CI/CD pipelines.
Cloud and Edge Deployment
- Kubernetes Basics: Container orchestration platform for deploying, scaling, and managing containerized applications; Pods are the smallest deployable unit (one or more containers); Deployments manage replica sets and rolling updates; Services provide stable network endpoints (ClusterIP, NodePort, LoadBalancer); ConfigMaps and Secrets manage configuration and sensitive data; Namespaces provide resource isolation; kubectl is the CLI tool for cluster interaction; YAML manifests define desired state declaratively
- Cisco IOx and Edge Computing: IOx is Cisco's application hosting framework for network devices (Catalyst switches, ISR routers, IR industrial routers); enables running containerized applications directly on network infrastructure at the edge; applications packaged as Docker containers deployed via IOx Local Manager or Fog Director; reduces latency by processing data closer to the source; use cases include IoT data processing, local analytics, and branch office applications
- Cloud-Native Development: Twelve-factor app methodology: codebase in version control, explicit dependency declaration, config in environment variables, backing services as attached resources, strict separation of build/release/run, stateless processes, port binding, concurrency via process model, disposability (fast startup/graceful shutdown), dev/prod parity, logs as event streams, admin processes as one-off tasks; microservices architecture decomposes monoliths into independently deployable services communicating via APIs
YANG Data Models
| Concept | Description |
|---|---|
| YANG Overview | Yet Another Next Generation data modeling language defined in RFC 7950; describes the structure, syntax, and semantics of network configuration and operational state data; used by NETCONF and RESTCONF protocols as the schema definition; models are organized into modules and submodules with namespace, prefix, and revision; models are hierarchical, describing data as a tree of nodes; key advantage is vendor-neutral, machine-readable network data definitions enabling multi-vendor automation |
| YANG Node Types | container: groups related nodes (no data value itself), list: sequence of entries identified by key leaves (like a database table), leaf: single data value with a type (string, uint32, boolean, enumeration, inet:ipv4-address), leaf-list: sequence of single values (like an array), choice: selects one of several alternatives, augment: extends another module's data model, grouping/uses: reusable node definitions; understand the tree structure output from pyang -f tree which visualizes the model hierarchy |
| Model Categories | IETF models: vendor-neutral standards (ietf-interfaces, ietf-ip, ietf-routing) defined by IETF working groups; OpenConfig models: vendor-neutral operational models from the OpenConfig consortium focusing on real-world operator needs; Native models: vendor-specific models (Cisco-IOS-XE-native, Cisco-IOS-XR-*) providing full feature coverage for a specific platform; native models offer the most complete feature set but are not portable across vendors; IETF and OpenConfig models provide portability but may lack platform-specific features |
| pyang Tool | Python-based YANG validator and converter; pyang -f tree model.yang displays the model as a human-readable tree; pyang -f jstree generates interactive HTML documentation; pyang -f jsonxsl generates XSLT for XML to JSON conversion; validates YANG syntax and semantics; resolves imports and includes across modules; essential tool for exploring and understanding YANG models before writing automation code; install via pip install pyang |
Exam Tip: Understand the YANG tree notation: rw means read-write (configuration data), ro means read-only (operational state data), + indicates a list key, ? indicates an optional node. Know how to read pyang tree output to identify the correct path for RESTCONF URLs. The path /ietf-interfaces:interfaces/interface=GigabitEthernet1 corresponds to the YANG container interfaces containing list interface keyed by name.
RESTCONF
| Feature | Description |
|---|---|
| Protocol Overview | RESTful interface to YANG-modeled data defined in RFC 8040; uses HTTPS as transport (port 443); standard HTTP methods map to operations: GET (read data), POST (create data), PUT (create or replace data), PATCH (merge/update data), DELETE (remove data); content types: application/yang-data+json (JSON encoding) or application/yang-data+xml (XML encoding); combines the familiarity of REST APIs with the rigor of YANG data models; simpler to use than NETCONF for basic operations |
| URL Structure | Base URL: https://{host}/restconf/data/{yang-path}; root discovery: GET /.well-known/host-meta returns the RESTCONF root resource; data resource: /restconf/data/ for configuration and state data; operations resource: /restconf/operations/ for RPC operations; example paths: /restconf/data/ietf-interfaces:interfaces (all interfaces), /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1 (specific interface by key), /restconf/data/Cisco-IOS-XE-native:native/hostname (device hostname using native model); query parameters: ?depth=, ?fields=, ?content=config|nonconfig|all |
| Python with RESTCONF | Use the requests library with Basic Authentication; set Accept and Content-Type headers to application/yang-data+json; GET requests retrieve configuration or operational data; PUT/PATCH requests send JSON body matching the YANG model structure; example: requests.get(url, auth=(user,pass), headers=headers, verify=False); parse JSON response with response.json(); handle errors by checking response.status_code; common pattern: build URL from YANG path, set headers, make request, validate response, parse data |
NETCONF
| Feature | Description |
|---|---|
| Protocol Overview | Network Configuration Protocol defined in RFC 6241; uses SSH as transport (default port 830); XML-based RPC mechanism for managing network device configurations; supports YANG data models for structured data; connection-oriented with persistent sessions; message framing uses ]]>]]> delimiter (NETCONF 1.0) or chunked framing (NETCONF 1.1); supports capabilities exchange during session setup where client and server advertise their supported features |
| Operations | <get> retrieves running configuration and operational state data; <get-config> retrieves configuration from a specific datastore (running, startup, candidate); <edit-config> modifies configuration with operations: merge (default, combine with existing), replace (overwrite), create (fail if exists), delete (fail if not exists), remove (delete if exists, ignore otherwise); <copy-config> copies entire datastore; <delete-config> removes a datastore; <lock>/<unlock> prevents concurrent modifications; <commit> applies candidate to running (when candidate datastore is supported); <validate> checks configuration syntax |
| ncclient Python Library | Python library for NETCONF client operations; connect: manager.connect(host, port=830, username, password, hostkey_verify=False); m.get_config(source='running') retrieves full running config; m.get_config(source='running', filter=('subtree', xml_filter)) retrieves filtered data; m.edit_config(target='running', config=xml_config) modifies configuration; m.get() retrieves operational state; parse XML responses using xml.etree.ElementTree or lxml; always close the session with m.close_session(); supports context manager (with statement) for automatic cleanup |
| NETCONF vs RESTCONF | NETCONF: SSH transport, XML encoding only, full transaction support with candidate datastore and commit/rollback, lock/unlock for concurrent access control, connection-oriented persistent sessions, subtree and XPath filtering; RESTCONF: HTTPS transport, JSON and XML encoding, stateless HTTP requests, no native transaction/lock support, URL-based resource identification, familiar REST paradigm; use NETCONF for complex transactional operations requiring atomic changes; use RESTCONF for simple CRUD operations and integration with web-based tools |
Automation Tools and Frameworks
- Ansible for Network Automation: Agentless automation using SSH or API connections; YAML playbooks define desired state; inventory files list managed devices with connection variables; modules for Cisco platforms: ios_config, ios_command (IOS/IOS-XE), nxos_config (Nexus), aci_tenant, aci_epg (ACI), meraki_network (Meraki); roles organize reusable playbook components; Jinja2 templates generate device-specific configurations; idempotent operations ensure running a playbook multiple times produces the same result; collections (cisco.ios, cisco.nxos, cisco.aci, cisco.meraki) provide platform-specific modules
- Terraform for Infrastructure as Code: Declarative infrastructure provisioning using HCL (HashiCorp Configuration Language); providers connect to APIs (Cisco ACI, Meraki, AWS, Azure); resources define infrastructure components; state file tracks current infrastructure; plan shows proposed changes before applying; apply creates or modifies infrastructure; destroy removes managed infrastructure; modules encapsulate reusable configurations; Cisco providers include CiscoDevNet/aci, CiscoDevNet/meraki for managing network infrastructure as code
- Python Automation Libraries: Netmiko (SSH-based CLI automation for multi-vendor devices, simplifies paramiko), NAPALM (Network Automation and Programmability Abstraction Layer with Multivendor support, provides unified get/set interface), Nornir (Python automation framework using inventory and tasks, alternative to Ansible for Python-native workflows), pyATS/Genie (Cisco test automation framework for parsing CLI output into structured data, network state verification)
- Configuration Management Comparison: Ansible (agentless, push model, YAML playbooks, SSH/API), Puppet (agent-based, pull model, declarative DSL, Ruby), Chef (agent-based, pull model, imperative recipes, Ruby), Salt (agent or agentless, push/pull, YAML states, Python); for network automation, Ansible is the most widely adopted due to its agentless architecture and extensive network module ecosystem; Terraform is preferred for provisioning infrastructure while Ansible handles ongoing configuration management
Quick Reference Summary
| Scenario | Solution |
|---|---|
| Authenticate to DNA Center API | POST /dna/system/api/v1/auth/token with Basic Auth, use X-Auth-Token header |
| Get Meraki network devices | GET /api/v1/networks/{netId}/devices with X-Cisco-Meraki-API-Key header |
| Read interface config via RESTCONF | GET /restconf/data/ietf-interfaces:interfaces with Accept: application/yang-data+json |
| Modify config via NETCONF | ncclient edit_config(target='running', config=xml) with YANG-structured XML payload |
| Containerize a Python app | Dockerfile with FROM python:3.9-slim, COPY, pip install, CMD, then docker build and run |
| Automate config deployment to IOS devices | Ansible playbook with cisco.ios.ios_config module or DNA Center Template Programmer API |
| Explore a YANG model structure | pyang -f tree model.yang to visualize the data tree hierarchy |
| Handle Meraki API rate limiting | Check for 429 status, read Retry-After header, implement exponential backoff with jitter |
| Receive real-time event notifications | Register webhooks on Webex, Meraki, or DNA Center for push-based event delivery |
| Secure API credentials in CI/CD | Store in Jenkins credentials or GitHub Secrets, inject via environment variables at runtime |
| Authenticate to ACI APIC | POST /api/aaaLogin.json with credentials, use returned APIC-cookie token |
| Build a Webex chatbot | OAuth 2.0 bot token, register webhook for messages, respond via POST /v1/messages |
Exam Tip: The DEVCOR exam is 20% on each of the five domains, so every topic matters equally. Focus your final review on areas where you lack hands-on experience. Use the Cisco DevNet Sandbox (free) to practice with real APIs. Remember that RESTCONF URLs map directly to YANG model paths, NETCONF uses XML with YANG-defined structure, and Ansible provides the simplest path to multi-device automation without custom Python scripting.