Select Two (Multi-Select) Questions

NETCONF

Why it fails: NETCONF is a protocol, not a YANG model source/tool.

oc-interfaces

Why it fails: This is a specific OpenConfig model, not a source or tool.

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.

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.

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.

Expose all ports

Why it fails: Publishing every port widens the reachable attack surface, which is the opposite of securing a container. It is tempting because exposing ports is how services become reachable, and that is legitimate when a container must accept inbound traffic on specific, deliberately chosen ports.

Run containers as root

Why it fails: Running as root means a container escape or process compromise yields host-level privileges, defeating the isolation securing a container depends on. It is tempting because many official images default to root, so it works without extra configuration when privilege inside the container is genuinely required.

Disable network isolation

Why it fails: Disabling network isolation lets containers reach each other and the host unrestricted, removing the segmentation that limits lateral movement after compromise. It is tempting because flat networking simplifies service discovery and connectivity when containers must freely communicate without policy overhead.

junos_config

Why it fails: For Juniper Junos.

nxos_command

Why it fails: For NX-OS devices.

eos_config

Why it fails: For Arista EOS.

Use long-lived static passwords for service accounts

Why it fails: Long-lived static passwords remain valid indefinitely, so any leak grants persistent access and rotation becomes a manual, error-prone task. It is tempting because static service-account credentials are simple to configure once. Short-lived, dynamically issued credentials from a secrets manager satisfy the pipeline's authentication requirement instead.

Hardcode secrets directly in application code for ease of access

Why it fails: Hardcoding secrets in application code exposes them to anyone with repository or image access, and rotation requires a code change and redeploy. The option tempts because it removes external dependency lookups during builds, which is convenient, but that convenience is exactly why secrets belong in a managed vault or CI/CD secret store instead.

Store secrets in a configuration file stored in the git repository

Why it fails: Committing secrets to a git-tracked configuration file exposes them to anyone with repository read access and preserves them permanently in commit history, so rotation cannot remediate the leak. It is tempting because config files are the natural place for non-sensitive pipeline settings; a secrets manager or CI/CD secret store is the correct location for credentials.

CSV

Why it fails: CSV is not typical for REST APIs.

HTML

Why it fails: HTML is for web pages, not API data exchange.

Plain text headers

Why it fails: HTTP/2 compresses header fields with HPACK, transmitting them in binary form; plain text headers are an HTTP/1.1 trait. It tempts because HTTP/1.1 headers are human-readable ASCII, and developers debugging with curl still see decoded text, but that readability is lost on the wire under HTTP/2.

Persistent connections

Why it fails: Persistent connections already existed in HTTP/1.1 via keep-alive, so they are not a distinguishing HTTP/2 feature; HTTP/2 instead multiplexes many streams over one connection. It tempts because HTTP/2 does use a single long-lived connection, but that reuse is inherited rather than new.

Webhooks require OAuth 2.0 client credentials grant for security.

Why it fails: Webex webhooks authenticate via a shared secret or signature verification, not the OAuth 2.0 client credentials grant, which secures server-to-server API calls rather than inbound event delivery. It tempts because client credentials genuinely suit machine-to-machine integrations that call Webex APIs directly.

Webhooks use long polling to receive events.

Why it fails: Webhooks deliver events by HTTP POST callbacks to a registered target URL, not by long polling. It tempts because long polling is a real Webex API technique for receiving events, but that mechanism belongs to the events API, not to webhooks.

IPv6 addresses are 32 bits in length.

Why it fails: IPv6 addresses are 128 bits.

IPv6 uses ARP to resolve MAC addresses.

Why it fails: IPv6 uses Neighbor Discovery Protocol (NDP) instead of ARP.

Use a single try/except block to catch all exceptions without differentiation.

Why it fails: Catching every exception in one block discards the distinction between HTTP status errors, JSON decode failures and connection timeouts, so recovery logic cannot differ per failure. Separate handlers let each be retried, logged or surfaced appropriately. A single catch-all suits scripts where any failure triggers identical abort behaviour.

Assume the request always succeeds; errors are rare.

Why it fails: Assuming success leaves no handler for HTTP error codes, malformed JSON or socket timeouts, so the script crashes on the first failure. Graceful handling requires explicit try/except around the request and parsing. This assumption only holds for controlled internal calls where failures genuinely cannot occur.

Always parse the response body with json.loads() regardless of content type.

Why it fails: Calling json.loads() on an HTML error page or empty body raises JSONDecodeError, masking the real HTTP failure. The Content-Type header or response status should gate parsing. Unconditional parsing is fine only when the endpoint contract guarantees JSON on every response, including errors.

ExternalName

Why it fails: ExternalName maps a Service to a DNS CNAME, returning only that alias to in-cluster lookups; it creates no proxy, load balancer or external IP, so outside clients cannot reach the pods. It suits abstracting an external dependency, such as a managed database, behind an internal name.

ClusterIP

Why it fails: ClusterIP assigns only an internal virtual IP reachable within the cluster, so it never exposes a service externally. It is tempting because it is the default Service type and does provide stable in-cluster access, which is exactly the scenario where it is the right choice.

500 Internal Server Error

Why it fails: 500 belongs to the server error class, meaning the request was valid but the server failed processing it. It is tempting because both 4xx and 5xx indicate failures, yet only 4xx codes such as 400 or 404 signal a client-side fault.

200 OK

Why it fails: 200 signals a successful request, not a client error, so it sits in the success class. It is tempting because it appears whenever a request completes, but success codes confirm the client's request was accepted and processed.

201 Created

Why it fails: 201 confirms a resource was created successfully, placing it in the success class rather than the client error class. It is tempting because it accompanies POST requests, yet it reports success, not a malformed or unauthorised client request.

DevNet Sandboxes are only available with a paid subscription.

Why it fails: Many sandboxes are free.

DevNet Sandboxes only support Cisco Catalyst switches.

Why it fails: They support many platforms.

DevNet Sandboxes do not support third-party devices.

Why it fails: Some include third-party devices.

Allow all container images to be pulled from any public registry.

Why it fails: Pulling images from any public registry removes provenance control, letting untrusted or tampered layers enter the build and deploy stages. It is tempting because unrestricted registries maximise image availability and convenience, which suits isolated lab or proof-of-concept environments where supply-chain risk is deliberately accepted, not a secure pipeline.

Store secrets (API keys, passwords) in version control.

Why it fails: Version control retains every committed value in history, so secrets remain recoverable by anyone with repository access even after deletion. It is tempting because committing configuration alongside code keeps deployments reproducible and simple, which suits non-sensitive parameters such as ports or feature toggles, not API keys or passwords.

Use SNMP MIBs for all configurations

Why it fails: SNMP is not suitable for all configuration tasks.

Configure each device manually through CLI

Why it fails: Manual configuration contradicts automation goals.

People API

Why it fails: The People API returns directory profile data about users; it does not receive or deliver bot messages. It is tempting because bots often resolve sender identities, but that is supplementary enrichment, whereas the Messages API and webhooks are what actually receive and post message content.

Licenses API

Why it fails: The Licenses API reports Webex service entitlements for users and organisations; it plays no part in receiving or responding to messages. It is tempting because bot deployment may require licence checks, but that is administrative provisioning, not the message-handling endpoints the bot's runtime depends on.

IP

Why it fails: IP is a network layer protocol.

TCP

Why it fails: TCP is a transport layer protocol.

ARP

Why it fails: ARP is a data link/network layer protocol.

Network device configuration files

Why it fails: Configuration files are retrieved through Catalyst Center's configuration APIs or Command Runner, not the intent API, which abstracts intent rather than returning raw device configs. It tempts because Catalyst Center stores device configurations for compliance, so it would be the right choice when the requirement is configuration archive or drift comparison.

Real-time interface statistics

Why it fails: Real-time interface statistics are polled from devices or streamed via telemetry, not exposed through Catalyst Center's intent API, which returns modelled network intent and assurance data rather than live counters. It tempts because assurance dashboards display interface health, but that data comes from the telemetry pipeline, not the intent API.

Configuration compliance auditing

Why it fails: Prime also has compliance auditing.

Software image management

Why it fails: Both DNA Center and Prime offer image management.

Network Hierarchy and Site Management

Why it fails: Both have site management capabilities.

Status code

Why it fails: Part of response.

Payload

Why it fails: Only present in some requests (POST, PUT).

Query string

Why it fails: Part of URI, optional.