How should I use these Scenario practice questions?

Read each scenario carefully and choose your answer before revealing the explanation. Then check why your choice was right or wrong. Repeat until the reasoning feels automatic.

Can I practise just Scenario questions in a focused session?

Yes — use the session launcher on this page to start a 10-, 20-, 30- or 50-question session drawn entirely from the Scenario domain.

200-901 · topic practice

Scenario practice questions

Practise Cisco DevNet Associate 200-901 Scenario practice questions — original exam-style scenarios with answer choices, explanations, and analysis of common mistakes.

Courseiva uses original exam-style practice questions designed for learning and revision. The goal is to understand the concepts, recognise exam patterns, and improve through explanations — not memorise copied exam dumps.

Editorial oversight:Johnson Ajibi· MSc IT Security, IEEE Senior Member

10 questionsDomain: Scenario

Practice 10 questions Browse domain →

What the exam tests

What to know about Scenario

Scenario questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Watch out for

Common Scenario exam traps

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Practice set

Scenario questions

10 questions · select your answer, then reveal the explanation

Question 1mediummulti select

Read the full REST/YANG explanation →

A developer is troubleshooting a Cisco RESTCONF API call that returns a 409 Conflict error. Which two scenarios could cause this? (Choose two.)

Trap 1: Authentication token is missing.

A missing authentication token yields 401 Unauthorized, not 409 Conflict. It is tempting because authentication failures are common RESTCONF issues, and it would be correct when credentials are absent or expired, but 409 signals a resource-state conflict such as a duplicate or concurrent edit.

Trap 2: The resource does not exist.

A missing resource yields 404 Not Found, because the URI path resolves to no existing target. It tempts because developers frequently hit absent paths when first testing RESTCONF, but that condition is reported as 404. A 409 Conflict instead signals a state clash, such as a duplicate create or a lock violation.

Trap 3: The request contains invalid data types.

Invalid data types produce a 400 Bad Request, since the server rejects malformed or wrongly typed payload values during schema validation. It tempts because YANG type mismatches are a common RESTCONF error, but they map to 400, not 409. A 409 arises from a state conflict, such as creating a resource that already exists.

Study all Scenario common traps →

A
Authentication token is missing.
Why it fails: A missing authentication token yields 401 Unauthorized, not 409 Conflict. It is tempting because authentication failures are common RESTCONF issues, and it would be correct when credentials are absent or expired, but 409 signals a resource-state conflict such as a duplicate or concurrent edit.
B
The resource's current state conflicts with the requested change (e.g., trying to delete a resource that is in use).
HTTP 409 means the request conflicts with the resource's current state. Attempting to delete a resource still in use, such as an object referenced by dependents, produces exactly this conflict because the server cannot reconcile the requested deletion with existing references.
C
The resource already exists and the request attempts to create a duplicate.
A 409 arises when the request contradicts existing server state. Issuing a create for a resource that already exists duplicates a unique key, so the server rejects it as a conflict rather than overwriting or silently succeeding.
D
The resource does not exist.
Why it fails: A missing resource yields 404 Not Found, because the URI path resolves to no existing target. It tempts because developers frequently hit absent paths when first testing RESTCONF, but that condition is reported as 404. A 409 Conflict instead signals a state clash, such as a duplicate create or a lock violation.
E
The request contains invalid data types.
Why it fails: Invalid data types produce a 400 Bad Request, since the server rejects malformed or wrongly typed payload values during schema validation. It tempts because YANG type mismatches are a common RESTCONF error, but they map to 400, not 409. A 409 arises from a state conflict, such as creating a resource that already exists.

Full breakdown with real-world context →

Question 2hardmulti select

Read the full Scenario explanation →

Which THREE are valid Kubernetes Service types? (Select three.)

Trap 1: Deployment

Deployment is a workload resource, not a Service type.

Trap 2: Ingress

Ingress is an API object that manages external access, not a Service type.

Study all Scenario common traps →

A
NodePort
Exposes service on each Node's IP at a static port.
B
Deployment
Why it fails: Deployment is a workload resource, not a Service type.
C
ClusterIP
Default type, exposes service on a cluster-internal IP.
D
LoadBalancer
Exposes service externally using a cloud provider's load balancer.
E
Ingress
Why it fails: Ingress is an API object that manages external access, not a Service type.

Full breakdown with real-world context →

Question 3mediummulti select

Read the full Scenario explanation →

A developer receives HTTP 409 Conflict when updating a network configuration via Cisco NX-OS API. Which two scenarios could cause this error?

Trap 1: The request body contains malformed JSON.

Malformed JSON produces HTTP 400 Bad Request, as the payload fails parsing before any state comparison occurs. It is tempting because both indicate a faulty client request, but 409 requires syntactically valid input that conflicts with the device's current configuration state.

Trap 2: The request includes unsupported parameters.

Unsupported parameters typically yield HTTP 400 Bad Request, since the API rejects malformed or unknown fields during schema validation. A 409 Conflict signals a state clash, such as editing an object whose configuration revision no longer matches. This option is tempting because parameter errors are common API faults, but they map to 400, not 409.

Trap 3: The API key used is invalid.

An invalid API key yields HTTP 401 Unauthorized, since authentication fails before the request reaches conflict detection. It is tempting because both are client-side errors, but 409 signals a state conflict such as a duplicate object or a concurrent modification.

Study all Scenario common traps →

A
The resource was recently modified by another client.
A concurrent write by another client triggers HTTP 409 Conflict because NX-OS detects a stale configuration revision, rejecting the update to prevent overwriting newer changes. This satisfies the stem's requirement for a scenario causing the conflict, since the resource's version no longer matches the client's submitted payload.
B
The update conflicts with a lock held by another transaction.
A concurrent transaction holds a configuration lock, so NX-OS rejects the write with HTTP 409 rather than queuing it. The API surfaces the conflict immediately because the candidate configuration cannot be modified while another session owns the lock, satisfying the stem's requirement for a scenario producing this status.
C
The request body contains malformed JSON.
Why it fails: Malformed JSON produces HTTP 400 Bad Request, as the payload fails parsing before any state comparison occurs. It is tempting because both indicate a faulty client request, but 409 requires syntactically valid input that conflicts with the device's current configuration state.
D
The request includes unsupported parameters.
Why it fails: Unsupported parameters typically yield HTTP 400 Bad Request, since the API rejects malformed or unknown fields during schema validation. A 409 Conflict signals a state clash, such as editing an object whose configuration revision no longer matches. This option is tempting because parameter errors are common API faults, but they map to 400, not 409.
E
The API key used is invalid.
Why it fails: An invalid API key yields HTTP 401 Unauthorized, since authentication fails before the request reaches conflict detection. It is tempting because both are client-side errors, but 409 signals a state conflict such as a duplicate object or a concurrent modification.

Full breakdown with real-world context →

Question 4mediummultiple choice

Read the full Scenario explanation →

Which OAuth 2.0 grant type is most appropriate for a server-to-server integration where no user interaction is required, such as a backend service calling Cisco API?

Trap 1: Authorization code grant

The authorization code grant requires a browser redirect and a user authenticating at the authorization server to obtain the code, which no backend service can supply. It is tempting because it is the recommended flow for web applications acting on behalf of a signed-in user.

Trap 2: Password grant

The password grant requires the resource owner's username and password to be sent to the token endpoint, and it presumes a user whose credentials exist; a backend service has no such user. It is tempting for legacy first-party clients that collect credentials directly, such as a vendor's own mobile app.

Trap 3: Device code grant

The device code grant requires a human to visit a verification URI and enter a code on a second device, so it still depends on user interaction. It is tempting because it suits input-constrained devices such as smart TVs or CLI tools where a browser cannot be launched locally.

Study all Scenario common traps →

A
Authorization code grant
Why it fails: The authorization code grant requires a browser redirect and a user authenticating at the authorization server to obtain the code, which no backend service can supply. It is tempting because it is the recommended flow for web applications acting on behalf of a signed-in user.
B
Password grant
Why it fails: The password grant requires the resource owner's username and password to be sent to the token endpoint, and it presumes a user whose credentials exist; a backend service has no such user. It is tempting for legacy first-party clients that collect credentials directly, such as a vendor's own mobile app.
C
Device code grant
Why it fails: The device code grant requires a human to visit a verification URI and enter a code on a second device, so it still depends on user interaction. It is tempting because it suits input-constrained devices such as smart TVs or CLI tools where a browser cannot be launched locally.
D
Client credentials grant
The client credentials grant exchanges the application's own client ID and secret directly for an access token, with no resource owner or browser redirect involved. This matches server-to-server backend calls where no user context exists, unlike authorisation code or implicit grants.

Full breakdown with real-world context →

Question 5hardmultiple choice

Study the full Python automation breakdown →

A developer is designing a Python application that must handle failures when making REST API calls to a Cisco DNA Center controller. The application should retry a failed request only if the HTTP status code indicates a server-side error (5xx) or a timeout occurs, but should not retry on client errors (4xx). The developer wants to implement this using a decorator. Which Python library provides a ready-to-use retry decorator that can be configured to retry on specific exceptions and HTTP status codes?

Trap 1: urllib3

urllib3 provides a Retry class that can be used with requests to handle retries at the connection level, but it is not a decorator and is not designed to be used directly as a decorator on functions. It is lower-level and would require manual integration. It does not offer the simplicity of a decorator for retrying arbitrary code blocks.

Trap 2: functools

The functools module provides tools like lru_cache and wraps, but it does not include a retry decorator. While it can be used to create a custom retry decorator, it does not provide one out of the box. The developer would need to implement the retry logic manually, which is not the ready-to-use solution requested.

Trap 3: requests

The requests library is used for making HTTP requests but does not include built-in retry logic as a decorator. It does offer a Retry class via urllib3 that can be attached to an HTTPAdapter, but that is not a decorator and requires more setup. It does not provide the decorator-based approach the developer is looking for.

Study all Scenario common traps →

A
urllib3
Why it fails: urllib3 provides a Retry class that can be used with requests to handle retries at the connection level, but it is not a decorator and is not designed to be used directly as a decorator on functions. It is lower-level and would require manual integration. It does not offer the simplicity of a decorator for retrying arbitrary code blocks.
B
tenacity
Tenacity is a general-purpose retrying library that provides a decorator and can be configured to retry based on exceptions, including custom conditions. It supports retrying on specific HTTP status codes when integrated with requests, and can be set to stop after a number of attempts. It is widely used in network automation for robust API interactions.
C
functools
Why it fails: The functools module provides tools like lru_cache and wraps, but it does not include a retry decorator. While it can be used to create a custom retry decorator, it does not provide one out of the box. The developer would need to implement the retry logic manually, which is not the ready-to-use solution requested.
D
requests
Why it fails: The requests library is used for making HTTP requests but does not include built-in retry logic as a decorator. It does offer a Retry class via urllib3 that can be attached to an HTTPAdapter, but that is not a decorator and requires more setup. It does not provide the decorator-based approach the developer is looking for.

Full breakdown with real-world context →

Question 6easymultiple choice

Read the full Scenario explanation →

A developer is working on a Git repository and needs to temporarily save changes that are not ready to be committed so they can switch to another branch to fix a bug. Which Git command should the developer use to stash the current changes?

Trap 1: git commit -m "WIP"

This is incorrect because committing unfinished work creates a permanent record in the branch history. While it does allow switching branches, it pollutes the commit history with incomplete changes that may not be desired. The scenario asks for temporary saving, not permanent recording. Stashing is the appropriate mechanism for temporary storage without affecting the commit graph.

Trap 2: git branch temp

This is incorrect because creating a new branch does not save uncommitted changes. The changes remain in the working directory and would carry over to any branch the developer switches to, potentially causing conflicts. Branching is for diverging work, not for temporarily setting aside changes. Stashing is the correct tool for that purpose.

Trap 3: git checkout -- .

This is incorrect because git checkout -- . discards all unstaged changes in the working directory, reverting files to the last committed state. This would permanently lose the developer's unfinished work, which is the opposite of what is needed. The developer wants to preserve changes temporarily, not destroy them. Stashing is the safe alternative.

Study all Scenario common traps →

A
git commit -m "WIP"
Why it fails: This is incorrect because committing unfinished work creates a permanent record in the branch history. While it does allow switching branches, it pollutes the commit history with incomplete changes that may not be desired. The scenario asks for temporary saving, not permanent recording. Stashing is the appropriate mechanism for temporary storage without affecting the commit graph.
B
git branch temp
Why it fails: This is incorrect because creating a new branch does not save uncommitted changes. The changes remain in the working directory and would carry over to any branch the developer switches to, potentially causing conflicts. Branching is for diverging work, not for temporarily setting aside changes. Stashing is the correct tool for that purpose.
C
git stash
This is correct because git stash saves the current working directory and index state, reverting the working directory to match the HEAD commit. It allows the developer to switch branches without committing unfinished work. Later, git stash pop or git stash apply can restore the changes. This command is specifically designed for temporarily shelving changes.
D
git checkout -- .
Why it fails: This is incorrect because git checkout -- . discards all unstaged changes in the working directory, reverting files to the last committed state. This would permanently lose the developer's unfinished work, which is the opposite of what is needed. The developer wants to preserve changes temporarily, not destroy them. Stashing is the safe alternative.

Full breakdown with real-world context →

Question 7hardmulti select

Read the full Scenario explanation →

A network engineer is deploying a new application that requires low-latency, high-throughput communication between two data centers. The engineer decides to use UDP instead of TCP for the application's transport protocol. Which two characteristics of UDP make it suitable for this scenario? (Choose two.)

Trap 1: UDP guarantees packet ordering and delivery.

UDP does not guarantee packet ordering or delivery. Packets may arrive out of order, be duplicated, or be lost entirely. Applications using UDP must handle these issues at the application layer if needed. This option confuses UDP with TCP, which provides ordered and reliable delivery through sequence numbers and acknowledgments.

Trap 2: UDP provides reliable delivery through acknowledgments and…

UDP does not provide reliable delivery; it is a connectionless protocol that does not use acknowledgments or retransmissions. Reliability is a feature of TCP, not UDP. This option incorrectly attributes TCP's reliability mechanisms to UDP, which would not be suitable for a low-latency scenario where some packet loss is acceptable.

Trap 3: UDP performs congestion control to avoid network congestion.

UDP does not perform congestion control. It sends data at the rate the application dictates, regardless of network conditions. Congestion control is a TCP feature that adjusts transmission rates based on network feedback. For low-latency applications, the lack of congestion control can be advantageous because it avoids delays caused by throttling, but it also risks network congestion.

Study all Scenario common traps →

A
UDP guarantees packet ordering and delivery.
Why it fails: UDP does not guarantee packet ordering or delivery. Packets may arrive out of order, be duplicated, or be lost entirely. Applications using UDP must handle these issues at the application layer if needed. This option confuses UDP with TCP, which provides ordered and reliable delivery through sequence numbers and acknowledgments.
B
UDP provides reliable delivery through acknowledgments and retransmissions.
Why it fails: UDP does not provide reliable delivery; it is a connectionless protocol that does not use acknowledgments or retransmissions. Reliability is a feature of TCP, not UDP. This option incorrectly attributes TCP's reliability mechanisms to UDP, which would not be suitable for a low-latency scenario where some packet loss is acceptable.
C
UDP has a smaller header size compared to TCP, reducing bandwidth overhead.
The UDP header is 8 bytes, while the TCP header is at least 20 bytes. This smaller header reduces per-packet overhead, which can improve efficiency for high-throughput applications. In scenarios where many small packets are sent, the reduced overhead can lead to better bandwidth utilization and lower latency.
D
UDP performs congestion control to avoid network congestion.
Why it fails: UDP does not perform congestion control. It sends data at the rate the application dictates, regardless of network conditions. Congestion control is a TCP feature that adjusts transmission rates based on network feedback. For low-latency applications, the lack of congestion control can be advantageous because it avoids delays caused by throttling, but it also risks network congestion.
E
UDP has lower overhead because it does not establish a connection before sending data.
UDP is connectionless, meaning it does not perform a three-way handshake before transmitting data. This reduces latency and overhead, making it suitable for applications that require low-latency communication. The absence of connection setup and teardown allows data to be sent immediately, which is beneficial for high-throughput, real-time applications.

Full breakdown with real-world context →

Question 8mediummultiple choice

Study the full Python automation breakdown →

A developer must build a Python script that reads a list of devices from a YAML inventory file and then pushes configuration to each device using NETCONF over SSH. The script must be reusable and must not hardcode credentials. Which approach best satisfies these requirements?

Trap 1: Use paramiko to open an interactive SSH shell and type…

paramiko opens a generic SSH channel, but NETCONF requires specific framing and XML capabilities negotiation. Trying to type CLI commands into an SSH shell does not use the NETCONF protocol and would not work against a NETCONF-only endpoint. It also ignores the YAML inventory requirement.

Trap 2: Use the requests library to POST XML configuration directly to the…

NETCONF uses SSH on port 830, not HTTP, so the requests library cannot speak the NETCONF protocol. Sending raw XML over HTTP to that port would fail because no HTTP server is listening. This option also does not address reading the YAML inventory or avoiding hardcoded credentials.

Trap 3: Use the ncclient library and hardcode the device list and…

ncclient is the correct library, but hardcoding the device list and credentials directly contradicts the requirement that the script be reusable and not embed secrets. Any credential rotation or inventory change would require editing the script, which is exactly what the scenario forbids.

Study all Scenario common traps →

A
Use paramiko to open an interactive SSH shell and type configuration commands into the CLI prompt.
Why it fails: paramiko opens a generic SSH channel, but NETCONF requires specific framing and XML capabilities negotiation. Trying to type CLI commands into an SSH shell does not use the NETCONF protocol and would not work against a NETCONF-only endpoint. It also ignores the YAML inventory requirement.
B
Use the requests library to POST XML configuration directly to the device management IP on port 830.
Why it fails: NETCONF uses SSH on port 830, not HTTP, so the requests library cannot speak the NETCONF protocol. Sending raw XML over HTTP to that port would fail because no HTTP server is listening. This option also does not address reading the YAML inventory or avoiding hardcoded credentials.
C
Use the ncclient library and hardcode the device list and credentials inside the script for simplicity.
Why it fails: ncclient is the correct library, but hardcoding the device list and credentials directly contradicts the requirement that the script be reusable and not embed secrets. Any credential rotation or inventory change would require editing the script, which is exactly what the scenario forbids.
D
Use the ncclient library, load the inventory with PyYAML, and retrieve credentials from environment variables.
ncclient is the standard Python library for NETCONF sessions and supports SSH transport. PyYAML parses the inventory file without hardcoding device data. Reading credentials from environment variables keeps secrets out of source code, which satisfies the reusability and security requirements described in the scenario.

Full breakdown with real-world context →

Question 9mediummultiple choice

Study the full Python automation breakdown →

A developer is writing a Python script that calls the Cisco DNA Center Intent API to retrieve a list of network devices. The script must handle the case where the API returns a 401 Unauthorized response by obtaining a new authentication token and retrying the request. Which Python construct should be used to implement this retry with token refresh?

Trap 1: A while loop that continuously sends the same request with the same…

A while loop that resends the same request with an unchanged token will never succeed if the token is invalid; it will keep receiving 401 responses indefinitely. This does not refresh the token and could cause an infinite loop, so it fails to meet the requirement of handling authentication failure gracefully.

Trap 2: A conditional statement that checks the response status code before…

Checking the response before sending the request is impossible because the response does not exist yet. Aborting on a non-200 status also does not retry or refresh the token, so it does not satisfy the requirement to recover from a 401 by re-authenticating and retrying the API call.

Trap 3: A for loop that iterates over a list of predefined tokens, sending…

Using a static list of tokens is impractical and insecure; tokens expire and must be obtained dynamically. This approach does not refresh the token from the authentication endpoint and assumes multiple valid tokens exist, which is not how Cisco DNA Center authentication works, so it is not a viable solution.

Study all Scenario common traps →

A
A while loop that continuously sends the same request with the same token until a 200 OK response is received.
Why it fails: A while loop that resends the same request with an unchanged token will never succeed if the token is invalid; it will keep receiving 401 responses indefinitely. This does not refresh the token and could cause an infinite loop, so it fails to meet the requirement of handling authentication failure gracefully.
B
A conditional statement that checks the response status code before sending the request and, if it is not 200, aborts the script.
Why it fails: Checking the response before sending the request is impossible because the response does not exist yet. Aborting on a non-200 status also does not retry or refresh the token, so it does not satisfy the requirement to recover from a 401 by re-authenticating and retrying the API call.
C
A try/except block that catches requests.exceptions.HTTPError, checks the response status code, and if it is 401, obtains a new token using the DNA Center authentication endpoint and retries the original request.
This approach correctly handles the 401 by catching the HTTPError raised by raise_for_status(), then re-authenticating via the DNA Center token endpoint and retrying. It directly addresses the scenario's requirement to refresh the token and retry on unauthorized responses, making it the appropriate Python construct for this error-handling flow.
D
A for loop that iterates over a list of predefined tokens, sending the request with each token until one succeeds.
Why it fails: Using a static list of tokens is impractical and insecure; tokens expire and must be obtained dynamically. This approach does not refresh the token from the authentication endpoint and assumes multiple valid tokens exist, which is not how Cisco DNA Center authentication works, so it is not a viable solution.

Full breakdown with real-world context →

Question 10mediummultiple choice

Read the full DNS explanation →

A network engineer writes a Python script to handle exceptions when making REST API calls. Which exception type should be caught to handle network connectivity issues (e.g., DNS failure, refused connection)?

Trap 1: requests.exceptions.RequestException

RequestException is the base class for all requests exceptions, so catching it also swallows HTTPError, Timeout and other unrelated failures rather than isolating connectivity faults. It is tempting as a catch-all for any API call failure; however, ConnectionError is the specific subclass raised for DNS failure and refused connections.

Trap 2: requests.exceptions.HTTPError

HTTPError is raised only when a response returns an unsuccessful status code, so it never fires for DNS failure or refused connections where no response arrives. It is tempting because API scripts commonly check status codes; however, ConnectionError is the subclass that covers those transport-level failures.

Trap 3: requests.exceptions.Timeout

Timeout fires only when a connection or read exceeds the configured timeout, not when DNS resolution fails or a connection is refused outright. It is tempting because slow or unreachable endpoints often manifest as timeouts; however, ConnectionError is the subclass raised for those connectivity faults.

Study all Scenario common traps →

A
requests.exceptions.RequestException
Why it fails: RequestException is the base class for all requests exceptions, so catching it also swallows HTTPError, Timeout and other unrelated failures rather than isolating connectivity faults. It is tempting as a catch-all for any API call failure; however, ConnectionError is the specific subclass raised for DNS failure and refused connections.
B
requests.exceptions.ConnectionError
requests.exceptions.ConnectionError is raised when the underlying connection cannot be established, covering DNS resolution failures and refused connections. Catching it satisfies the requirement to handle network connectivity issues, unlike HTTPError, which signals a received error response.
C
requests.exceptions.HTTPError
Why it fails: HTTPError is raised only when a response returns an unsuccessful status code, so it never fires for DNS failure or refused connections where no response arrives. It is tempting because API scripts commonly check status codes; however, ConnectionError is the subclass that covers those transport-level failures.
D
requests.exceptions.Timeout
Why it fails: Timeout fires only when a connection or read exceeds the configured timeout, not when DNS resolution fails or a connection is refused outright. It is tempting because slow or unreachable endpoints often manifest as timeouts; however, ConnectionError is the subclass raised for those connectivity faults.

Full breakdown with real-world context →

Continue with 20-question session →

Free account

Track your progress over time

Create a free account to save your results and see which topics improve across sessions.

Focused Scenario sessions

Start a Scenario only practice session

Every question in these sessions is drawn from the Scenario domain — nothing else.

10 questions 20 questions 30 questions 50 questions

Browse all Scenario questions →Mixed 200-901 session

Frequently asked questions

What does the 200-901 exam test about Scenario?: Scenario questions test whether you can apply the concept in context, not just recognise a definition.
How should I use these practice questions?: Select your answer before revealing the explanation. Then read why each option is right or wrong — this active recall approach builds retention far faster than re-reading notes.
Can I practise just Scenario questions in a focused session?: Yes — the session launcher on this page draws every question from the Scenario domain. Use a 10-question session first to gauge your baseline, then move to 20 or 30 once the weak spots are clear.
Where can I practise other 200-901 topics?: Use the topic links above to move to related areas, or go back to the 200-901 question bank to see all topics.
Are these real exam questions or dumps?: These are original practice questions written to test the same concepts the 200-901 exam covers. They are not copied from any real exam or dump site.

Scenario only

10 questions 20 questions 30 questions 50 questions

Mixed 200-901 session

Track your progress

A free account saves results across sessions and highlights which topics need work.

Study resources

All 200-901 questions Scenario domain overview 200-901 exam guide

Exam traps to avoid

▸Answering from memory before reading the full scenario.
▸Missing a constraint such as cost, availability, security, scope or command context.
▸Choosing a broad answer when the question asks for the most specific fix.
▸Ignoring why the wrong options are tempting.

Scenario practice questions

What to know about Scenario

Common Scenario exam traps

Scenario questions

A developer is troubleshooting a Cisco RESTCONF API call that returns a 409 Conflict error. Which two scenarios could cause this? (Choose two.)

Which THREE are valid Kubernetes Service types? (Select three.)

A developer receives HTTP 409 Conflict when updating a network configuration via Cisco NX-OS API. Which two scenarios could cause this error?

Which OAuth 2.0 grant type is most appropriate for a server-to-server integration where no user interaction is required, such as a backend service calling Cisco API?

A developer is working on a Git repository and needs to temporarily save changes that are not ready to be committed so they can switch to another branch to fix a bug. Which Git command should the developer use to stash the current changes?

A developer must build a Python script that reads a list of devices from a YAML inventory file and then pushes configuration to each device using NETCONF over SSH. The script must be reusable and must not hardcode credentials. Which approach best satisfies these requirements?

A network engineer writes a Python script to handle exceptions when making REST API calls. Which exception type should be caught to handle network connectivity issues (e.g., DNS failure, refused connection)?

Track your progress over time

Start a Scenario only practice session

Related 200-901 topic practice pages

Infrastructure and Automation practice questions

Application Deployment and Security practice questions

Understanding and Using APIs practice questions

Software Development and Design practice questions

Cisco Platforms and Development practice questions

Network Fundamentals practice questions

200-901 fundamentals practice questions

200-901 scenario practice questions

200-901 troubleshooting practice questions

Frequently asked questions

Track your progress

Study resources

Exam traps to avoid