200-901 Timed Practice Test 5 — 10 Questions

Question 1

Which TWO are common authentication methods used when interacting with Cisco APIs?

Accepted Answer

HTTP Basic Authentication. HTTP Basic Authentication (option B) is a common method for authenticating to Cisco APIs, where the client sends a base64-encoded username:password string in the Authorization header. API keys in HTTP headers (option C) are also widely used, especially with REST APIs like Cisco DNA Center or Meraki, where the key is passed in a custom header (e.g., 'X-Cisco-Meraki-API-Key'). Both are simple, stateless mechanisms supported by many Cisco platforms.

Answer

Client certificate exchange

Answer

LDAP bind credentials

Answer

SNMPv3 authentication

Question 2

Refer to the exhibit. A service engineer runs a 'check-sync' action on the NSO service 'vpn1'. The result shows 'out-of-sync' for device 'pe1'. What does this indicate?

Accepted Answer

The configuration on pe1 differs from the service model defined in NSO.. The 'check-sync' action in NSO compares the actual device configuration (retrieved via NETCONF or CLI) against the configuration that NSO's service model expects. An 'out-of-sync' result for device 'pe1' means the running configuration on pe1 does not match the configuration defined by the NSO service model for that device. This is a standard NSO feature to detect configuration drift.

Answer

The device pe1 is unreachable via NETCONF.

Answer

The service model in NSO does not have a configuration for pe1.

Answer

The device pe1 has a hardware failure.

Question 3

A security policy requires that all container images in a registry are scanned for vulnerabilities before deployment. Which approach best integrates this into a CI/CD pipeline without slowing down the pipeline?

Accepted Answer

Build the image, scan it locally, and if it passes, push it to the registry; run scans in parallel with the build if possible.. Option C is correct because it shifts the vulnerability scan left in the pipeline: the image is built and scanned locally before being pushed to the registry. If the scan passes, the image is pushed; if it fails, the pipeline stops early, avoiding the overhead of pushing a vulnerable image and then rebuilding. This approach minimizes pipeline latency by running scans in parallel with the build where possible, ensuring security without blocking the deployment flow.

Answer

Build the image, push it, then scan it, and if vulnerabilities are found, rebuild and repush.

Answer

Run the vulnerability scan on the image after pushing to the registry and block deployment if critical vulnerabilities are found.

Answer

Scan the source code dependencies before building the image, and skip image scanning.

Question 4

Which TWO are valid methods to secure a REST API? (Choose two.)

Accepted Answer

Use HTTPS to encrypt data in transit.. HTTPS (HTTP over TLS) encrypts the entire HTTP conversation, including headers and payload, using Transport Layer Security (TLS). This prevents eavesdropping, man-in-the-middle attacks, and tampering of data in transit. For a REST API, HTTPS is a fundamental security requirement to protect sensitive data and credentials from being exposed on the network.

Answer

Use HTTP with basic authentication.

Answer

Embed API keys in the URL query string.

Answer

Implement rate limiting to prevent abuse.

Question 5

A network engineer is troubleshooting a Kubernetes deployment where pods are failing to start with the error 'CrashLoopBackOff'. The pod log shows 'bind: address already in use'. The deployment runs multiple replicas of a container that listens on port 8080. What is the most likely cause?

Accepted Answer

The deployment has hostPort: 8080 specified, causing port conflict when multiple replicas are scheduled on the same node.. The 'bind: address already in use' error indicates that the container's process cannot bind to port 8080 because it is already occupied. When `hostPort: 8080` is specified in the pod spec, Kubernetes instructs the container runtime to map the container port to the same port on the node's network namespace. If multiple replicas of the deployment are scheduled on the same node, each pod attempts to bind to port 8080 on the host, causing a conflict and the CrashLoopBackOff state. This is a common misconfiguration when using hostPort without ensuring that replicas are spread across different nodes.

Answer

The container is attempting to bind to a privileged port without the necessary capabilities.

Answer

The service is using NodePort and the node port is already in use.

Answer

Multiple containers in the same pod are trying to bind to the same port.

Question 6

A developer needs to ensure that microservice A can securely communicate with microservice B over HTTPS within a Kubernetes cluster. What is the simplest approach?

Accepted Answer

Create a Kubernetes Service of type ClusterIP for microservice B and configure microservice A to use HTTPS with the service DNS name.. Option D is correct because using a ClusterIP Service for microservice B provides a stable DNS name within the cluster, allowing microservice A to communicate over HTTPS without exposing the service externally. This approach leverages Kubernetes' internal service discovery and can be paired with a service mesh or mutual TLS (mTLS) for secure communication, meeting the requirement for simplicity and security.

Answer

Use a Kubernetes Ingress resource with TLS termination for microservice B.

Answer

Expose microservice B via a LoadBalancer Service and use HTTPS from microservice A.

Answer

Connect directly using the pod IP of microservice B over HTTP.

Question 7

During an automation script run, a network device returns HTTP 429. What does this indicate?

Accepted Answer

Rate limiting. HTTP 429 (Too Many Requests) indicates the client has sent too many requests in a given amount of time, triggering rate limiting on the server. In network automation, devices like routers or switches enforce rate limits to prevent resource exhaustion, often based on RFC 6585. This is common when automation scripts exceed API call thresholds, requiring retry logic with exponential backoff.

Answer

Internal server error

Answer

Authentication failure

Answer

Resource not found

Question 8

Which THREE of the following are best practices for writing Ansible playbooks for network automation? (Select exactly 3.)

Accepted Answer

Include a validation task after configuration changes. Option B is correct because after applying configuration changes via modules like `ios_config` or `junos_config`, a validation task (e.g., using `wait_for` or `assert` to verify operational state) ensures the device is reachable and the changes took effect before proceeding. This prevents cascading failures in multi-device playbooks and aligns with network automation best practices for reliability.

Answer

Run all tasks without checking for errors

Answer

Hardcode device IPs in the playbook

Question 9

In a network automation workflow, a developer needs to ensure idempotency. What does idempotency mean in this context?

Accepted Answer

Running the script once produces the same result as running it multiple times. Idempotency in network automation means that executing an operation multiple times results in the same network state as executing it once. For example, using a REST API PUT request to set a VLAN configuration will leave the device in the same state whether the request is sent once or repeatedly, because PUT is inherently idempotent. This prevents unintended side effects like duplicate VLANs or interface misconfigurations when a script is retried due to network failures or timeouts.

Answer

The script uses a single API call

Answer

The script can recover from failures

Answer

The script can run on multiple devices simultaneously

Question 10

Which THREE of the following are valid methods to handle API rate limiting in a Python automation script? (Select exactly 3.)

Accepted Answer

Parse the Retry-After header from the response. Option A is correct because the Retry-After header is a standard HTTP mechanism (defined in RFC 7231) that explicitly tells the client how long to wait before making the next request. Parsing this header allows your Python script to respect the server's rate limit dynamically, rather than using a fixed or arbitrary delay. This is a common pattern when interacting with REST APIs that enforce rate limiting.

Answer

Sleep for a fixed amount of time between requests

Answer

Ignore the limit and send requests faster