Cisco Certified Network Associate (CCNA) 200-301 Practice Test 68
Question 670
An AI-assisted network operations summary states that a switch rebooted because of a power failure. Its only cited evidence is a syslog interface link-down event; there is no reboot event, power telemetry or device uptime record. What is the appropriate acceptance decision?
- Approve the power-failure conclusion because a link-down log is always caused by a reboot.
- Reject the unsupported root-cause claim and require corroborating reboot or power evidence with verifiable citations.
- Delete all syslog entries so the model no longer produces inconsistent summaries.
- Execute the proposed power-supply replacement automatically because AI confidence is not shown.
Explanation
Correct Answer
B:The cited link-down record supports only the narrower observation that the interface went down. To claim the switch rebooted because it lost power, the system should produce evidence such as boot markers, uptime discontinuity, power-source alarms, environmental telemetry or correlated neighbor and power logs. If that evidence does not exist, present the cause as undetermined rather than asserted fact. An AI summary should map each substantive assertion to actual accessible observations and preserve uncertainty, and potentially disruptive remediation should require an explicitly authorized operational workflow. This scenario tests evidence-grounded AI use in network operations, not generic model confidence or automatic execution. Cross-check event timestamps and device identity before drawing a root-cause conclusion.
Incorrect Answers
A:A link-down event is compatible with several causes: unplugged media, neighbor failure, switchport shutdown, physical errors or a local device interruption. It is not exclusive proof that the switch rebooted, much less that power failed. Accepting a single explanation as certain would turn a weak inference into an operationally costly maintenance decision. Investigate additional logs and state rather than assuming causation from temporal proximity.
C:Deleting logs removes precisely the historical evidence needed to assess the incident and makes future audit harder. The mismatch is an inference-quality issue, not a reason to erase potentially relevant telemetry. Preserve original records, retrieve additional data sources and make the summarizer state when it cannot substantiate a conclusion. Deletion can also violate operational retention policy.
D:Replacing hardware is an impactful physical change that should follow a supported diagnosis and appropriate approval. No power telemetry or reboot proof is available, so a power-supply swap would be speculative. Model-generated suggestions do not become operational authority merely because they are phrased confidently. Establish independent evidence of a failed component and follow the organization's change process before physical remediation.
Question 671
An application needs to read the existing operational status of `/api/v1/devices/R1/interfaces/Gi0-1` and must not create or modify a resource. The endpoint requires a token. Which HTTP request is appropriate?
- Send an authenticated `GET` to the resource URI and parse the returned representation without a mutation body.
- Send `POST` to the collection to create a new interface record for each health check.
- Send `PUT` with an empty object to the interface URI to discover its current state.
- Send `DELETE` to the interface URI and assume the server will return its current status.
Explanation
Correct Answer
A:GET has read/retrieval semantics. Authentication may be required, but a successful read should not create or overwrite the target resource. Verify the response status and payload rather than using POST or PUT on an endpoint intended only for retrieval.
Incorrect Answers
B:POST commonly invokes resource creation or other mutation; it does not express the stated read-only request.
C:PUT generally requests creation/replacement at the target URI and can overwrite resource data.
D:DELETE requests removal, not retrieval, and violates the no-modification requirement.
Question 672
A network inventory REST service accepts `POST /devices` with a JSON body describing a new branch router. The service chooses a unique resource ID and returns `201 Created` with a `Location` header. Which method best matches this resource-creation behavior?
- GET to the devices collection because retrieving a representation must also create a new device.
- PUT to `/devices` without identifying a target resource, while assuming the server can never create an ID.
- DELETE to `/devices` with the JSON body so the server inserts a new child resource.
- POST to the devices collection, then follow the returned Location or identifier to verify the created resource.
Explanation
Correct Answer
D:POST asks the target resource to process the enclosed representation according to service-specific semantics and is commonly used when the server allocates a new child-resource URI. In this scenario the API accepts POST to `/devices`, returns 201 Created and supplies a Location pointing to the new device representation. Validate the returned identifier and retrieve the created resource; handle retries carefully because repeating a non-idempotent POST may create duplicates unless the API supports idempotency controls. The service's documented behavior, not a memorized method acronym, is the decisive detail. Authorization, schema validation and TLS transport remain separate required controls.
Incorrect Answers
A:GET requests a representation of a target resource and is intended to be safe. A correctly designed collection GET should not create a new inventory device as its requested effect. If a server mutates inventory on GET, that violates expected method semantics and is not the documented creation endpoint here.
B:PUT normally targets a known resource URI and requests creation or replacement of that specified resource state. The given API contract delegates ID allocation to the server when POSTing to the `/devices` collection. Using a collection PUT without a target identity does not match this described contract and can have different semantics.
C:DELETE requests removal of the targeted resource rather than creation of a new child. Supplying JSON describing a router does not turn DELETE into a resource-creation method. The 201 Created and Location behavior in the scenario is associated with successful POST processing to the documented collection.
Question 673
An operator needs to change only the `description` field of an existing REST-managed interface while preserving its configured MTU, VLAN and administrative state. The API supports JSON Merge Patch on `PATCH /interfaces/7`; PUT replaces the resource representation. What is the safest method for this narrow change?
- Send PUT with only the description field and assume every omitted field must remain unchanged.
- Send a supported PATCH request containing the intended description update and verify the unaffected fields afterward.
- Send GET with a request body carrying the description so the server applies the partial update.
- Send DELETE followed by GET to recreate the interface with its original settings automatically.
Explanation
Correct Answer
B:A documented PATCH operation applies a partial modification to an existing resource under its defined patch semantics. Because the service explicitly supports JSON Merge Patch on `/interfaces/7`, the operator can send a patch containing only `description`, avoiding an unintended full replacement of the representation. Use the appropriate Content-Type and authorization, consider concurrency controls such as ETags if supported, and inspect the resulting interface state. Verify the new description and also the unchanged MTU, VLAN and administrative status. PATCH behavior depends on the API's documented patch format; it should not be assumed for an endpoint that does not support it.
Incorrect Answers
A:PUT generally expresses replacement of a target resource's state with the supplied representation. If the server interprets omitted properties as absent or default values, a description-only PUT can unintentionally remove MTU, VLAN or administrative settings. The scenario explicitly states this API's PUT is a replacement operation, so use supported partial modification instead.
C:GET is intended for retrieving a resource representation and does not define a general way to modify state using a request body. An API that unexpectedly changes data on GET can break caches and client assumptions. The documented partial-update route is PATCH on the targeted interface.
D:DELETE removes the target resource; GET retrieves a representation. Neither step automatically rebuilds the original interface configuration, and deletion could interrupt network service. A narrow description change should not require destroying and recreating the managed interface. Use the API's supported partial-update mechanism.
Question 674
A controller REST endpoint expects JSON in an authenticated POST. A script sends a valid JSON body but receives HTTP 401, and the server log reports a missing `Authorization` header. What change addresses the authentication failure?
- Include a valid `Authorization: Bearer <access_token>` header for the API, with `Content-Type: application/json` for the JSON request body.
- Change only the body to XML while leaving the authentication header absent.
- Replace POST with DELETE to bypass the endpoint’s login requirements.
- Retry the same unauthenticated POST indefinitely because a syntactically valid JSON payload guarantees authorization.
Explanation
Correct Answer
A:HTTP 401 indicates the request lacks valid authentication credentials for the protected resource. Supplying the documented bearer token addresses the missing-credentials finding; a JSON media type describes the body, not authorization. The caller should handle token expiration securely.
Incorrect Answers
B:Body format does not substitute for credentials; the server explicitly reports missing Authorization.
C:HTTP method changes do not grant access and risk a destructive request.
D:Well-formed JSON proves neither caller identity nor permission.
Question 675
A network inventory endpoint `GET /devices/7` unexpectedly increments a persistent device-maintenance counter on the server every time a monitoring poller reads it. Repeated harmless-looking checks now change business state. Which API defect should the engineer report?
- The GET handler violates expected safe-method semantics by changing application state as the requested effect of a read.
- A GET request must always allocate a new inventory resource ID, so incrementing counters is correct creation behavior.
- A successful GET may never produce any server logs or metrics, therefore all logging must be disabled.
- The error is that the endpoint did not use UDP instead of HTTP/TCP to transmit a read request.
Explanation
Correct Answer
A:HTTP GET is defined as a safe method: the client requests transfer of a resource representation and does not request a state change in the target application. A server can log accesses or perform incidental internal work, but a persistent business-maintenance counter incremented as part of every read is an inappropriate requested side effect for a GET endpoint. Fix the handler so polling does not mutate managed inventory, and move intentional counter-changing actions to a documented state-changing operation. Regression-test repeated GETs for unchanged application state while allowing ordinary access logs. This distinction matters because caches, prefetchers and monitoring tools may call GET repeatedly under the assumption it is safe.
Incorrect Answers
B:GET requests representation retrieval, not automatic creation of an inventory resource. A new server-generated resource ID is commonly associated with a successful documented POST to a collection. Treating every read as creation would produce unexpected duplicates or side effects and conflict with normal safe HTTP behavior.
C:Safe-method semantics do not prohibit a server from keeping access logs, audit evidence or operational metrics as incidental effects of reading a resource. The defect is a change to the application's requested business state, not the mere existence of internal logs. Disable the unintended mutation rather than legitimate observability.
D:HTTP ordinarily uses a transport such as TCP or QUIC depending on the HTTP version; it is not defined as a protocol that must replace reads with UDP commands. The network transport does not change GET's intended safe semantics. The incident concerns what the server does with a retrieval request.
Question 676
An automation client calls a device-management REST API with `POST /devices` to create an object. The server creates object ID 481, but the response is lost. The client blindly retries the same POST and receives a second object ID 482. Which application design best prevents this duplicate-create problem?
- Replace every POST with GET because GET is the standard method for creating new resources.
- Repeat POST indefinitely until an HTTP 200 appears, assuming retries cannot change server state.
- Use a documented idempotency token or reconciliation lookup before retrying creation, according to the API contract.
- Disable TLS server validation so the retry response is less likely to fail.
Explanation
Correct Answer
C:The client must distinguish a lost response from a failed server operation. If the API supports an idempotency key, send a stable unique token on the original create and its retries so the server can recognize the same logical request. If no such feature is documented, reconcile by querying for the intended resource using a stable external identifier before deciding whether to create again. The exact safe behavior depends on the API contract; do not assume a universal idempotency-key feature exists. Treat HTTP 201 and a returned Location or resource ID as successful evidence when received, but remember that a timeout after POST is ambiguous. Reconciliation prevents unintended duplicates while preserving legitimate new-object creation.
Incorrect Answers
A:GET is defined for retrieving a representation, not creating a server-side object as a normal safe HTTP operation. Changing the method arbitrarily would not satisfy the API's documented resource-creation contract and could fail authorization or routing. The client still needs to handle a lost response after a state-changing request; simply substituting GET without a reconciliation protocol is not an implementation of creation.
B:POST is not inherently idempotent. The server may perform a creation each time it processes the request, so a missing response does not mean the previous creation failed. Repeating the request without a request identity or lookup already produced IDs 481 and 482, demonstrating the danger. HTTP status-code expectations do not prevent additional state changes when retrying an unsafe operation.
D:TLS certificate verification secures server identity and the channel. Disabling it weakens security and does nothing to make POST idempotent. An HTTP response can still be lost after the server commits the object even over a secure connection. Duplicate creation is a request-retry semantics problem, not a certificate-trust problem. Preserve TLS validation while implementing proper result reconciliation.
Question 677
A network-controller API documents PUT as full replacement of an interface resource. A client uses PUT with only `{"description":"WAN-A"}` and afterwards the interface's old MTU and ACL fields have reset. Which defect caused the unintended changes?
- The client used a replacement operation but omitted properties that needed to be retained; use the documented partial-update mechanism or a complete representation.
- A DNS TTL was too long and caused the JSON body's missing fields to become null.
- The TCP three-way handshake transmitted an extra ACK that reset the interface ACL.
- SNMP polling of the interface counters always deletes fields excluded from GET responses.
Explanation
Correct Answer
A:In this API contract, PUT replaces the target interface representation rather than patching only supplied properties. Sending just the description can therefore remove or reset fields not included in the replacement body, including MTU and ACL settings, depending on the documented schema. This is a client request-design problem, not a transport error. Prefer the supported PATCH operation for narrow changes or construct and validate a complete replacement representation, potentially using a fresh GET and conditional request to avoid overwriting concurrent changes. Confirm all critical fields after the update and record a rollback plan for network-affecting changes.
Incorrect Answers
B:DNS TTL controls caching of name-resolution records; it does not add or erase JSON object fields from an API request body. The request already reached the correct interface resource and changed its description. The omitted properties were lost because the server treats PUT as replacement, as explicitly documented.
C:TCP ACK packets establish and maintain reliable transport semantics; they do not choose how a REST server interprets a PUT request's JSON representation. The interface fields changed after the server processed the supplied replacement body. Diagnose API method semantics rather than packet acknowledgment ordering.
D:SNMP monitoring retrieves counters and may receive traps, but ordinary polling does not delete configuration fields from a REST resource representation. The documented PUT replacement semantics and omitted MTU/ACL values explain the reset. An unrelated management read does not produce this exact update behavior.
Question 678
A REST client calls a network-controller endpoint using a bearer token. With no Authorization header it receives HTTP 401. With a valid login token lacking configuration privileges it receives HTTP 403. What is the best interpretation?
- 401 means the resource does not exist, while 403 confirms that the target URI has been permanently removed.
- 401 is an error that requires enabling OSPF, while 403 requires a subnet mask change on the client.
- Both codes prove network connectivity failed before the HTTP server received any request.
- 401 indicates missing or unacceptable authentication credentials; 403 indicates the server understood the request but refuses access, such as for insufficient authorization.
Explanation
Correct Answer
D:HTTP 401 Unauthorized is an authentication challenge or failure category: the request lacks acceptable credentials for the protected resource. An HTTP 403 Forbidden response indicates that the server understood the request but declines to authorize it, which can occur when an authenticated principal lacks sufficient privileges or policy permits. The example differentiates missing credentials from an authenticated but underprivileged token. Confirm the appropriate scheme and header, token validity and permitted scopes or roles rather than blindly retrying. Do not expose secrets in logs when debugging. The server may intentionally hide some authorization details, so review its documented access policy as well.
Incorrect Answers
A:A missing resource is commonly represented by HTTP 404 rather than automatically by 401. A resource removed permanently may use a status such as 410, but 403 is a refusal to permit the requested action. The example provides direct evidence that the authentication and privilege level changes the response.
B:OSPF route exchange and subnet masks can influence whether an IP connection reaches a remote service, but an actual HTTP 401 or 403 means the server has already processed the HTTP request enough to return an application-layer status. Fix credentials and permission scopes before changing routing or addressing.
C:Receiving HTTP status codes from the server is itself evidence that a request reached an HTTP processing component. A pure lack of network connectivity would typically produce timeout, connection refusal or transport errors rather than a meaningful HTTP authentication/authorization response. Distinguish transport reachability from access policy.
Question 679
A faulty script used `POST /api/v1/devices` on a collection to check device state and accidentally created duplicate entries. It has been changed to a read-only operation. Which test proves the misuse has been corrected?
- A POST returns HTTP 201 Created and a Location header for another new device object.
- The script reports HTTP 401 because the bearer token is missing, without showing any successful GET.
- A trace shows `GET` to the intended existing resource, a successful read response with expected fields, and no new resource IDs or collection-size change.
- The server shows a valid JSON body for a new resource, but the request still uses POST on the collection.
Explanation
Correct Answer
C:The original defect was invoking a mutating collection operation for a read. Verify the actual HTTP method and resource URI, the returned representation, and absence of side effects. HTTP 200 is typical for a successful GET but status alone is not sufficient without confirming the method.
Incorrect Answers
A:That directly reproduces the unintended creation rather than proving a safe read.
B:An authentication failure does not prove correct read method or payload access.
D:Valid encoding does not change the semantics of a mutating request.
Question 680
A device-management API responds to `POST /sites/9/devices` with HTTP 201 Created, `Location: /sites/9/devices/481`, and a JSON body containing `id: 481`. Which check best verifies the specific resource creation rather than only the JSON syntax?
- Validate that the JSON body has balanced braces, without checking its values or server state.
- Check only that the request used POST, ignoring response status and the created resource URI.
- Confirm the automation tool is installed on the workstation, even if no HTTP request was sent.
- Follow the returned resource URI using an authorized GET and confirm ID 481 and expected attributes exist.
Explanation
Correct Answer
D:HTTP 201 Created together with a Location URI and returned ID is the expected creation response in this example. A subsequent authorized GET to `/sites/9/devices/481` can verify that the server now exposes that exact object and its expected attributes. This closes the distinction between a successful-looking response and the persisted resource state. Do not assume every API returns Location or supports immediate read-after-write consistency: follow the documented contract and handle asynchronous provisioning if the API specifies it. Here the response explicitly provides a URI and the requested acceptance check is to confirm the new object's identity, not merely parse its JSON. Keep the authenticated GET under the correct tenancy/site scope.
Incorrect Answers
A:Valid JSON syntax is necessary for parsers but does not prove the server created the desired resource. A JSON object can be syntactically valid yet contain an error message, stale identifier or incorrect attributes. The response already reports a concrete creation status and Location header; verification should inspect the actual resource the server claims was created. Syntax-only checks are too shallow for the acceptance criterion.
B:HTTP POST is often used to request creation, but the method alone cannot show what happened. A POST can fail validation, be unauthorized or return a transient response. HTTP 201 and a returned URI are strong indications of creation, but the question asks to verify the resource and its identity, so the client should inspect the created object rather than infer success from request metadata alone.
C:The presence of Ansible, Terraform or another client on an operator's machine is unrelated to whether this REST service accepted a particular POST. A local tool may be fully installed yet fail network transport, authentication, input validation or server-side processing. The objective is to validate resource ID 481 in the service, not the workstation's software inventory.
