Cisco DCAUTO 300-635 common mistakes
Cisco DCAUTO 300-635 · Understand the traps and how to avoid them.
When asked to identify the correct HTTP method and payload for creating a tenant in ACI, candidates choose POST to /api/mo/uni/tn-<name>.json without including the required attributes, or they use PUT when the object does not yet exist, causing a 400 error.
Candidates confuse the REST semantics of ACI: POST creates a new MO under a parent, PUT updates an existing MO or creates it if the DN is fully specified. They also forget that the payload must wrap the object in a top-level key matching the class name (e.g., fvTenant).
What to do instead
Memorize the ACI REST API conventions: POST to a parent DN with a JSON body containing the class name as the key; PUT to the full DN of the object to create or replace. Practice with the ACI simulator or sandbox to see the exact error responses when the payload is malformed.
In Ansible playbooks for NX-OS, candidates use the wrong connection type (e.g., network_cli for HTTP API tasks) or forget to set ansible_network_os, leading to connection failures or timeouts.
They do not distinguish between connection plugins: network_cli for CLI over SSH, httpapi for NX-API REST, and local for legacy provider-based modules. They also overlook that httpapi requires ansible_network_os: nxos and proper authentication settings.
What to do instead
Review the Ansible network connection options and practice writing playbooks with both network_cli and httpapi. Use ansible-doc for the nxos modules to see the required connection type and parameters. Test against a lab device or the NX-OSv sandbox.
When configuring a Terraform provider for ACI, candidates hardcode credentials in the .tf file or use the wrong provider source (e.g., cisco/aci instead of the correct registry path), and they fail to use variables or environment variables for sensitive data.
They are unfamiliar with the Terraform ACI provider's authentication methods (username/password, private key, or token) and the recommended practice of using input variables and environment variables (e.g., ACI_USERNAME, ACI_PASSWORD). They also may not know the correct provider name and version constraints.
What to do instead
Study the official Terraform ACI provider documentation to learn the provider block syntax and authentication options. Practice creating a variables.tf file and using TF_VAR_ environment variables. Always run terraform init to verify provider installation.
Candidates confuse the roles of Cisco Nexus Dashboard and Nexus Dashboard Orchestrator (NDO) when asked about multi-site policy management, stating that Nexus Dashboard itself provides cross-site network policy orchestration.
They conflate the Nexus Dashboard platform (which provides a single pane of glass for operations, insights, and automation) with NDO, which is a separate application hosted on Nexus Dashboard that handles multi-site ACI and NX-OS policy orchestration.
What to do instead
Clearly separate the functions: Nexus Dashboard is the infrastructure platform for managing on-prem and cloud networks, while NDO is the multi-site orchestration application. Review Cisco documentation on Nexus Dashboard and NDO to understand their distinct roles and how they integrate.
When writing a Python script using the ACI Cobra SDK, candidates use the wrong class names or forget to call .commit() on the configuration object, resulting in no changes being pushed to APIC.
They do not understand that Cobra SDK requires building a configuration tree with specific MO classes (e.g., cobra.model.fv.Tenant) and then committing the root object. They may also miss that the commit is asynchronous and needs to be checked for errors.
What to do instead
Practice with the Cobra SDK examples: create a tenant, add a private network, and commit. Always check the commit response for errors. Use the APIC GUI or REST API to verify the configuration was applied. Refer to the Cobra SDK documentation for class hierarchy.
In CI/CD pipelines for network automation, candidates place credentials directly in pipeline scripts or repository files, or they use long-lived static credentials instead of integrating with a secrets manager.
They focus on functionality and overlook security best practices. They may not be aware of tools like HashiCorp Vault, AWS Secrets Manager, or pipeline-native secret storage (e.g., GitHub Actions secrets, GitLab CI variables).
What to do instead
Learn to use environment variables and secret management tools in CI/CD. For example, in GitLab CI, define masked variables; in Jenkins, use credentials binding. Always reference secrets via variables in playbooks and Terraform, never hardcode.
When asked about the NX-API CLI vs NX-API REST, candidates incorrectly state that NX-API CLI uses JSON-RPC and NX-API REST uses XML only, or they confuse the endpoints (e.g., /ins for CLI, /api/mo for REST).
They have not studied the NX-API architecture in detail. NX-API CLI accepts CLI commands via JSON or XML over HTTP/HTTPS and returns structured output; NX-API REST uses RESTful URLs with JSON payloads to manage objects. The endpoints are distinct: /ins for CLI and /api for REST.
What to do instead
Review the Cisco NX-API documentation and practice with both interfaces on a Nexus switch or simulator. Use curl or Postman to send requests and observe the differences in request/response formats and endpoints.
In Ansible, candidates use the wrong module for a task, such as using nxos_command to make configuration changes instead of nxos_config, or using nxos_config for operational state gathering.
They do not understand the distinction between modules: nxos_command is for executing show commands and returns raw output, while nxos_config is for pushing configuration changes and supports idempotency and diff. Using the wrong module can lead to unintended changes or failures.
What to do instead
Study the Ansible NX-OS module documentation to learn each module's purpose. Practice using nxos_command for show commands and nxos_config for configuration. Use the --check mode to test playbooks without making changes.
When describing the ACI policy model, candidates mix up the hierarchy levels (e.g., tenant, application profile, EPG, bridge domain) and their relationships, such as stating that an EPG directly contains a bridge domain.
They have not internalized the ACI object model. In ACI, an EPG is associated with a bridge domain via a domain binding, but the bridge domain is a separate object under the tenant, not contained within the EPG. Similarly, application profiles contain EPGs, not the other way around.
What to do instead
Draw the ACI policy model hierarchy from memory: Tenant > Application Profile > EPG; Tenant > Bridge Domain; Tenant > VRF. Use the APIC GUI to explore the relationships. Practice with the ACI simulator to create objects and see their DNs.
In Terraform, candidates use the count or for_each meta-arguments incorrectly, leading to resource duplication or errors when iterating over maps or lists, especially when the collection changes.
They do not understand the difference between count (index-based) and for_each (key-based) and how Terraform tracks state. Using count with a list that changes order can cause resources to be recreated unexpectedly.
What to do instead
Learn the best practices for loops in Terraform: use for_each with maps or sets of strings for stable resource addressing. Practice with simple examples and use terraform plan to see the effects of changes. Refer to Terraform documentation on meta-arguments.