350-901 AUTOCOR — Cisco Certified Internetwork Expert (CCIE) Automation

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. An automation engineer is designing a new network automation solution that will be maintained by a distributed team over several years. Cisco's CCIE Automation certification specifically calls out proficiency in software solution design as a foundational skill. Which practice best reflects sound software solution design for a long-lived automation codebase?

   • A. Decompose the solution into well-defined modules with clear interfaces (e.g., separate inventory, task execution, and reporting layers) so components can be tested, replaced, and scaled independently(correct)
   • B. Write all automation logic in a single monolithic script with no functions or modules, so there is only one file for engineers to review
   • C. Hard-code device credentials and IP addresses directly into the automation scripts so no external inventory or secrets system is required
   • D. Avoid version control entirely so that only the current working copy of the code exists on the automation server

   Explanation: Sound software solution design favors decomposing a system into modules with clear responsibilities and interfaces (such as separate inventory, execution, and reporting layers), which improves testability, maintainability, and the ability to evolve or scale individual components independently. A single monolithic script (option B) becomes difficult to test, extend, or hand off to other engineers. Hard-coding credentials (option C) is both a design anti-pattern and a security risk — credentials should be externalized to a secrets management system. Avoiding version control (option D) removes the ability to track changes, roll back, or collaborate safely, which directly contradicts the Git usage skill this certification calls out.

2. 2. A team of network automation engineers is collaborating on a shared Git repository containing Ansible playbooks. An engineer wants to propose a change to a playbook without directly modifying the main branch, so the change can be reviewed before merging. Which Git workflow accomplishes this?

   • A. Create a feature branch, commit the change to that branch, push it, and open a pull/merge request for review before merging into main(correct)
   • B. Commit directly to the main branch and notify the team afterward via chat
   • C. Delete the main branch and replace it with the engineer's local copy
   • D. Use 'git clone --force' to overwrite the remote repository with the local working directory

   Explanation: The standard collaborative Git workflow for proposing reviewable changes is to create a feature branch, commit work there, push it to the remote, and open a pull/merge request so teammates can review the diff before it is merged into the main branch. Committing directly to main (option B) bypasses review and risks introducing untested changes to the shared branch. Deleting the main branch (option C) destroys the team's shared history and is destructive. There is no 'git clone --force' command that overwrites a remote repository with a local directory (option D) — this describes an invalid/nonexistent operation.

3. 3. A CI/CD pipeline that deploys network configuration changes begins failing intermittently at the 'lint and unit test' stage, but only on the shared runner pool — not when engineers run the same tests locally. Which troubleshooting approach best isolates the root cause?

   • A. Immediately disable the lint and unit test stage so deployments can continue while the issue is ignored
   • B. Compare the pipeline runner's environment (tool/dependency versions, environment variables, available resources, and concurrency with other jobs) against the local development environment to identify environment drift or resource contention as the differentiator(correct)
   • C. Assume the test suite itself is non-deterministic and delete the failing tests from the repository
   • D. Rewrite the entire pipeline configuration from scratch without first reviewing the pipeline logs

   Explanation: When a failure reproduces only on shared CI/CD infrastructure and not locally, the most effective troubleshooting approach is to compare the two environments — dependency/tool versions, environment variables, filesystem state, and resource contention from concurrent jobs on a shared runner pool are common causes of environment-specific failures. Disabling the stage (option A) hides the problem rather than fixing it and removes a quality gate. Deleting failing tests (option C) removes valid signal without understanding the cause and can mask a real defect. Rewriting the pipeline without first reviewing logs (option D) skips the diagnostic step that would actually reveal the root cause.

4. 4. An automation solution that pushes configuration to hundreds of devices via a REST API has recently become noticeably slower. The engineer suspects a performance issue rather than a network outage. Which technique is most appropriate for diagnosing the source of the slowdown?

   • A. Profile the application code and instrument key operations (e.g., API call latency, serialization time, per-device processing time) to identify which stage of the pipeline is consuming the most time(correct)
   • B. Increase the number of concurrent threads without measurement, on the assumption that more concurrency always resolves performance issues
   • C. Restart the automation server and consider the issue resolved if it does not immediately recur
   • D. Ignore the slowdown since REST API calls are inherently variable in latency and cannot be measured

   Explanation: Diagnosing a performance regression requires measurement: profiling the code and instrumenting discrete stages (API latency, serialization, per-device processing) reveals exactly where time is being spent, which is the prerequisite for any effective fix. Blindly increasing concurrency (option B) can worsen contention (e.g., against API rate limits) if the bottleneck isn't actually concurrency-bound. Restarting the server (option C) may mask a transient symptom without addressing the underlying cause, and the issue is likely to recur. REST API latency is measurable and diagnosable with proper instrumentation and logging (option D is a false premise).

5. 5. A new automation engineer merges a feature branch into main without first pulling the latest changes from main, resulting in a merge commit with unexpected conflicts in a shared inventory file. What is the best immediate response consistent with good Git practice?

   • A. Carefully review the conflicting sections in the merge, resolve them by understanding both sets of intended changes, then commit the resolution and verify the merged file is correct before pushing(correct)
   • B. Force-push the engineer's original branch over main to discard the other team's conflicting changes
   • C. Delete the inventory file entirely so there is nothing left to conflict
   • D. Ignore the conflict markers and push the file as-is, including the unresolved '<<<<<<<' and '>>>>>>>' markers

   Explanation: The correct response to a merge conflict is to review both sets of changes, understand their intent, manually resolve the conflicting sections, and verify correctness before committing and pushing the resolution. Force-pushing over main to discard a teammate's work (option B) destroys their contributions and is a destructive, disruptive action in a shared repository. Deleting the file (option C) removes needed content rather than resolving the conflict. Pushing unresolved conflict markers (option D) leaves the file syntactically broken and will break any downstream automation that consumes it.

6. 6. A team is designing a CI/CD pipeline for network automation that must validate configuration changes before they reach production devices. Which pipeline stage ordering best reflects a sound deployment design that minimizes risk to production?

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

   Explanation: A sound CI/CD design for network automation validates changes progressively — static analysis and unit tests catch basic errors early and cheaply, staging/lab integration tests validate real device behavior in a safe environment, an approval gate adds human or policy oversight before production impact, and production deployment should retain rollback capability in case of unexpected issues. Deploying to production before testing (option B) inverts the risk model and exposes production to unvalidated changes. Relying solely on post-deployment monitoring (option C) is reactive, not preventative. Lint checks alone (option D) cannot catch functional or runtime issues that only integration testing would reveal.

7. 7. A network automation engineer is developing a Python REST API that will allow other teams to request network configuration changes programmatically. Which design choice best supports safe, predictable infrastructure-as-code consumption of this API?

   • A. Define clear, versioned request/response schemas (e.g., using a framework like FastAPI with Pydantic models) so consumers get consistent, validated input/output structures and breaking changes are introduced only in new API versions(correct)
   • B. Accept any arbitrary JSON payload without validation, and apply whatever fields are present directly to device configuration
   • C. Change the response format of the API frequently without versioning so that it always reflects the latest internal data model
   • D. Require consumers to submit raw, vendor-specific CLI commands as unstructured strings with no schema validation

   Explanation: For infrastructure-as-code consumers to reliably build automation against an API, the API should expose clear, validated, versioned schemas so that request/response contracts are predictable and breaking changes are isolated to new versions. Accepting arbitrary unvalidated JSON and applying it directly to devices (option B) is unsafe and can push malformed or malicious configuration. Changing response formats without versioning (option C) breaks every existing consumer unpredictably. Accepting unstructured, vendor-specific CLI strings with no schema (option D) defeats the purpose of a structured API and reintroduces the fragility that infrastructure-as-code APIs are meant to eliminate.

8. 8. An engineer is building a Python CLI application to help network operators run common automation tasks (e.g., 'deploy-config', 'backup-config') from a terminal. Which Python approach is best suited for structuring commands, options, and help text for this CLI application?

   • 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, requiring users to memorize exact argument order
   • C. Require users to edit the Python source code directly each time they want to change which task runs
   • D. Only support a single hardcoded command with no arguments or options at all

   Explanation: CLI frameworks such as Click or Python's built-in argparse are the standard approach for building maintainable command-line applications — they provide structured subcommand definitions, argument/option parsing, validation, and automatically generated help text, all of which improve usability and reduce bugs. Manually parsing sys.argv with ad hoc string splitting (option B) is fragile and provides a poor user experience with no discoverability. Requiring users to edit source code to change behavior (option C) is not a usable CLI design. Supporting only a single hardcoded command (option D) does not meet the stated requirement of running multiple distinct automation tasks.

9. 9. A network automation team needs to reuse the same set of Ansible tasks (e.g., configuring NTP, DNS, and logging) across many different playbooks for different device groups. Which Ansible construct is designed specifically to package and reuse this kind of related task, variable, and template content?

   • A. An Ansible role, which bundles tasks, handlers, variables, templates, and default values into a reusable, self-contained unit that can be included in multiple playbooks(correct)
   • B. A single ad hoc 'ansible' command run manually on each device, repeated by hand for every playbook
   • C. A Python virtual environment, which manages package dependencies but has no concept of Ansible tasks or templates
   • D. A Git commit message describing the desired configuration, which Ansible parses at runtime to generate tasks

   Explanation: Ansible roles are the standard mechanism for packaging reusable, related automation content — tasks, handlers, variables, defaults, and Jinja2 templates — into a self-contained structure that multiple playbooks can include, promoting reuse and consistency across device groups. Manually repeating ad hoc commands (option B) does not scale and reintroduces the toil automation is meant to eliminate. A Python virtual environment (option C) manages Python package dependencies and has no relationship to Ansible's task/role reuse model. Git commit messages (option D) are not parsed by Ansible to generate configuration tasks; this describes a nonexistent mechanism.

10. 10. An engineer is using Terraform to orchestrate the provisioning of network infrastructure resources across multiple environments (dev, staging, production). The team wants to avoid accidentally applying a dev-sized configuration change to production. Which Terraform practice best addresses this risk?

    • A. Use separate Terraform state files (and typically separate workspaces or directories) per environment, and require a manual review of the 'terraform plan' output before running 'terraform apply' against production state(correct)
    • B. Store all environments in a single shared state file with no separation, so a single 'terraform apply' updates dev, staging, and production simultaneously
    • C. Never run 'terraform plan' before 'terraform apply', to save time during deployments
    • D. Manually edit the Terraform state file by hand whenever a discrepancy with production is noticed

    Explanation: Separating Terraform state per environment (via distinct state files, workspaces, or directory structures) prevents an operation intended for one environment from inadvertently affecting another, and reviewing the 'terraform plan' output before 'terraform apply' against production state is a critical safety gate to catch unintended changes before they are applied. A single shared state file across all environments (option B) is precisely the risk described in the scenario and would make it easy to accidentally impact production. Skipping 'terraform plan' (option C) removes the primary safety check Terraform provides. Manually hand-editing the state file (option D) is explicitly discouraged by Terraform's own documentation because it can corrupt state and cause drift between the state file and real infrastructure.

11. 11. A Python script needs to consume a vendor's REST API that occasionally returns HTTP 429 (Too Many Requests) responses during periods of high load. Which approach best handles this condition in a production-grade infrastructure-as-code script?

    • A. Implement retry logic with exponential backoff that inspects the response status code (and any 'Retry-After' header) and waits an increasing amount of time between retry attempts before giving up after a bounded number of tries(correct)
    • B. Immediately crash the script with an unhandled exception whenever any non-200 response is received
    • C. Retry the request in a tight loop with no delay between attempts until it succeeds
    • D. Silently ignore the 429 response and proceed as though the request succeeded

    Explanation: Robust API consumption in infrastructure-as-code scripts should implement retry logic with exponential backoff (and respect any 'Retry-After' header provided by the server), bounded by a maximum retry count, which handles transient rate-limiting gracefully while avoiding indefinite hangs. Crashing on any non-200 response (option B) provides a poor and brittle user experience for a recoverable condition. Retrying in a tight loop with no delay (option C) worsens the rate-limiting condition and can make the problem worse for the API provider and other consumers. Silently proceeding as if the request succeeded (option D) hides a real failure and risks leaving infrastructure in an inconsistent, unverified state.

12. 12. A team maintains an Ansible role that configures NTP servers on network devices. Different device groups (branch, campus, data center) require different NTP server IP addresses, but the underlying tasks are identical. Which approach correctly leverages Ansible's variable precedence model to support this without duplicating the role's task logic?

    • A. Define default NTP server values in the role's 'defaults/main.yml', and override them per device group using group_vars (or host_vars) so each group receives its own values while sharing the same role tasks(correct)
    • B. Create a separate, fully duplicated copy of the role for each device group, changing only the NTP server IP address in each copy
    • C. Hard-code all three device groups' NTP server IP addresses directly into the task file using nested if-statements written in raw Python
    • D. Store NTP server addresses only in the playbook's 'vars_prompt' so an operator must manually type them in during every single playbook run

    Explanation: Ansible's variable precedence model is specifically designed to support this pattern: role defaults (in 'defaults/main.yml') provide the lowest-precedence fallback values, and group_vars or host_vars can override those defaults per device group, allowing one shared set of role tasks to be reused with group-specific values. Duplicating the entire role per group (option B) violates the DRY principle and creates a maintenance burden every time the shared task logic needs to change. Hard-coding values with raw Python if-statements inside a task file (option C) is not idiomatic Ansible and bypasses the variable system entirely. Requiring manual entry via 'vars_prompt' on every run (option D) defeats the purpose of automation by reintroducing manual, error-prone human input for a value that is already known ahead of time.

13. 13. An engineer is writing a Python script that uses an SDK to call Cisco device APIs for automated configuration and monitoring tasks. Which practice best reflects good Python scripting technique for API automation against Cisco platforms?

    • A. Use structured functions with clear parameters, handle exceptions raised by the SDK/API client explicitly, and log meaningful context (device, operation, and result) for each API call(correct)
    • B. Write all API calls inline in a single unstructured script with no exception handling, so that any error immediately terminates the entire automation run with a generic traceback
    • C. Avoid logging entirely so that API call details are never recorded, in order to keep script output minimal
    • D. Hard-code the exact response of a successful API call into the script so the script does not need to actually call the API

    Explanation: Well-structured Python automation for Cisco platform APIs uses clear functions with explicit parameters, handles exceptions from the SDK/API client so failures are caught and can be handled or retried, and logs meaningful context (which device, what operation, and the result) to support troubleshooting. An unstructured script with no exception handling (option B) fails ungracefully and provides poor diagnostic information when something goes wrong. Avoiding logging entirely (option C) removes the visibility needed to troubleshoot automation failures across many devices. Hard-coding an expected API response instead of actually calling the API (option D) means the script does not perform real automation at all — it does not reflect actual device state.

14. 14. An engineer needs to push a validated interface configuration to a fleet of Cisco IOS XE devices as part of an automated pipeline, and wants the operation to be model-driven and structured rather than relying on raw CLI screen-scraping. Which general approach is most appropriate?

    • A. Use a model-driven management interface (such as NETCONF/RESTCONF with YANG-modeled data) to submit structured configuration data to IOS XE, rather than sending raw CLI text and parsing terminal output(correct)
    • B. Telnet into each device manually and type the configuration commands by hand for every device in the fleet
    • C. Screen-scrape the CLI output of 'show running-config' with regular expressions and treat the parsed text as the sole source of truth for making configuration changes
    • D. Disable all management interfaces on the device except the console port before attempting automated configuration

    Explanation: IOS XE supports model-driven management via NETCONF/RESTCONF using structured YANG data models, which is the preferred, structured approach for automated configuration because it avoids the fragility of parsing free-form CLI text and provides well-defined, validated data structures for both configuration and telemetry. Manually telnetting into devices (option B) does not scale and is not automation at all. Screen-scraping CLI output with regex as the sole source of truth (option C) is fragile because CLI output formatting can change between software versions and is not designed to be machine-parsed. Disabling all management interfaces except the console port (option D) would prevent programmatic/API-based automation entirely, the opposite of what is needed.

15. 15. A team uses pyATS to run automated regression tests against network devices after configuration changes. They want to enhance an existing pyATS test script to also validate that a specific routing protocol neighbor relationship is 'Established' after the change, and fail the test clearly if it is not. Which approach best reflects good pyATS test enhancement practice?

    • A. Add a new test step that parses the relevant 'show' command output (e.g., via a pyATS/Genie parser) into structured data, asserts the neighbor state equals 'Established', and raises a clear, descriptive failure with the actual observed state if the assertion does not hold(correct)
    • B. Add a print statement that logs the raw CLI output, with no assertion, and consider the test successful as long as the script does not crash
    • C. Remove all existing test steps and replace them with a single sleep() call, assuming the neighbor will eventually come up given enough time
    • D. Hard-code the test result to always pass regardless of the actual neighbor state, to avoid false failures in the pipeline

    Explanation: Enhancing a pyATS test script correctly means adding a test step that parses relevant command output into structured data (pyATS/Genie parsers convert CLI output into structured Python objects), asserts the expected condition, and produces a clear, descriptive failure message including the actual observed state when the assertion fails — this gives engineers actionable diagnostic information. Merely printing raw output without an assertion (option B) does not actually validate anything; the test would report success even if the neighbor never came up. Replacing test logic with an unconditional sleep() (option C) removes validation entirely and does not verify convergence occurred. Hard-coding the result to always pass (option D) defeats the entire purpose of automated testing by hiding real failures.

16. 16. An engineer wants to receive continuous, near-real-time updates of interface counters from a fleet of Cisco devices without repeatedly polling with 'show' commands over CLI or NETCONF/RESTCONF. Which approach, consistent with YANG model-driven telemetry, is designed for this use case?

    • A. Configure model-driven telemetry (e.g., via gNMI or a dial-out subscription) so the device streams structured, YANG-modeled updates to a telemetry receiver as state changes, rather than the collector polling repeatedly(correct)
    • B. Write a script that issues a new SSH CLI 'show interface' command in a tight loop with no delay, as fast as possible, to approximate real-time updates
    • C. Use SNMP polling exclusively, since YANG-modeled telemetry is not a real, distinct approach to network monitoring
    • D. Manually check the device's local logging buffer once per day and record any observed counter values by hand

    Explanation: Model-driven telemetry (using protocols such as gNMI, with dial-in or dial-out subscription models) allows a device to proactively stream structured, YANG-modeled state and counter data to a receiver as it changes, which is far more efficient and timely than repeated polling. Repeatedly issuing CLI 'show' commands in a tight loop (option B) is a polling anti-pattern that is resource-intensive on both the device and the collector and does not scale to a fleet. YANG-modeled telemetry is a distinct, real, and increasingly standard approach to network monitoring that complements or replaces traditional SNMP polling (option C's premise is false). Manual, once-daily log checks (option D) do not provide near-real-time visibility and are not automation.

17. 17. An engineer's pyATS test suite intermittently fails a step that checks whether a newly configured VLAN appears in 'show vlan brief' output, even though the configuration push reports success. Investigation shows the VLAN sometimes takes a few seconds to appear after being applied. Which test enhancement best addresses this without weakening the validation itself?

    • A. Implement a bounded retry/poll loop (e.g., using pyATS utilities for polling with a timeout) that repeatedly checks for the VLAN's presence for a limited period before failing, rather than checking exactly once immediately after the push(correct)
    • B. Remove the VLAN presence check entirely from the test suite since it is unreliable
    • C. Add a fixed, very long unconditional sleep (e.g., 10 minutes) before every test step in the entire suite, regardless of what each step checks
    • D. Change the assertion so that it passes whenever the configuration push reports success, without independently verifying the VLAN actually appears in device state

    Explanation: The correct fix for a check that is racing against eventual consistency (the VLAN takes a few seconds to appear) is a bounded retry/poll loop with a timeout — this waits only as long as necessary and still fails decisively if the condition is never met within the allowed window, preserving the validation's integrity. Removing the check (option B) eliminates real test coverage rather than fixing the timing issue. A fixed, very long sleep applied to every step (option C) unnecessarily slows down the entire suite and does not correctly target only the step with the race condition. Trusting the push's reported success without independently verifying device state (option D) removes the actual value of the test, since the goal is precisely to confirm the device state matches intent, not just that the push command returned success.

18. 18. An engineer is troubleshooting why a Python automation script's NETCONF <edit-config> operation against an IOS XE device fails validation, even though the same XML payload was accepted on a different device of the same model. Which diagnostic step is most likely to reveal the root cause?

    • A. Compare the YANG capabilities (via <hello> exchange) and supported/deviated YANG modules on both devices, since differing IOS XE software versions or feature licenses can result in different supported YANG models or deviations(correct)
    • B. Assume NETCONF is unreliable and switch immediately to CLI screen-scraping without further investigation
    • C. Conclude the payload itself must always be identical in cause and effect across all devices, since NETCONF ignores device-specific capabilities entirely
    • D. Reboot the failing device repeatedly until the same payload happens to succeed

    Explanation: Because YANG module support (including vendor deviations) can differ between devices depending on software version, platform, or licensed features, comparing the two devices' advertised NETCONF <hello> capabilities and supported YANG modules is the most direct way to identify why an otherwise-identical payload is accepted on one device but rejected on another. Abandoning NETCONF for CLI screen-scraping (option B) avoids diagnosing the actual root cause and trades a structured interface for a fragile one. Assuming NETCONF ignores device capabilities (option C) is factually incorrect — NETCONF explicitly advertises capabilities precisely so clients can adapt to what a given device supports. Repeatedly rebooting the device (option D) is not a diagnostic step and is unlikely to resolve a capability mismatch.

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

    • A. Retrieve the API key at runtime from a dedicated secret management system (or, at minimum, an environment variable not committed to source control) rather than embedding it as a literal string in the script(correct)
    • B. Hard-code the API key directly as a string literal in the Python script and commit the script to a shared Git repository
    • C. Post the API key in a team chat channel so anyone on the team can copy it into their own local scripts
    • D. Store the API key in a plaintext file inside the repository's root directory alongside the source code, without adding it to .gitignore

    Explanation: Secure secret management requires retrieving sensitive credentials like API keys at runtime from a dedicated secret management system (such as a vault service) or, at minimum, from an environment variable that is never committed to source control — this limits exposure and allows credentials to be rotated without code changes. Hard-coding the key into the script and committing it to Git (option B) permanently exposes the secret in version history, even if later removed, and is a common real-world source of credential leaks. Posting the key in a chat channel (option C) broadly and permanently exposes it beyond those with a legitimate need. Storing it in a plaintext file in the repository without .gitignore protection (option D) risks the same accidental commit exposure as option B.

20. 20. A code review flags a Python automation script that constructs a shell command string using unsanitized user input (a device hostname entered by an operator) and passes it to a shell for execution. Which OWASP-aligned secure coding practice addresses the vulnerability this pattern introduces?

    • A. Avoid passing unsanitized, user-controlled input to a shell; instead validate/sanitize the input against an expected format (or use parameterized/argument-list execution APIs that do not invoke a shell) to prevent command injection(correct)
    • B. Trust all operator-entered input by default, since operators are assumed to be authorized users and therefore cannot introduce security issues
    • C. Increase the length limit on the hostname field so longer malicious payloads can also be entered without truncation
    • D. Log the constructed shell command after execution, which is sufficient to prevent the underlying vulnerability

    Explanation: This scenario describes a classic command injection vulnerability, which OWASP secure coding practices address by validating/sanitizing input against an expected format and, ideally, avoiding shell invocation altogether by using parameterized or argument-list execution APIs (which pass arguments directly to a program without shell interpretation of special characters). Trusting all operator input by default (option B) ignores that authorized users can still make mistakes or that input fields can be a vector for accidental or malicious injected content, and does not address the underlying vulnerability class. Increasing the input length limit (option C) does nothing to prevent injection and could make it easier to construct a larger malicious payload. Logging the command after execution (option D) is useful for auditing but does not prevent the injection from occurring in the first place.

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

    • A. Require authentication (e.g., OAuth2 tokens or mutual TLS) on every request, enforce authorization checks so a client can only act within its permitted scope, use TLS to encrypt traffic in transit, and validate all input server-side(correct)
    • B. Allow anonymous, unauthenticated access to all endpoints to simplify client integration
    • C. Serve the API only over unencrypted HTTP to reduce the performance overhead of TLS negotiation
    • D. Perform authorization checks only in client-side code, and trust that clients will not send requests outside their intended scope

    Explanation: REST API security best practice for an API that can trigger network configuration changes requires strong authentication (such as OAuth2 tokens or mutual TLS), server-side authorization enforcement so a client cannot exceed its permitted scope, transport encryption via TLS, and server-side input validation, since none of these controls can be safely assumed or skipped for an API with this level of impact. Allowing anonymous access (option B) would let any party trigger configuration changes, which is unacceptable for an API of this sensitivity. Serving the API over unencrypted HTTP (option C) exposes credentials and configuration data to interception. Performing authorization checks only client-side (option D) is fundamentally insecure because client-side code can be bypassed or modified by the caller; authorization must be enforced on the server.

22. 22. A network automation platform stores database credentials, API tokens, and TLS private keys used by various automation jobs. The team wants to move away from storing these secrets in plaintext configuration files on the automation server. Which capability should a proper secret management system provide to meaningfully improve this situation?

    • A. Centralized, access-controlled, encrypted storage of secrets with the ability to audit access and rotate credentials without requiring changes to the automation code that consumes them(correct)
    • B. A shared spreadsheet listing all secrets in plaintext, accessible to the entire automation team for convenience
    • C. Encrypting the secrets once at initial setup, with no mechanism to rotate or audit them afterward
    • D. Embedding all secrets as string literals in the automation job source code so they are always available without any external dependency

    Explanation: A proper secret management system provides centralized, encrypted, access-controlled storage for secrets, along with audit logging of access and the ability to rotate credentials without requiring every consuming automation job to be individually modified — this directly addresses the plaintext-storage risk described. A shared plaintext spreadsheet (option B) does not encrypt secrets, provides no meaningful access control beyond who can open the file, and has no audit trail — it is arguably worse than plaintext config files since it is even easier to share broadly. Encrypting secrets only once with no rotation or audit capability (option C) fails to address ongoing credential lifecycle management, which is a core purpose of secret management. Embedding secrets as literals in source code (option D) reintroduces the exact anti-pattern the team is trying to move away from and risks permanent exposure via version control history.

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

    • A. This violates the principle of enforcing proper authorization (broken access control); the API must implement server-side authorization checks that restrict each authenticated user to only the devices/actions within their assigned scope, not just verify that they are logged in(correct)
    • B. This is expected and acceptable behavior, since authentication alone is always sufficient to guarantee correct access control regardless of the resource being accessed
    • C. The fix is to remove authentication entirely, since requiring login is what caused the access control gap
    • D. The fix is to encrypt the API traffic with TLS, which is sufficient to prevent unauthorized users from performing actions outside their scope

    Explanation: This scenario describes broken access control — a well-known OWASP-aligned vulnerability category where authentication (proving who you are) is conflated with authorization (proving what you are allowed to do). The remediation is to implement server-side authorization checks that enforce each user's or role's permitted scope of devices/actions on every request, not merely check that a valid session/token exists. Treating this as expected/acceptable (option B) ignores a real security gap that would let any authenticated user affect devices outside their responsibility. Removing authentication entirely (option C) would make the problem far worse, not better, since it would remove even the identity check that currently exists. TLS encryption (option D) protects data in transit from eavesdropping but does nothing to enforce which actions an authenticated user is permitted to perform — it does not address authorization at all.

24. 24. An engineer is writing a Python automation script that reads a configuration template and inserts a user-supplied device description field into the final device configuration. Applying OWASP secure coding guidance, what is the primary concern with inserting unsanitized user-supplied text directly into a configuration payload?

    • A. The unsanitized text could contain characters or sequences that break out of the intended field, alter unrelated parts of the configuration, or inject unintended commands, so it should be validated/escaped against an expected format before use(correct)
    • B. There is no concern at all, because configuration templates cannot be affected by the content of a text field under any circumstances
    • C. The only concern is that the description might exceed the device's display width in a terminal window
    • D. The concern only applies to numeric fields, never to free-text description fields

    Explanation: OWASP secure coding guidance treats any unsanitized user-supplied input inserted into a structured payload (including configuration templates) as a potential injection risk — special characters or unexpected sequences in a 'description' field could break out of the intended field boundary and alter unrelated configuration, or in the worst case inject unintended commands, so validating or escaping the input against an expected format before use is the correct mitigation. Claiming there is no concern (option B) ignores a well-documented class of injection vulnerabilities that applies to templated configuration generation just as it does to other structured output. Framing the issue as merely a display/formatting concern (option C) understates the actual risk, which is about configuration integrity and potential injection, not cosmetics. Limiting the concern to numeric fields only (option D) is incorrect — free-text fields are, if anything, a more common vector for this class of issue because they are less constrained by format.

25. 25. A network automation pipeline calls a secret management system to retrieve a device credential immediately before pushing configuration, then discards the credential from memory after use, rather than caching it in a local file for reuse across multiple pipeline runs. Which security benefit does this pattern primarily provide?

    • A. It minimizes the window of exposure and the number of places a live credential exists at rest, reducing the risk that a compromised pipeline host or leftover file exposes a long-lived, reusable credential(correct)
    • B. It has no security benefit and only adds unnecessary latency to every pipeline run, since caching credentials to disk is always equally secure
    • C. It guarantees the pipeline can never be compromised, regardless of any other vulnerability in the automation code
    • D. It is primarily a performance optimization with no relationship to secret management or credential exposure at all

    Explanation: Retrieving a credential just-in-time and discarding it after use (rather than caching it to disk) reduces the attack surface — there are fewer locations and less time during which a live, reusable credential exists at rest, so if the pipeline host is later compromised or a leftover cache file is discovered, the exposure is limited compared to a long-lived cached credential. Dismissing this as having no security benefit (option B) misunderstands the core value of minimizing credential lifetime and exposure, which is a standard secret management principle. No single practice guarantees a pipeline can 'never' be compromised (option C) — defense-in-depth requires multiple layered controls, not a single silver bullet. Framing this purely as a performance concern (option D) ignores its direct and well-established relationship to reducing credential exposure risk.