350-901 AUTOCOR — Cisco Automation Core Specialist

Full question text, answer options, and explanations for this practice set — a spoiler-free alternative is the interactive quiz above for scored, shuffled practice.

1. 1. A network automation engineer inherits a Python script that both generates device configuration and pushes it to devices within a single function. The team wants to add support for a new device platform without duplicating logic. Which design change best supports this goal?

   • A. Separate the script into a config-generation layer (platform-specific templates) and a shared execution/push layer connected through a clear interface, so a new platform only requires a new template(correct)
   • B. Copy the entire function and hand-edit the copy for the new platform
   • C. Add a large if/elif chain inside the same function for each platform's logic
   • D. Hard-code the new platform's values directly into the existing function body

   Explanation: Separating configuration generation (which varies by platform) from execution (which can be shared) is a core software design practice that lets new platforms be added via a new template rather than duplicated code. Copying the function (B) reintroduces duplication and a growing maintenance burden. An if/elif chain (C) keeps all platform logic tightly coupled and grows harder to test as platforms are added. Hard-coding new values into existing logic (D) risks breaking the current platform's behavior and does not scale.

2. 2. An engineer wants to propose a change to a shared Ansible playbook repository so a teammate can review the diff before it becomes part of the main branch. Which Git workflow accomplishes this?

   • A. Create a feature branch, commit the change there, push it, and open a pull/merge request for review before merging into main(correct)
   • B. Commit directly to main and tell the team afterward
   • C. Delete main and replace it with the local working copy
   • D. Email a zipped copy of the changed files to the team lead

   Explanation: Creating a feature branch, pushing it, and opening a pull/merge request is the standard collaborative Git workflow for review before merge. Committing directly to main (B) bypasses review. Deleting main (C) destroys shared history. Emailing zipped files (D) discards Git's actual collaboration/merge tooling and commit history.

3. 3. A CI/CD pipeline's integration test stage fails intermittently only when multiple pipeline runs execute concurrently against a shared lab environment, and passes reliably when run alone. What is the most likely root cause and the appropriate fix?

   • A. Concurrent runs are mutating shared lab device state simultaneously (a race condition); serialize access via locking/queuing or provision isolated per-run environments(correct)
   • B. The lab hardware is simply unreliable and must be replaced before further troubleshooting
   • C. Remove the integration test stage since it cannot be trusted
   • D. Increase the pipeline's overall timeout value

   Explanation: Intermittent failures correlated specifically with concurrent execution against shared, stateful infrastructure are a classic signature of race conditions from simultaneous state mutation; serializing access or isolating environments per run is the correct fix. Assuming hardware unreliability (B) ignores the concurrency correlation. Removing the stage (C) discards real test coverage instead of fixing the cause. Increasing the timeout (D) does not address a race condition at all.

4. 4. Profiling shows that 90% of an automation script's runtime is spent waiting on sequential, synchronous HTTP calls to device APIs, with negligible time in local processing. Which change is most directly justified by this data?

   • A. Introduce concurrency (async I/O or a thread/process pool) so multiple independent device API calls run in parallel instead of sequentially(correct)
   • B. Rewrite the local data-processing logic in a faster language
   • C. Add more local caching of computed results
   • D. Reduce the number of fields requested from the API response

   Explanation: When profiling shows the overwhelming majority of time is I/O wait rather than computation, introducing concurrency to overlap independent API calls directly targets the measured bottleneck. Optimizing local processing (B) or caching (C) do not address I/O wait time. Trimming response fields (D) targets parsing overhead, not the measured wait-on-I/O bottleneck.

5. 5. A merge into a shared inventory file produces unexpected conflicts because an engineer did not pull the latest main before merging. What is the best immediate response consistent with good Git practice?

   • A. Review the conflicting sections, understand both sets of intended changes, resolve them, then commit and verify the merged file before pushing(correct)
   • B. Force-push the engineer's branch over main to discard the other changes
   • C. Delete the inventory file so nothing conflicts
   • D. Push the file with the raw conflict markers still present

   Explanation: Correctly resolving a merge conflict means reviewing both sets of changes, resolving them deliberately, and verifying correctness before pushing. Force-pushing over main (B) destroys a teammate's work. Deleting the file (C) removes needed content instead of resolving the conflict. Pushing unresolved conflict markers (D) leaves the file broken and can break downstream automation.

6. 6. A team is designing a CI/CD pipeline that validates network automation changes before they reach production devices. Which stage ordering best minimizes risk to production?

   • A. Lint/static analysis -> unit tests -> deploy to staging/lab with integration tests -> approval gate -> deploy to production with rollback capability(correct)
   • B. Deploy to production first, then run unit tests to confirm correctness
   • C. Skip staging entirely and rely on production monitoring alerts to catch issues
   • D. Run lint checks only and treat a clean result as sufficient to deploy to production

   Explanation: Progressive validation — static analysis, unit tests, staging integration tests, an approval gate, then production deployment with rollback capability — minimizes risk by catching issues before they reach production. Deploying first (B) inverts the risk model. Relying only on post-deployment monitoring (C) is reactive. Lint alone (D) cannot catch functional/runtime issues.

7. 7. An engineer is building a Python REST API that other teams will use to request network configuration changes programmatically. Which design choice best supports safe, predictable consumption of this API by infrastructure-as-code clients?

   • A. Define clear, versioned request/response schemas (e.g., FastAPI with Pydantic models) so breaking changes are only introduced in new API versions(correct)
   • B. Accept any arbitrary JSON payload without validation and apply whatever fields are present directly to the device
   • C. Change the response format frequently without versioning to reflect the latest internal data model
   • D. Require consumers to submit raw vendor-specific CLI strings with no schema validation

   Explanation: Clear, validated, versioned schemas keep request/response contracts predictable and isolate breaking changes to new versions. Accepting unvalidated arbitrary JSON (B) is unsafe. Changing response formats without versioning (C) breaks existing consumers unpredictably. Requiring raw CLI strings (D) reintroduces the fragility structured APIs are meant to eliminate.

8. 8. An engineer is building a Python CLI tool for operators to run tasks like 'deploy-config' and 'backup-config'. Which Python approach best structures commands, options, and help text?

   • A. Use a CLI framework such as Click or argparse to define subcommands, arguments, and options with built-in help text generation(correct)
   • B. Parse sys.argv manually with ad hoc string splitting and no help text
   • C. Require users to edit the source code each time they want to change which task runs
   • D. Support only a single hardcoded command with no arguments

   Explanation: CLI frameworks like Click or argparse provide structured subcommand definitions, argument parsing, validation, and auto-generated help text. Manual sys.argv parsing (B) is fragile with poor discoverability. Editing source code to change behavior (C) is not a usable CLI. A single hardcoded command (D) fails the requirement of multiple distinct tasks.

9. 9. A team needs to reuse the same set of Ansible tasks (NTP, DNS, logging) across many playbooks for different device groups. Which Ansible construct is designed to package and reuse this kind of content?

   • A. An Ansible role, which bundles tasks, handlers, variables, templates, and defaults into a reusable unit that can be included in multiple playbooks(correct)
   • B. A single ad hoc 'ansible' command run manually for each device
   • C. A Python virtual environment, which has no concept of Ansible tasks
   • D. A Git commit message that Ansible parses at runtime to generate tasks

   Explanation: Ansible roles package related tasks, handlers, variables, defaults, and templates into a reusable structure multiple playbooks can include. Manual ad hoc commands (B) do not scale. A Python virtual environment (C) manages package dependencies, unrelated to Ansible task reuse. Git commit messages (D) are not parsed by Ansible to generate tasks.

10. 10. An engineer uses Terraform to provision resources across dev, staging, and production. The team wants to avoid accidentally applying a dev-sized change to production. Which practice best addresses this risk?

    • A. Use separate Terraform state files/workspaces per environment, and require manual review of 'terraform plan' before 'terraform apply' against production(correct)
    • B. Store all environments in a single shared state file so one apply updates all of them
    • C. Never run 'terraform plan' before 'terraform apply' to save time
    • D. Manually edit the state file whenever a discrepancy with production is noticed

    Explanation: Separating state per environment and reviewing 'terraform plan' before applying to production prevents an operation intended for one environment from affecting another. A single shared state file (B) is exactly the described risk. Skipping 'terraform plan' (C) removes Terraform's primary safety check. Manually editing state (D) is discouraged and can corrupt state or cause drift.

11. 11. A Python script consumes a vendor REST API that occasionally returns HTTP 429 (Too Many Requests) under high load. Which approach best handles this in a production-grade script?

    • A. Implement retry logic with exponential backoff, respecting any 'Retry-After' header, bounded by a maximum retry count(correct)
    • B. Crash immediately with an unhandled exception on any non-200 response
    • C. Retry in a tight loop with no delay until it succeeds
    • D. Silently ignore the 429 and proceed as if it succeeded

    Explanation: Bounded retry with exponential backoff (respecting 'Retry-After') handles transient rate-limiting gracefully without hanging indefinitely. Crashing on any non-200 (B) is brittle for a recoverable condition. A tight no-delay retry loop (C) worsens rate-limiting. Silently proceeding (D) hides a real failure and risks inconsistent state.

12. 12. A team maintains an Ansible role that configures NTP. Branch, campus, and data center device groups require different NTP server IPs but identical task logic. Which approach correctly leverages Ansible's variable precedence model?

    • A. Define default NTP values in 'defaults/main.yml' and override per group using group_vars/host_vars, sharing the same role tasks(correct)
    • B. Create a fully duplicated copy of the role for each device group
    • C. Hard-code all three groups' IP addresses in nested Python if-statements inside the task file
    • D. Store NTP addresses only in 'vars_prompt' so an operator types them in every run

    Explanation: Role defaults provide the lowest-precedence fallback, and group_vars/host_vars override per group, letting one shared task set serve multiple groups. Duplicating the role (B) violates DRY and creates a maintenance burden. Hard-coded if-statements (C) are not idiomatic Ansible and bypass the variable system. Manual entry via 'vars_prompt' (D) reintroduces error-prone manual steps.

13. 13. An engineer writes a Python script using an SDK to call Cisco device APIs for configuration and monitoring. Which practice best reflects good scripting technique for this automation?

    • A. Use structured functions with clear parameters, handle SDK/API exceptions explicitly, and log meaningful context (device, operation, result) per call(correct)
    • B. Write all API calls inline with no exception handling so any error immediately terminates the run with a generic traceback
    • C. Avoid logging entirely to keep output minimal
    • D. Hard-code an expected successful API response so the script never needs to actually call the API

    Explanation: Structured functions with explicit exception handling and meaningful logging support troubleshooting across many devices. Unstructured code with no exception handling (B) fails ungracefully. Avoiding logging (C) removes needed visibility. Hard-coding a fake response (D) means the script performs no real automation.

14. 14. An engineer must push a validated interface configuration to a fleet of IOS XE devices in an automated pipeline, using a model-driven and structured approach rather than raw CLI screen-scraping. Which approach is most appropriate?

    • A. Use NETCONF/RESTCONF with YANG-modeled data to submit structured configuration rather than sending raw CLI text and parsing terminal output(correct)
    • B. Telnet into each device manually and type commands by hand
    • C. Screen-scrape 'show running-config' output with regex as the sole source of truth for changes
    • D. Disable all management interfaces except the console port before automating

    Explanation: NETCONF/RESTCONF with YANG models is the preferred structured, model-driven configuration approach on IOS XE. Manual Telnet (B) is not automation. Screen-scraping CLI text with regex (C) is fragile because output formatting can change between software versions. Disabling management interfaces except console (D) prevents API-based automation entirely.

15. 15. A team uses pyATS for regression testing after configuration changes and wants to add a check that a routing protocol neighbor is 'Established' after a change, failing clearly if not. Which approach reflects good pyATS test enhancement practice?

    • A. Parse the relevant 'show' output via a Genie parser into structured data, assert the neighbor state equals 'Established', and raise a clear failure with the observed state if not(correct)
    • B. Print the raw CLI output with no assertion and consider the test successful as long as it does not crash
    • C. Replace existing steps with a single sleep() call, assuming the neighbor eventually comes up
    • D. Hard-code the result to always pass to avoid false failures

    Explanation: Parsing into structured data and asserting the expected state with a descriptive failure message gives actionable diagnostic detail. Printing raw output with no assertion (B) validates nothing. An unconditional sleep() (C) removes validation entirely. Hard-coding a pass (D) defeats the purpose of automated testing.

16. 16. A monitoring team wants continuous, near-real-time interface counter updates from a fleet of Cisco devices without repeatedly polling with 'show' commands. Which approach fits YANG model-driven telemetry?

    • A. Configure model-driven telemetry (e.g., gNMI dial-out subscription) so the device streams structured YANG-modeled updates as state changes(correct)
    • B. Issue a new SSH CLI 'show interface' command in a tight loop with no delay
    • C. Use SNMP polling exclusively, since YANG telemetry is not a distinct approach
    • D. Manually check the local logging buffer once per day

    Explanation: Model-driven telemetry lets a device proactively stream structured state changes, far more efficient and timely than polling. Tight-loop CLI polling (B) is resource-intensive and does not scale. YANG telemetry is a real, distinct approach (C's premise is false). Once-daily manual checks (D) do not provide near-real-time visibility.

17. 17. A pyATS test intermittently fails a VLAN presence check right after a config push, because the VLAN sometimes takes a few seconds to appear. Which test enhancement addresses this without weakening the validation?

    • A. Implement a bounded retry/poll loop that checks for the VLAN's presence for a limited period before failing(correct)
    • B. Remove the VLAN presence check entirely
    • C. Add a fixed 10-minute sleep before every step in the entire suite
    • D. Pass the test whenever the push reports success, without checking device state

    Explanation: A bounded retry/poll loop waits only as long as necessary and still fails decisively within the allowed window, preserving validation integrity. Removing the check (B) eliminates coverage. A blanket long sleep (C) slows the whole suite unnecessarily. Trusting the push result alone (D) removes the value of independently verifying device state.

18. 18. A Python automation script's NETCONF <edit-config> against an IOS XE device fails validation, though the identical XML payload succeeded on a different device of the same model. Which diagnostic step is most likely to reveal the root cause?

    • A. Compare the YANG capabilities and supported/deviated YANG modules on both devices via the <hello> exchange, since differing software versions or licenses can produce different supported models(correct)
    • B. Abandon NETCONF and switch to CLI screen-scraping without further investigation
    • C. Assume NETCONF ignores device-specific capabilities entirely
    • D. Reboot the failing device repeatedly until the payload happens to succeed

    Explanation: Comparing advertised NETCONF capabilities and YANG module support is the most direct way to identify why an identical payload is accepted on one device but not another. Switching to CLI screen-scraping (B) avoids diagnosing the root cause. Assuming NETCONF ignores capabilities (C) is factually wrong. Repeated reboots (D) are not a diagnostic step.

19. 19. An automation engineer's Python script must authenticate to a Cisco platform's REST API using an API key. Which practice for handling that key is most consistent with secure coding principles?

    • A. Retrieve the key at runtime from a dedicated secret management system, or at minimum an environment variable not committed to source control(correct)
    • B. Hard-code the key as a string literal and commit the script to a shared repository
    • C. Post the key in a team chat channel so anyone can copy it
    • D. Store the key in a plaintext file in the repository root without adding it to .gitignore

    Explanation: Retrieving secrets at runtime from a secret manager or environment variable never committed to source control limits exposure and allows rotation without code changes. Hard-coding and committing (B) permanently exposes the secret in history. Posting in chat (C) broadly exposes it. A plaintext file without .gitignore (D) risks the same accidental commit exposure.

20. 20. A code review flags a script that constructs a shell command string using unsanitized operator-entered hostnames and passes it to a shell for execution. Which OWASP-aligned practice addresses this vulnerability?

    • A. Avoid passing unsanitized input to a shell; validate input against an expected format or use parameterized/argument-list execution APIs that do not invoke a shell(correct)
    • B. Trust all operator-entered input by default since operators are authorized users
    • C. Increase the length limit on the hostname field
    • D. Log the constructed shell command after execution

    Explanation: This is a command injection risk; validating input and using argument-list execution APIs (avoiding shell interpretation) is the correct mitigation. Trusting all internal input (B) ignores that operators can still introduce risky content. Increasing length limits (C) does nothing to prevent injection. Logging after execution (D) does not prevent the injection from occurring.

21. 21. An engineer is designing a REST API that network automation clients use to submit configuration change requests. Which combination of controls reflects REST API security best practice?

    • A. Require authentication (OAuth2 tokens or mutual TLS), enforce server-side authorization scoping, use TLS in transit, and validate all input server-side(correct)
    • B. Allow anonymous, unauthenticated access to all endpoints to simplify integration
    • C. Serve the API only over unencrypted HTTP to reduce TLS overhead
    • D. Perform authorization checks only in client-side code

    Explanation: Strong authentication, server-side authorization, TLS, and server-side validation together are required for an API that can trigger configuration changes. Anonymous access (B) lets any party trigger changes. Unencrypted HTTP (C) exposes credentials and data. Client-side-only authorization (D) is bypassable and insecure.

22. 22. An automation platform stores database credentials, API tokens, and TLS keys used by various jobs. The team wants to move away from plaintext configuration files on the automation server. Which capability should a proper secret management system provide?

    • A. Centralized, access-controlled, encrypted storage with the ability to audit access and rotate credentials without changing consuming code(correct)
    • B. A shared spreadsheet listing all secrets in plaintext for team convenience
    • C. Encryption once at initial setup with no rotation or audit mechanism afterward
    • D. Embedding all secrets as string literals in job source code

    Explanation: Centralized encrypted storage with audit logging and rotation without code changes directly addresses the plaintext-storage risk. A plaintext spreadsheet (B) provides no encryption or meaningful access control. One-time encryption with no rotation (C) fails ongoing credential lifecycle management. Embedding secrets in source code (D) reintroduces the exact anti-pattern being avoided.

23. 23. A security review finds that any authenticated user, regardless of role, can call an API endpoint that pushes configuration to any device in inventory, including devices outside their assigned scope. Which OWASP-aligned principle is violated, and what is the remediation?

    • A. Broken access control; implement server-side authorization checks restricting each user to their assigned devices/actions, not just verifying login(correct)
    • B. This is expected and acceptable behavior since authentication alone guarantees correct access control
    • C. Remove authentication entirely since it caused the gap
    • D. Encrypt the API traffic with TLS, which alone is sufficient to prevent out-of-scope actions

    Explanation: This describes broken access control, conflating authentication with authorization; the fix is server-side authorization checks enforcing each user's permitted scope on every request. Treating it as acceptable (B) ignores a real gap. Removing authentication (C) makes it worse. TLS (D) protects data in transit but does not enforce what an authenticated user is permitted to do.

24. 24. A Python automation script inserts a user-supplied device description field directly into a configuration template. Applying OWASP secure coding guidance, what is the primary concern?

    • A. Unsanitized text could break out of the intended field or inject unintended content, so it should be validated/escaped against an expected format before use(correct)
    • B. There is no concern because templates cannot be affected by text field content
    • C. The only concern is the description exceeding terminal display width
    • D. The concern only applies to numeric fields, never free-text fields

    Explanation: Unsanitized input embedded in a structured payload is a potential injection risk; validating or escaping it against an expected format before use is the correct mitigation. Claiming no concern (B) ignores a documented injection risk class. Framing it as a display issue (C) understates the actual configuration-integrity risk. Limiting concern to numeric fields (D) is incorrect — free-text fields are a more common injection vector.

25. 25. A network automation pipeline retrieves a device credential from a secret management system immediately before a config push, then discards it from memory rather than caching it to disk for reuse. What security benefit does this provide?

    • A. It minimizes the window of exposure and number of places a live credential exists at rest, reducing risk if the pipeline host is later compromised(correct)
    • B. No security benefit — caching to disk is always equally secure
    • C. It guarantees the pipeline can never be compromised
    • D. It is purely a performance optimization unrelated to credential exposure

    Explanation: Just-in-time retrieval with immediate discard reduces the attack surface and the exposure window for a reusable credential. Dismissing this as no benefit (B) misunderstands a core secret management principle. No single practice guarantees a pipeline can never be compromised (C). Framing this purely as performance (D) ignores its direct relationship to credential exposure risk.