Cisco 350-401: Automação, Programabilidade e APIs — Guia de estudos

By Laurynas Brazys · 15 August 2026 · #cisco #350-401 #certification #exam-prep #study-guide

Faz parte do Cisco CCNP Enterprise 350-401 ENCOR — Guia de estudos. Pratique com respostas verificadas no centro de exames da Cisco, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

As redes corporativas estão migrando da configuração dispositivo a dispositivo para operações baseadas em controladoras, orientadas por intenção e com automação em malha fechada. A programabilidade expõe o estado e o controle da rede por meio de APIs e modelos de dados, enquanto ferramentas como Python, Ansible e Git permitem fluxos de trabalho repetíveis e testáveis. O objetivo é expressar os resultados desejados de forma declarativa, fazer com que as controladoras traduzam a intenção em políticas e configurações, medir os resultados por meio de telemetria e assurance (garantia) e corrigir desvios automaticamente ou com aprovação humana. Para alcançar isso, é necessário entender as funções das controladoras, APIs e protocolos (REST, NETCONF/RESTCONF com YANG), formatos de dados (JSON, XML, YAML), plataformas de automação (Cisco DNA Center) e disciplinas operacionais (idempotência, controle de versão, testes, gerenciamento de riscos e rollback).

Controladoras, Intenção e Operações em Malha Fechada

• Redes baseadas em controladoras e suas funções:
  • O Cisco SD-WAN separa os planos: o vManage fornece o plano de gerenciamento único; o vSmart gerencia o plano de controle e distribui políticas que direcionam o encaminhamento de dados pelo fabric; o vBond orquestra o onboarding e pode atuar como um servidor STUN para atravessar NAT. Os roteadores de borda SD-WAN usam OMP como o protocolo do plano de controle para se comunicar com o vSmart.
  • O Cisco SD-Access cria uma rede de sobreposição (overlay) que fornece separação lógica de Camada 2 e Camada 3. Um nó do plano de controle do fabric mantém um banco de dados global de endpoint para localização, enquanto um nó de borda do fabric conecta o fabric a redes externas. Em redes sem fio, o Gerenciamento de Recursos de Rádio (Radio Resource Management) é executado na controladora sem fio.
• Intenção e configuração declarativa:
  • A intenção descreve o resultado desejado, não como implementá-lo em cada dispositivo. Sistemas declarativos (por exemplo, “segmentar visitantes em todos os lugares com acesso apenas à Internet”) permitem que as controladoras compilem a política em configurações específicas do dispositivo.
  • Trade-offs: Modelos declarativos simplificam as operações e reduzem o desvio (drift), mas podem ocultar detalhes de implementação. Os operadores precisam de ferramentas transparentes para diff/preview (comparação/pré-visualização) e rollback para manter a confiança.
• Operações em malha fechada:
  • Medir: Coletar o estado via telemetria por streaming e assurance (garantia) da controladora.
  • Analisar: Detectar desvios da intenção (por exemplo, violações de segmentação, quedas de SLA).
  • Agir: Corrigir por meio de atualizações de políticas, alterações de configuração ou engenharia de tráfego.
  • Modos de falha: Tempestades de eventos ou telemetria ruidosa podem acionar falsos positivos; loops de correção podem oscilar. Mecanismos de proteção (guardrails), como limites de taxa (rate limits), histerese e aprovações com intervenção humana, e uma correlação robusta evitam instabilidade (thrashing).

APIs, Modelos de Dados e Protocolos

• APIs REST:
  • Métodos: GET (leitura), POST (criação/ação), PUT (substituição), PATCH (atualização parcial), DELETE (remoção), HEAD/OPTIONS (metadados).
  • Códigos de status: 2xx sucesso (200 OK, 201 Created), 3xx redirecionamentos, 4xx erros do cliente (400 entrada inválida, 401 não autorizado, 403 proibido, 404 não encontrado, 409 conflito, 429 limite de taxa), 5xx erros do servidor (500, 503).
  • Autenticação: Básica (sobre TLS), esquemas de token/bearer e OAuth 2.0. Sempre use TLS; evite incorporar credenciais em URIs. Lide com a renovação e a expiração de tokens.
  • Limites de taxa (Rate limits): Servidores podem aplicar limitação (throttle) com o código 429 e o cabeçalho Retry-After. Implemente backoff exponencial, jitter e acompanhamento do orçamento de requisições nos clientes.
• Formatos de dados e validação:
  • JSON é comum para REST; XML continua prevalente em NETCONF; YAML é usado para arquivos escritos por humanos (inventários, playbooks, conjuntos de variáveis). Converta YAML para JSON internamente quando necessário.
  • Validação de schema: Use JSON Schema para payloads JSON; XML Schema para XML; YANG para gerenciamento baseado em modelos (tipos, restrições, declarações must/when). Valide no lado do cliente antes de enviar para detectar erros antecipadamente.
• NETCONF, RESTCONF, YANG, RPCs e datastores:
  • Modelos YANG definem estruturas de dados e operações para configuração e estado.
  • O NETCONF usa XML sobre SSH, com operações como , , , , , . Os datastores normalmente incluem running e candidate; o candidate permite o padrão preparar-e-confirmar (prepare-and-commit) com atomicidade.
  • O RESTCONF mapeia recursos modelados em YANG para uma interface RESTful sobre HTTP(S), usando JSON ou XML com tipos de mídia (media types) padronizados. Os métodos são mapeados para a semântica do NETCONF (PATCH/PUT para edições).
  • Modos de falha e design:
    • Contenção de bloqueio (lock): Coordene o uso de para evitar deadlocks; use escopo restrito e timeouts.
    • Falhas parciais: Prefira usar o datastore candidate + para alterações transacionais. Se apenas o running estiver disponível, use grupos de alteração estruturados e checkpoints.
    • Desvio de modelo (Model drift): Dispositivos podem suportar diferentes revisões de módulos YANG; negocie as capacidades (capabilities) e teste durante a CI.
• Exemplos concisos:
  • Atualização parcial com RESTCONF (troca HTTP): PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1 Content-Type: application/yang-data+json { “ietf-interfaces:interface”: { “name”: “GigabitEthernet1”, “description”: “Uplink”, “enabled”: true } }
  • NETCONF com Python (ncclient): from ncclient import manager cfg = """ GigabitEthernet1 Uplink true """ with manager.connect(host=“r1”, port=830, username=“netops”, password="***", hostkey_verify=False) as m: m.edit_config(target=“candidate”, config=cfg) m.commit()

Ferramentas e Workflows: Python, Ansible, Git e Pipelines

• Automação com Cisco DNA Center:
  • As APIs REST Northbound fornecem acesso a inventário, modelos (templates), provisionamento e assurance. As interfaces Southbound conectam o controlador aos dispositivos (CLI, SNMP, NETCONF/RESTCONF) para implementar a intenção.
  • Workflows de descoberta podem usar CDP, LLDP e faixas de IP. Use controle de acesso baseado em função (RBAC), modelos baseados em projeto e variáveis por site. O Assurance correlaciona a telemetria em problemas, pontuações de saúde e remediações sugeridas — insumos essenciais para a automação de ciclo fechado (closed-loop).
• Fundamentos de Python para automação de redes:
  • Núcleo da linguagem: tipos, funções, módulos, ambientes virtuais (virtual environments) e logging.
  • Bibliotecas: requests/httpx (REST), ncclient (NETCONF), jinja2 (templates), pyyaml, json, pandas (tratamento de dados), rich/logging para observabilidade.
  • Práticas: validação de entrada, novas tentativas com backoff, exceções estruturadas, timeouts e testes unitários. Serialize a lógica de negócios separadamente da E/S (I/O) para simplificar os testes.
• Ansible:
  • O inventário define hosts e grupos; mantenha host_vars/group_vars em YAML.
  • Playbooks declaram o estado desejado; módulos como ios_config, ios_facts, iosxe_config, restconf_config e uri executam ações. Use roles para encapsular lógica reutilizável.
  • Idempotência: Módulos garantem que execuções repetidas convirjam sem alterações não intencionais. Use check_mode e diff para pré-visualizar; notifique handlers para salvar apenas quando houver alteração.
  • Exemplo:
    • hosts: edge connection: network_cli gather_facts: no tasks:
      • ios_config: parents: interface GigabitEthernet1 lines: - description Uplink notify: save handlers:
      • name: save ios_config: save_when: changed
  • Controle de mudanças: use janelas de manutenção, estratégia serial ou em lote (batch) e limitação (throttling) por site para limitar o raio de impacto. Capture verificações pré e pós-mudança automaticamente.
• Git, versionamento, testes e pipelines:
  • Armazene a intenção da rede (variáveis YAML, templates Jinja, playbooks), configurações geradas e testes no Git. Use branches, pull requests e revisão de código (code review). Commits semânticos e tags alinham as versões com as implantações.
  • Testes: faça o lint de YAML e playbooks, valide esquemas (schemas) YANG/JSON, execute testes unitários e testes de cenário com Ansible Molecule. Integre pré-verificações sintéticas (por exemplo, alcançabilidade) em CI.
  • Pipelines: Dev → homologação/laboratório (staging/lab) → canary em produção → implementação em fases (phased rollout). As etapas de controle (gates) incluem análise estática, execuções de simulação (dry-runs) em simuladores, aprovações e reversão (rollback) automática em caso de regressão da saúde do sistema.

Telemetria, Automação Orientada a Eventos e Gerenciamento de Riscos

• Streaming de telemetria:
  • A telemetria orientada a modelos (IOS XE, NX-OS) publica o estado modelado em YANG em intervalos definidos sobre gRPC/gNMI ou NETCONF, com assinaturas dial-in ou dial-out. Os benefícios incluem baixa latência e dados estruturados, superando a coleta periódica por CLI (CLI scraping) ou o polling SNMP.
  • Exemplo (IOS XE, conciso):

undefined

• Dicas de design: Alinhar a frequência de amostragem com o caso de uso; garantir a capacidade do barramento de mensagens; projetar pipelines de downsampling/agregação; proteger contra a perda de telemetria com buffering e confirmações (acknowledgments).
• Automação orientada a eventos:
  • Disparar ações com base em webhooks, syslog, traps SNMP, eventos do DNA Center ou tópicos do Kafka. Usar correlação e limitação de taxa (rate limiting) para evitar instabilidades (flaps) induzidas por tempestades de eventos. Manter handlers idempotentes que podem ser reexecutados com segurança.
  • Ciclo fechado (Closed-loop): Um controlador detecta uma violação de política, valida com sinais secundários, abre um ticket de mudança ou dispara uma remediação limitada, depois reavalia e finaliza.
• Gerenciamento de riscos, rollback e credenciais:
  • Mecanismos de proteção (Guardrails): rollouts em fases, limites de concorrência, controles de raio de impacto (blast-radius), backoff dinâmico em respostas 429/5xx e timeouts. Usar transações onde disponível (NETCONF candidate + commit), ou checkpoints de dispositivo e configure replace.
  • Rollback: Manter configurações padrão (golden configs), diffs e checkpoints por dispositivo. Preferir a semântica de commit-confirmed onde houver suporte; caso contrário, implementar fallback automatizado usando temporizadores e verificações de alcançabilidade.
  • Proteção de credenciais: impor RBAC, tokens de curta duração e segredos just-in-time por tarefa (job). Usar cofres de segredos (por exemplo, Ansible Vault ou um cofre externo), nunca incorporar segredos em playbooks ou no Git. Rotacionar credenciais regularmente e após mudanças de pessoal. Proteger as credenciais do controlador para o dispositivo e auditar o acesso.

Cenário de Problema Prático

A Aurelius Logistics planeja padronizar as configurações de campus e filiais, impor uma segmentação consistente e implementar garantia de qualidade em ciclo fechado (closed-loop assurance) usando o Cisco DNA Center, ao mesmo tempo em que permite mudanças seguras via Ansible e Git.

1. Fazer o baseline e descobrir a rede

• Justificativa: A descoberta do DNA Center usando faixas de IP mais CDP/LLDP enumera dispositivos e topologia, estabelecendo um inventário autoritativo. Isso permite o escopo da intenção e a herança de variáveis por localidade (site). A coleta de dados de assurance estabelece baselines de saúde pré-mudança para comparação e gatilhos de rollback.

2. Modelar a intenção e os templates no DNA Center

• Justificativa: Expressar políticas de segmentação (por exemplo, funcionário, IoT, convidado) e QoS de forma declarativa. Usar templates parametrizados com variáveis de localidade (site) para interfaces, roteamento e ACLs. A política declarativa permite que o controlador compile configurações específicas do dispositivo, reduzindo o erro humano e o desvio de configuração (drift).

3. Implementar gerenciamento de configuração orientado pelo Git

• Justificativa: Armazenar templates, variáveis de localidade (YAML) e testes de validação no Git. Feature branches e pull requests impõem a revisão por pares (peer review). Tags alinham as implantações com as versões, permitindo um rollback preciso. Isso fornece um histórico de mudanças auditável e suporta gatilhos de pipeline automatizados.

4. Construir um pipeline de CI/CD com portões de validação

• Justificativa: Os estágios do pipeline fazem o lint do YAML, validam payloads JSON/YANG, realizam testes unitários da renderização do Jinja e simulam chamadas de API em um ambiente de sandbox. Os dry runs do DNA Center e o check_mode/diff do Ansible validam as mudanças sem impacto. Somente após passar por todos os portões, o pipeline permite a aprovação do operador para prosseguir.

5. Implantar incrementalmente com Ansible e as APIs do DNA Center

• Justificativa: Usar as APIs northbound do DNA Center para enviar templates primeiro para uma localidade canário (canary site) e, em seguida, fazer o rollout em série por localidade com limites de tamanho de lote. Para dispositivos que suportam NETCONF/RESTCONF, os módulos do Ansible realizam atualizações direcionadas e idempotentes. Essa abordagem dupla aproveita o controlador para tarefas pesadas de política e a automação direta de dispositivos para mudanças refinadas, minimizando o raio de impacto.

6. Ativar streaming de telemetria e verificações orientadas por assurance

• Justificativa: Configurar telemetria orientada a modelos em dispositivos de borda para alimentar o DNA Center Assurance e a pilha de observabilidade da empresa. Definir SLOs (por exemplo, taxa de sucesso de onboarding, latência) e assinaturas de eventos que geram alertas se as métricas pós-mudança regredirem. Isso permite a detecção imediata de resultados negativos.

7. Habilitar remediação controlada em ciclo fechado

• Justificativa: Para desvios bem compreendidos (por exemplo, interface inativa com uma solução de contorno conhecida), permitir que o pipeline dispare um playbook restrito para reverter a última mudança ou aplicar um hotfix. Exigir aprovação humana para remediações mais amplas. Implementar backoff exponencial e tempo de espera (cooldown) para prevenir oscilações.

8. Preparar e testar os caminhos de rollback

• Justificativa: Antes de cada mudança, criar checkpoints do dispositivo ou usar NETCONF candidate + commit-confirmed, se disponível. Arquivar as configurações pré-mudança e marcar o repositório Git com uma tag. Se as pontuações de saúde caírem ou a telemetria mostrar violações de SLA, o pipeline executa configure replace ou NETCONF discard/rollback, restaurando o estado anterior rapidamente.

9. Proteger credenciais e impor controle de acesso

• Justificativa: Armazenar as credenciais de dispositivos/controladores em um cofre; injetar tokens de curta duração nas tarefas (jobs). Usar o RBAC do DNA Center para restringir os escopos da API. Nunca registrar segredos em logs; limpar (scrub) as saídas no CI. Rotacionar credenciais e tokens regularmente e após mudanças de pessoal para reduzir o risco.

10. Operacionalizar com documentação e runbooks

• Justificativa: Documentar as definições de intenção, esquemas de variáveis, modos de falha (limites de taxa, erros de API, incompatibilidades de modelo) e etapas de recuperação. Treinar o NOC para interpretar os sinais de assurance e os status do pipeline, garantindo respostas consistentes e rápidas a incidentes.

Essa abordagem cria um caminho seguro e testável da intenção à implementação, aproveita os controladores para distribuição de políticas (com vManage/vSmart em SD‑WAN e DNA Center no campus), usa ferramentas idempotentes para convergência e fecha o ciclo com validação baseada em telemetria e remediação controlada.

← Segurança Corporativa e Serviços de Identidade · Todos os domínios · Garantia de Rede →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →