350-901 Cheat Sheet

The cisco.ios.ios_vlans resource module is the modern declarative module for VLANs; with state: replaced it overwrites the config of the listed VLANs so the running VLAN entries match the playbook exactly, giving idempotent convergence rather than blind CLI pushes.

Trap Distractor uses the deprecated singular cisco.ios.ios_vlan which only adds VLANs and cannot declaratively replace the set.

Ansible network resource modules accept state values merged (default, additive), replaced (replace only the specified resources), overridden (replace and remove every resource not listed), and deleted. For VLANs, overridden deletes all VLANs absent from the playbook while replaced touches only the listed ones.

Trap Confusing replaced (per-resource) with overridden (whole-list) — overridden will wipe VLANs you did not list.

The gathered state returns current config as structured facts, rendered produces device CLI from the module input without connecting, and parsed converts a supplied running-config text into structured data. None of these three push configuration to the device.

The legacy cisco.ios.ios_vlan (singular) module was deprecated and removed from the cisco.ios collection after 2022-06-01; playbooks should use the plural cisco.ios.ios_vlans resource module for declarative, idempotent VLAN management.

cisco.ios.ios_ospfv2 manages the OSPFv2 process (areas, networks, redistribution, timers) as structured data, while cisco.ios.ios_ospf_interfaces manages per-interface OSPF settings; state: merged adds, replaced rewrites one process, overridden rewrites all.

Trap Using the generic ios_config module for OSPF instead of the declarative ios_ospfv2 resource module.

cisco.ios.ios_acls manages named and numbered IPv4/IPv6 ACLs as a structured list of ACEs; state: replaced rewrites a single named ACL to the given ACEs, while state: overridden reconciles ALL ACLs on the device to the module's definition.

Trap Assuming state: replaced touches every ACL on the device (it is scoped to the named ACL; overridden is the device-wide one).

cisco.ios.ios_interfaces manages L1/L2 interface attributes (description, enabled, mtu, speed, duplex); cisco.ios.ios_l3_interfaces manages the L3 addressing (IPv4/IPv6) on those interfaces — the correct module depends on which layer of interface setting is being automated.

Trap Trying to set an IP address with ios_interfaces (addressing lives in ios_l3_interfaces).

cisco.ios.ios_config pushes raw CLI imperatively; the parents list places the lines/commands into a config hierarchy, e.g. parents: interface GigabitEthernet1/0/1 with lines: ip access-group ACL_IN in enters that interface context before applying the lines.

ios_config defaults to match: line, comparing each candidate line against the running-config and sending only missing lines; setting match: none disables that comparison so every command is pushed on every run, destroying idempotency.

Trap Assuming ios_config is always idempotent — with match: none (or no diff-aware model) it re-pushes lines every run.

ios_config's save_when: modified copies running-config to startup-config only when the task actually changed the running-config, preserving idempotency; save_when: always writes every run and reports changed each time.

For structured features (VLANs, OSPF, interfaces, ACLs) prefer the declarative resource modules (ios_vlans, ios_ospfv2, ios_l3_interfaces, ios_acls) which model and converge state; reserve ios_config for raw CLI that no resource module covers.

Network devices set ansible_connection to ansible.netcommon.network_cli (SSH CLI), ansible.netcommon.netconf (NETCONF/830), or ansible.netcommon.httpapi (REST/RESTCONF), and ansible_network_os: cisco.ios.ios to select the platform parser and command set.

For network_cli, ansible_user/ansible_password authenticate the SSH session and become: true with become_method: enable (optionally ansible_become_password) elevates to privileged EXEC so configuration tasks can run.

Inventory groups let group_vars/<group>.yml set shared connection variables while host_vars/<host>.yml overrides per device; this keeps credentials and ansible_network_os out of playbooks and scoped correctly.

The httpapi connection plugin (with ansible_httpapi_use_ssl: true and ansible_httpapi_port: 443) is used for RESTCONF and controller APIs such as Cisco Catalyst Center, where modules exchange JSON over HTTPS rather than screen-scraping CLI.

ansible-vault encrypt protects a var file with AES256 so credentials stay ciphertext in Git; ansible-vault encrypt_string embeds a single encrypted value inline in an otherwise plaintext vars file for selective secrecy.

The decryption key is provided at run time via --ask-vault-pass or --vault-password-file, and --vault-id label@source supports multiple vaults; the plaintext secret never lives on disk or in source control.

Committing the vault password (or a symmetric key) alongside the encrypted file gives no real protection because anyone with repo access can decrypt; the key must come from an out-of-band source or a secrets manager at runtime.

Trap Encrypting the vars file but committing the vault password file next to it is a common secret-management anti-pattern.

An idempotent task reports changed only when it actually altered device state; re-running a fully converged playbook against the same devices yields ok with changed=0, which is the signal that the desired state already matches.

Running a playbook with --check (check mode) has resource modules compute and report the changes they would make without pushing anything, and --diff shows the exact config delta; together they give a safe dry-run before a real apply.

A role uses the standard tasks/ handlers/ templates/ vars/ defaults/ meta/ layout for reuse; a handler runs once at the end of the play and only when a task that notifys it reported changed, ideal for a single save or service reload.

Jinja2 templates plus loop/with_items render device-specific values (VLAN IDs, ACL entries, OSPF areas) from inventory variables, and when conditionals gate tasks so one playbook adapts across a heterogeneous fleet.

In Ansible, block groups tasks; rescue runs its tasks only if a task in the block fails (place restore/undo steps here); always runs regardless — together they give a change task automated rollback when a push or post-change verify fails, instead of leaving the device half-configured.

Trap Believing a failed task automatically rolls back prior changes without a rescue block.

failed_when defines a custom failure condition on a task (e.g. fail when command output contains 'Invalid'), and ignore_errors: true lets the play continue past a failure so a later cleanup or rescue can run — both control when the recovery path triggers.

Trap Confusing ignore_errors (continue past failure) with failed_when (redefine what counts as failure).

cisco.ios.ios_facts gathers device facts into ansible_net_* variables (ansible_net_model, ansible_net_serialnum, ansible_net_version, ansible_net_hostname) — the standard way to collect hardware/software inventory for an asset database; gather_subset tunes what is collected.

Trap Expecting a resource module's 'gathered' state to return hardware serial/model — it returns per-feature CONFIG, not asset inventory.

A RESTCONF GET with query content=nonconfig returns operational (read-only) state such as interface oper-status and counters, while content=config returns only configuration and omitting content returns both — how live device state is read without changing config.

Trap Assuming a plain RESTCONF GET on a data node returns only configuration data.

NETCONF returns configuration AND operational state, whereas returns configuration only from a named datastore — use to read operational/asset data such as counters or neighbor state.

Trap Using to read operational counters (it returns configuration only).

Python reads live device state by issuing ncclient get() RPCs or netmiko send_command show output, then parsing it into structured data with a Genie/pyATS parser or TextFSM for programmatic asset/state processing rather than screen-scraping raw text.

Trap Screen-scraping raw show output instead of parsing it into structured data.

Terraform's terraform.tfstate is the source of truth mapping HCL resources to real objects; a state file that is local to one runner is invisible to others, so a second engineer's run believes the resources do not exist and may recreate or destroy them.

Moving state to a remote backend (Amazon S3 with native use_lockfile locking, Google Cloud Storage, or HCP Terraform) shares one authoritative state and enables state locking so only one terraform apply can mutate state at a time, preventing concurrent destructive operations.

Trap terraform refresh or -var files are offered as the fix, but only a shared, locked remote backend addresses the concurrency root cause.

terraform apply -refresh-only (formerly terraform refresh) updates state to match the real world, but it cannot synthesize resources created under a different engineer's separate state file, so it does not solve shared-state or concurrency problems.

terraform import <resource_address> <id> brings an already-existing, unmanaged object under Terraform management by recording it in state; without import, Terraform would try to create a duplicate of a resource it does not know about.

terraform.tfstate persists every managed resource attribute — including passwords, tokens, and keys — in plaintext, so the state file must live in an encrypted, access-controlled remote backend and never be committed to Git; this secrecy concern is separate from state locking.

Trap Committing terraform.tfstate to the repo or assuming state locking also protects its confidentiality.

terraform init downloads the providers declared in required_providers and initializes the configured backend; it must run before plan/apply and again whenever providers, modules, or the backend change.

terraform plan computes an execution plan (the diff) and terraform apply executes it; saving the plan with -out=plan.tfplan and applying that file guarantees apply performs exactly the reviewed actions with no re-computation.

In plan output + creates, - destroys, ~ updates in place, and -/+ replaces (destroy then create) a resource; a -/+ on a networking resource signals a disruptive recreation, often driven by a change to an immutable attribute.

terraform destroy removes all resources tracked in state, while -target=<address> scopes a plan/apply/destroy to a single resource or module; -target is a surgical escape hatch, not a routine workflow.

The terraform { required_providers { iosxe = { source = "CiscoDevNet/iosxe", version = "..." } } } block declares each plugin's registry source and a version constraint; a matching provider "iosxe" block then sets url, username, password, and insecure.

The CiscoDevNet/iosxe Terraform provider configures Catalyst/IOS-XE devices by driving their model-driven API — NETCONF over SSH by default, or RESTCONF when you set protocol = "restconf" — exposing resources such as iosxe_vlan, iosxe_interface_ethernet, and iosxe_ospf whose attributes map to native YANG leaves.

Cisco maintains Terraform providers including iosxe, nxos, aci, sdwan, and catalystcenter, so the same HCL/state/plan workflow spans device-level and controller-level automation across product lines.

Each Cisco provider resource's arguments correspond to leaves in the device's YANG model (for example an iosxe_vlan resource's vlan_id and name), so Terraform effectively becomes a declarative front end over model-driven configuration.

HCL is declarative: you describe the desired end state of resources and Terraform's core computes the create/update/destroy actions to reach it, in contrast to an imperative script where you code each step and ordering yourself.

Configuration drift occurs when real infrastructure diverges from state (e.g., a manual out-of-band CLI change); terraform plan refreshes and surfaces that drift as a diff, and a subsequent apply re-converges the device to the HCL-defined state.

Input variables, locals, and outputs parameterize a configuration; reusable modules package it; and count/for_each iterate a resource across a set (e.g., one iosxe_vlan per entry in a VLAN map) for DRY, scalable definitions.

The lifecycle block tunes resource replacement: prevent_destroy blocks accidental deletion, create_before_destroy avoids an outage during replacement, and ignore_changes tells Terraform to disregard drift on specific attributes.

git merge <branch> fast-forwards (just advances the pointer, no merge commit) when the current branch is a direct ancestor of the target; otherwise it performs a three-way merge that creates a merge commit with two parents. git merge --no-ff forces a merge commit even when a fast-forward is possible.

Trap Claiming a fast-forward merge always records a merge commit.

A merge conflict writes both versions into the file delimited by <<<<<<< HEAD (current branch), ======= (separator), and >>>>>>> <branch> (incoming); the engineer edits to the desired content, deletes all markers, git adds the file, then git commit to finish the merge.

Trap Believing the middle section between ======= and >>>>>>> is your own branch's version.

git merge --abort restores the working tree and index to the exact state that existed before the merge began, safely discarding a conflicted, in-progress merge without needing a manual reset.

Trap Assuming git reset --hard is the only way to cancel a conflicted merge.

While a merge is conflicted, git status lists the files under "Unmerged paths" (both modified); the merge is not complete and cannot be committed until every conflicted path is resolved and staged with git add.

During a conflict, git checkout --ours <file> keeps the current branch's version and git checkout --theirs <file> keeps the incoming branch's version, resolving that file wholesale (useful for generated or binary files) before staging it.

Trap Thinking --ours refers to the branch being merged in rather than the current branch.

git merge --squash <branch> applies the branch's combined changes to the working tree and stages them but does NOT create a merge commit or record the source branch as a parent; the engineer then makes a single ordinary git commit.

Trap Expecting --squash to create the commit automatically.

git reset --soft HEAD~3 moves the branch tip back three commits while keeping all their changes staged, so one git commit collapses them into a single commit; done on a local, unpushed feature branch this does not rewrite shared history.

Trap Thinking reset --soft discards the changes from the collapsed commits.

git rebase -i HEAD~3 opens an editor listing the commits; changing pick to squash (s) merges a commit into the prior one and lets you edit the combined message, while fixup (f) merges but discards the squashed commit's message.

Trap Swapping the roles: believing fixup keeps the message and squash drops it.

Squashing rewrites commit SHAs, so squashing commits that were already pushed and shared requires a force push and diverges collaborators' history; squash only local commits that have not been pushed.

Trap Assuming squashing already-pushed commits is safe without a force push.

git cherry-pick <commit> creates a NEW commit on the current branch that reproduces the changes introduced by the named commit, with a new SHA; the original commit stays where it is (it is copied, not moved).

Trap Thinking cherry-pick moves the commit off its original branch.

git cherry-pick -n (--no-commit) applies the picked commit's changes to the working tree and index but stops before committing, allowing several picks to be combined into one commit.

git cherry-pick A..B picks the commits after A up to and including B — commit A itself is excluded; use A^..B to also include A.

Trap Assuming A..B includes commit A.

On a conflict, cherry-pick pauses; resolve the files, git add them, then run git cherry-pick --continue (or --abort to cancel entirely, --skip to drop the current commit).

git cherry-pick -x appends a "(cherry picked from commit )" line to the new commit message, recording where the change came from — common when backporting a fix to a release branch.

git reset --soft <ref> moves HEAD (and the current branch) to but leaves the index and working tree untouched, so the changes from the undone commits remain staged and ready to re-commit.

Trap Believing --soft discards working-tree changes.

git reset --mixed <ref> — the default when no mode is given — moves HEAD and resets the index to match but leaves the working tree alone, so the changes become unstaged (modified) but are not lost.

Trap Thinking the default reset deletes files from the working tree.

git reset --hard <ref> moves HEAD and forcibly overwrites BOTH the index and the working tree to match , permanently discarding uncommitted changes and the work in the reset-away commits.

Trap Assuming --hard keeps the removed commits' changes staged like --soft.

git reset <file> (i.e. git reset HEAD <file>) unstages that file — the inverse of git add — without changing its working-tree content and without moving HEAD.

Commits orphaned by a reset remain reachable through git reflog until garbage collection; running git reset --hard <sha-from-reflog> restores the branch to a mistakenly-reset commit.

Trap Believing reset --hard is immediately and permanently unrecoverable.

git checkout <branch> updates HEAD, the index, and the working tree to the branch tip; git checkout -b <new> creates a new branch and switches to it in one command.

git checkout -- <file> discards uncommitted working-tree changes to that file by restoring it from the index/HEAD (the modern equivalent is git restore <file>); it overwrites local edits, it does not stage them.

Trap Thinking checkout of a file path stages the file for commit.

git checkout <commit-sha> (a commit, not a branch) puts the repo in DETACHED HEAD state; new commits made there belong to no branch and become unreachable once you switch away unless you first create a branch to hold them.

Trap Assuming commits made in detached HEAD stay attached to the previously checked-out branch.

Modern Git separates checkout's overloaded behavior: git switch <branch> (with -c to create) changes branches and git restore <file> restores file contents, removing the ambiguity of a single overloaded command.

git revert <commit> creates a NEW commit that applies the inverse of the named commit's changes, undoing its effect while preserving history — making it the safe way to undo a commit that has already been pushed and pulled by others.

Trap Thinking revert deletes or rewrites the original commit.

git reset rewrites history and is unsafe once commits are pushed, whereas git revert is additive and non-destructive; on a shared branch you undo a bad commit with revert, not reset.

Trap Recommending reset as the safe way to undo an already-pushed commit.

Reverting a merge commit requires -m <parent-number> (e.g. git revert -m 1 <merge-sha>) to name which parent is the mainline, because a merge has two parents and Git cannot infer which side to preserve.

Trap Assuming a merge commit can be reverted without specifying a mainline parent.

git revert -n <commit> stages the inverse changes without creating the commit, letting several reverts be combined into a single commit.

git rebase <base> replays the current branch's commits one at a time on top of , producing a linear history with NEW SHAs, versus git merge which preserves branch topology by adding a merge commit.

Trap Believing rebase preserves the original commit SHAs.

Never rebase commits that have been pushed and that others may have based work on: rebasing rewrites SHAs, forcing every collaborator to reconcile diverged history. Rebase only local, unshared commits.

Trap Claiming rebasing a shared branch is fine as long as you force-push.

On a rebase conflict Git pauses at the offending commit; resolve, git add, then git rebase --continue. git rebase --abort returns to the pre-rebase state and --skip drops the current commit.

git pull --rebase fetches the upstream and rebases local commits on top of it instead of creating a merge commit, keeping a feature branch's history linear when syncing with the remote.

HEAD~n follows the first parent n generations back, while HEAD^ is the first parent and HEAD^2 the SECOND parent of a merge; thus HEAD~2 equals HEAD^^ but is not the same as HEAD^2.

Trap Treating HEAD~2 and HEAD^2 as equivalent.

git reflog records every movement of HEAD — commits, resets, checkouts, rebases, merges — and is the primary recovery tool for finding "lost" commits after a bad reset or rebase.

git branch -d <b> refuses to delete a branch that is not merged into the current HEAD (guarding against losing work), whereas git branch -D <b> force-deletes regardless of merge state.

Trap Thinking lowercase -d force-deletes an unmerged branch.

git stash saves uncommitted tracked changes and resets the working tree to HEAD; git stash pop reapplies and drops the most recent stash — used to switch branches without committing work in progress.

A job that fails with "command not found" or Python's "ModuleNotFoundError: No module named ..." indicates a missing dependency: the runner image or before_script never installed the required package (e.g. pip install -r requirements.txt).

Trap Reading 'command not found' as a YAML syntax error rather than a missing tool.

If a later job depends on files produced by an earlier job, the producing job must declare them under artifacts:paths:; otherwise the consuming job fails because the artifact was never uploaded and transferred between stages.

Trap Assuming files produced in one job persist to the next without an artifacts declaration.

cache speeds up repeated jobs by reusing files (pip/npm dirs) but is best-effort and not guaranteed to be present between jobs; runtime dependencies must be installed or passed as artifacts, never relied on from cache.

Trap Treating cache as a reliable way to pass dependencies between stages.

Choosing a minimal base image: (e.g. python:3.12-slim, alpine) that lacks tools like git, gcc, or openssh causes "not found" failures; fix by selecting a fuller image or installing the tool in before_script.

An unpinned dependency (e.g. ansible with no version) lets a job pull a newer, incompatible release that breaks the pipeline; pinning exact versions in requirements.txt (ansible==9.2.0) makes builds reproducible.

Trap Assuming an unpinned dependency always resolves to the last-known-good version.

A job failing on syntax or library APIs can stem from the runner image's language runtime differing from what the code targets (e.g. match statements requiring 3.10+ run on a python:3.8 image); align the image: tag to the required runtime.

A pipeline that passed before and now fails with new errors despite no code change usually means a transitively-updated tool shipped a breaking change; reproduce with the committed lockfile and read the tool's changelog to confirm.

A committed lockfile (requirements.txt with hashes, poetry.lock, Pipfile.lock) pins the entire transitive dependency graph so CI installs exactly the versions that were tested, eliminating drift between runs.

A GitLab CI job is marked failed when a command in its script: returns a non-zero exit code; a failing pytest, pyats, or ansible-lint step exits non-zero, halting that stage and blocking every later stage.

Trap Believing a job only fails if the runner itself crashes, not when a test exits non-zero.

The job log echoes each command and its output in order; the first non-zero exit and the traceback just above "ERROR: Job failed" localize the fault. Read top-down to the first error, not just the last line.

Trap Assuming the final log line is always the root cause of the failure.

allow_failure: true lets a job fail without failing the pipeline (it shows as a warning); when it is absent or false, a failed test blocks the pipeline. Use it to distinguish advisory checks from blocking gates.

Trap Thinking allow_failure hides the job from the pipeline rather than merely down-grading its failure to a warning.

Each line in script: runs so that the job stops at the first command returning non-zero; a failure early in script: means the later lines never executed, which the log makes visible by their absence.

In dial-in (dynamic) MDT the collector/client initiates the gRPC session to the device and creates a subscription that lives only for the duration of that session; when the client disconnects the subscription is torn down.

Trap Assuming the device (not the collector) initiates a dial-in session.

In dial-out (configured) MDT the subscription is statically configured on the device (via CLI or NETCONF) and the DEVICE initiates the connection to the receiver; it persists across sessions and reloads.

Trap Thinking the collector initiates the connection in dial-out mode.

In Cisco IOS-XE MDT the axes are coupled: dynamic subscriptions are always dial-in and non-persistent, configured subscriptions are always dial-out and persistent; 'dial-out dynamic' is not a valid combination.

Trap Choosing a 'dial-out dynamic' subscription, which does not exist.

A configured (dial-out) subscription is identified by an operator-assigned subscription-id in the device config; a dynamic (dial-in) subscription receives a server-assigned id at session establishment.

gNMI (gRPC Network Management Interface) runs over gRPC, which uses HTTP/2 as its transport, and TLS secures the channel; a gNMI Subscribe RPC carries the telemetry stream.

Trap Believing gNMI runs over plain TCP or SNMP.

Native gRPC dial-out streams telemetry from the device to a gRPC receiver whose address and port are named in the configured subscription's receiver/destination-group.

MDT can also be carried over NETCONF using RFC 8639/8641 YANG-Push notifications on the NETCONF-over-SSH transport for dial-in subscriptions, not only over gRPC.

Trap Believing MDT requires gRPC exclusively.

Model-driven telemetry replaces SNMP polling: it streams YANG-modeled data and does not use SNMP traps or MIB OIDs for encoding or transport.

Trap Selecting SNMPv3 encoding or MIB OIDs as an MDT component.

A periodic subscription streams the sensor-path data every configured period; on IOS-XE the period is expressed in centiseconds (period 3000 = 30 seconds), regardless of whether the value changed.

Trap Reading the IOS-XE period value as seconds instead of centiseconds.

An on-change subscription sends an update only when a value in the subscribed path changes, minimizing bandwidth for state that is mostly stable (e.g. interface admin/oper status).

Trap Assuming on-change streams continuously like periodic.

A sensor-path is the YANG XPath identifying the data to stream (e.g. Cisco-IOS-XE-interfaces-oper:interfaces/interface/statistics); it defines exactly which nodes the subscription publishes.

RFC 8641 (YANG-Push) defines datastore subscriptions with periodic and on-change semantics; RFC 8639 defines the underlying dynamic and configured subscription mechanism.

gRPC dial-out MDT commonly encodes data as KVGPB (key-value Google Protocol Buffers) for compactness, while gNMI and other transports can use JSON or JSON_IETF; the subscription names the encoding.

Trap Assuming MDT only ever uses JSON encoding.

Compact GPB needs the matching .proto file to decode because it omits field keys, whereas self-describing GPB (KVGPB) embeds keys so a generic collector can decode without the .proto.

Trap Treating compact GPB and KVGPB as interchangeable at the collector.

A common MDT collection pipeline is the TIG stack: Telegraf (the cisco_telemetry_mdt input plugin decodes the stream) -> InfluxDB (time-series store) -> Grafana (visualization).

Syslog severity ranges 0 (Emergency) to 7 (Debug); on Cisco devices 'logging trap ' sends messages at that severity AND more severe (lower number) to the syslog server.

Trap Thinking a higher severity number is more severe.

Syslog facility codes (0-23, e.g. local0-local7 = 16-23) categorize the source; the wire PRI value is computed as facility*8 + severity per RFC 5424.

An RFC 5424 syslog message has a structured header (PRI, VERSION, TIMESTAMP, HOSTNAME, APP-NAME, PROCID, MSGID) plus optional STRUCTURED-DATA and MSG, improving parseability over the legacy RFC 3164 BSD format.

Trap Confusing the legacy RFC 3164 BSD format with RFC 5424.

Syslog defaults to UDP/514 (fire-and-forget, lossy); TCP/6514 with TLS (RFC 5425) provides reliable, encrypted delivery for an automation logging strategy.

Trap Assuming syslog is reliable/TCP by default.

A webhook destination is an HTTPS endpoint that receives an event via an HTTP POST carrying a JSON body; in Python the automation emits it with requests.post(url, json=payload).

Trap Assuming a webhook is delivered by HTTP GET.

Webhook receivers authenticate the sender with a shared secret in a header (e.g. an HMAC signature like X-Hub-Signature) or a bearer token so a forged POST can be rejected.

Because a webhook POST can fail (receiver down, HTTP 5xx), a robust logging strategy retries with backoff and treats a non-2xx response as a failure rather than silently dropping the event.

Trap Fire-and-forget POST with no retry or status check.

Webhooks push structured JSON to application endpoints (ChatOps/incident tools such as Webex or a ticketing API); syslog streams line-oriented text to a syslog collector, so the destination is chosen per downstream consumer.

Structured (JSON) logs emit each event as a machine-parsable object with named fields (timestamp, level, event, device, correlation_id), enabling reliable filtering and aggregation instead of regex-scraping free text.

In Python, structured JSON logging is achieved by attaching a JSON formatter (e.g. python-json-logger) to a logging handler so each LogRecord serializes to one JSON line.

Attaching a correlation/trace id to every log line of a single automation run lets you trace one workflow across multiple devices and services when diagnosing an event later.

Python logging levels are DEBUG(10) < INFO(20) < WARNING(30) < ERROR(40) < CRITICAL(50); a logger emits records at or above its configured effective level and drops the rest.

Handlers route LogRecords to destinations: SysLogHandler (syslog), HTTPHandler (webhook), StreamHandler (stdout), FileHandler (file); attaching several handlers to one logger fans the same record to all of them.

Using the logging module (not print) gives per-level filtering, structured output, and multiple simultaneous destinations, whereas print writes only unlabeled text to stdout.

A logging strategy must never emit secrets (tokens, passwords, private keys); redact or mask sensitive fields (e.g. the Authorization header) before the record is written to any destination.

Trap Logging full request headers including Authorization/bearer tokens.

AI coding assistants speed up drafting of repetitive automation code such as Ansible tasks, Python REST clients, and Jinja2 templates, reducing time-to-first-draft for common patterns.

A benefit is helping engineers discover unfamiliar SDK/API usage (for example Catalyst Center or RESTCONF payload shapes) and explain existing unfamiliar code, lowering the learning curve.

The benefit is bounded: an AI assistant is a drafting aid, not an authoritative source, so its output still requires review and testing before it can be trusted for network changes.

When prompted with team standards, an assistant can scaffold consistent error handling, retries, and logging across a codebase, improving maintainability.

Pasting configurations, topology, or proprietary code into a cloud LLM transmits that data to a third party that may log or train on it unless a zero-retention or enterprise no-train agreement forbids it.

Trap Assuming TLS to the API endpoint makes the prompt private; encryption in transit does not prevent server-side retention or training.

Secrets inside code that is pasted into a prompt (API keys, device passwords, SNMP community strings) are disclosed to the provider; scrub or externalize secrets before sending code to an assistant.

Running a self-hosted or on-prem model keeps prompts and code inside the organization, mitigating egress risk, at the cost of model capability and maintenance overhead.

Sending prompts to a cloud LLM can breach data-residency or compliance boundaries when regulated data leaves its permitted jurisdiction.

AI-generated code can reproduce snippets resembling its training data, risking license contamination (for example copyleft/GPL code) inside a proprietary codebase.

Ownership and copyright of purely AI-generated code is legally unsettled, so organizations must set policy on whether such output may be committed and how it is attributed.

The mitigation is to license-scan and review AI-suggested code before merge, treating it like any third-party dependency rather than trusted first-party code.

Feeding proprietary code into an external model for training or fine-tuning can leak that intellectual property into other tenants' outputs.

LLMs invent plausible-looking but non-existent SDK methods, module names, or CLI/YANG paths, so generated code must be validated against real API and module documentation.

Trap Assuming code that imports and runs is correct; it may still call the wrong device semantics or a fabricated attribute.

Human review of AI-generated automation is mandatory before it touches devices, and the engineer, not the model, remains accountable for the resulting change.

AI assistants frequently produce insecure defaults such as disabled TLS verification, hardcoded credentials, or overly broad permissions, which must be caught during code validation.

A model's training cutoff means it may suggest deprecated or removed modules and APIs (for example a removed Ansible module), so the currency of suggestions must be verified.

Direct prompt injection is user-supplied input crafted to override the system prompt or guardrails, making the LLM ignore its instructions or exfiltrate data; it is OWASP LLM01:2025 Prompt Injection.

Indirect prompt injection embeds adversarial instructions in external content the agent retrieves (a wiki page, RFC, ticket, or device banner) that the model then obeys; editable ingested sources are the canonical attack surface.

Trap Sanitizing only the user's chat input while trusting retrieved documents, which is exactly where indirect injection lives.

Injection cannot be eliminated by prompt wording alone; mitigations are treating model output as untrusted, least-privilege tool scoping, segregating untrusted content, and human approval for high-impact actions.

In a network automation agent, a successful injection can induce a harmful config push or cause the agent to reveal secrets through a tool call, turning a chat exploit into a device action.

OWASP LLM02:2025 Sensitive Information Disclosure covers the model revealing secrets, PII, topology, or proprietary data through its outputs.

Feeding live configuration or network state to a third-party LLM is a disclosure vector; scope the data, redact secrets, and prefer enterprise no-train endpoints to reduce exposure.

Data included in prompts or fine-tuning can be memorized by a shared model and surfaced to other users, so regulated data should not be fed to shared models.

OWASP LLM07:2025 System Prompt Leakage warns that the system prompt can be extracted, so credentials and secrets must never be placed in it.

OWASP LLM06:2025 Excessive Agency is the risk that an agent with over-broad tools, permissions, or autonomy takes damaging actions from a flawed or manipulated decision.

The mitigation is least-privilege tool design: read-only tools where possible, narrowly typed parameters, and per-action authorization for state-changing operations.

Trap Granting the agent full administrative access so it can 'handle anything', which maximizes rather than contains excessive agency.

State-changing, high-impact tools such as config push or device reload should require explicit human approval rather than autonomous execution by the agent.

Limiting blast radius with lab/CML targets, change windows, and RBAC-scoped service accounts contains the impact of an over-agentic or manipulated action.

OWASP LLM10:2025 Unbounded Consumption covers an agent loop that invokes tools or the model without bounds, exhausting compute or running up cost (denial-of-wallet); mitigations are step/loop caps, rate limiting, and per-run budget limits.

Trap Naming only prompt injection as the agent-loop risk and missing the resource-exhaustion / denial-of-wallet category.

OWASP LLM05:2025 Improper Output Handling is passing LLM output unvalidated into downstream systems (shell, eval, device CLI, SQL), enabling injection or remote code execution.

Raw model output must never be eval'd, exec'd, or piped into a shell or device; it must be validated, parameterized, and constrained before use.

Trap Trusting model output because it came from your own agent rather than an external user.

Constraining tool inputs and outputs to strict schemas and command allow-lists prevents malformed or malicious model output from reaching devices.

OWASP LLM03:2025 Supply Chain covers risks from untrusted models, plugins, datasets, or dependencies, including compromised model weights and malicious MCP servers or tools.

OWASP LLM04:2025 Data and Model Poisoning is tampering with training, fine-tuning, or RAG data to bias or backdoor the model's outputs.

A malicious or compromised MCP server or tool can exfiltrate data or execute harmful actions, so the tools an agent may load must be vetted and pinned.

Poisoned RAG sources feed both indirect prompt injection and misinformation, so write access to the agent's knowledge base must be controlled.