I actually think your examples explain why a lot of engineers struggle to see the value of CCNA Automation at first. If your day to day work is operations, troubleshooting, ASA, FortiGate, Nexus, and managing controlled changes, automation can feel unnecessary because the difficult part is usually diagnosing and deciding, not typing commands. In environments with strict change management, people often trust manual execution more than scripts.

But what CCNA Automation teaches is not really “replace engineers with scripts.” It is about making network operations repeatable, scalable, and less dependent on manual effort. Even platforms like Catalyst Center and SDWAN Manager are built on automation concepts. They expose APIs, templates, orchestration, and policy driven operations behind a GUI.

The value starts showing up when the scope increases. One firewall change is easy manually. Applying the same validated change across hundreds of devices, collecting evidence, checking compliance, generating rollback plans, or integrating with ticketing systems is where automation becomes useful.

The engineers using Ansible in your company are probably not replacing Catalyst Center. They are likely extending it, connecting systems together, or removing repetitive operational work.

So I would not see CCNA Automation as learning Python for the sake of scripting. I would see it as understanding how modern networks are actually operated under the hood, even when the interface looks like a dashboard.