Cisco Certified Network Associate (CCNA) 200-301 Practice Test 69
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.
Question 681
A network engineer needs to push the same NTP server configuration to 24 existing IOS switches using SSH from a central runner, without installing a dedicated resident agent on each switch. Which workflow fits?
- Define the 24 switch targets and credentials in an Ansible inventory, run an authorized network playbook over the supported SSH connection, and inspect device results.
- Create cloud subnets with a Terraform provider and assume this alone changes the NTP running configuration on existing switches.
- Install a daemon named Ansible Agent on each IOS switch as a mandatory prerequisite for all Ansible network modules.
- Manually SSH into only one switch and copy the NTP line, leaving the other 23 unmanaged.
Explanation
Correct Answer
A:Ansible network automation commonly uses inventory, network connection plugins and idempotent modules to manage existing devices over a remote transport. The target devices need reachable credentials and supported modules rather than an Ansible resident service installed on every switch.
Incorrect Answers
B:A cloud resource plan does not automatically reach and configure the specified IOS devices.
C:Ansible is designed for agentless remote execution, including supported network devices.
D:The requirement explicitly covers a known fleet and repeatable centralized execution.
Question 682
A team manages 25 cloud-hosted virtual network resources with Terraform. Before approving a change, it must compare declared configuration with tracked state and observed infrastructure, identify resources to add/change/destroy, and avoid applying the change until reviewed. Which workflow fits?
- Run `terraform destroy` first to remove drift, then inspect the plan of whatever remains.
- Use `terraform plan` with appropriately refreshed state, review the proposed resource actions, and run `terraform apply` only after approval.
- Run an Ansible `ping` task against every device and assume it reveals cloud-resource create/delete actions.
- Edit the Terraform state file manually to hide resources that no longer match the desired configuration.
Explanation
Correct Answer
B:Terraform records managed resource information in state and generates a plan that compares desired configuration with the provider-observed resources and relevant state. A reviewed `terraform plan` describes proposed adds, updates and deletions before modifying infrastructure, permitting an operator to identify accidental destruction or replacement. After validating the intended changes, policies and dependencies, apply the approved plan with appropriate controls. State should be protected, access-controlled and consistent with the workspace's backend; drift may require inspection and reconciliation rather than blind action. A plan is a forecast, not proof the eventual deployment succeeded, so confirm resources after apply as a separate acceptance step.
Incorrect Answers
A:`terraform destroy` intentionally plans removal of managed resources and is not a safe generic drift-repair step. It can cause widespread outages and data loss if issued before review. The requirement is to see proposed changes and obtain approval before modifying infrastructure, so inspect a non-destructive plan first.
C:Ansible connectivity tests can establish that selected hosts are reachable through a supported connection plugin, but they do not provide Terraform's provider-aware desired-state plan for cloud resources. A successful ping or simple task cannot reveal which virtual networks Terraform intends to create, replace or delete.
D:Directly editing a Terraform state file to conceal drift can sever the correspondence between tracked objects and live resources, causing dangerous future plans. State is an operational record requiring controlled manipulation through supported tooling. Review observed drift and intended configuration rather than pretending unmanaged differences have disappeared.
Question 683
An Ansible job manages an IOS extended ACL. The first run installs one approved permit entry. On every later run the job blindly appends another identical permit line, changing the device configuration repeatedly. Which design change achieves idempotence?
- Always issue `no access-list` for the entire ACL before every run, even when it is already correct, and call any repeated disruption idempotent.
- Use a state-aware module or compare the existing ACL before updating it so a second execution with unchanged desired input makes no additional change.
- Change the inventory file name on each run so the same target appears new to automation.
- Verify a Terraform plan for an unrelated cloud VM, without inspecting the switch ACL state.
Explanation
Correct Answer
B:Idempotence means applying the same desired configuration again leaves an already-converged device unchanged. Test both the reported change status and the actual ACL contents after consecutive runs; blindly appending text is not state-aware convergence.
Incorrect Answers
A:Deleting and reinstalling an already-correct ACL is not the minimal non-changing behavior requested and can interrupt traffic.
C:Renaming an inventory file does not prevent duplicate device ACL entries.
D:An unrelated infrastructure plan cannot establish repeat convergence of this IOS access rule.
Question 684
An operations team already manages a fleet of IOS switches. It needs to enforce interface descriptions and NTP settings by SSH using repeatable tasks and device inventory, not create cloud virtual machines or network resources. Which tool model best suits this existing-device configuration problem?
- Ansible network automation with inventory, suitable network connection plugin and idempotent configuration modules.
- Terraform infrastructure provisioning alone without a supported provider to reach and configure these IOS devices.
- A local DNS cache flush script, because DNS entries are the source of the interface-description configuration.
- A packet generator sending random UDP datagrams to switch management IPs instead of authenticated configuration commands.
Explanation
Correct Answer
A:Ansible can apply repeatable desired configuration to a known inventory of existing network devices using supported connection methods and network modules, including SSH-based network CLI where appropriate. The stated work is modifying settings on already deployed IOS switches, so device-specific configuration enforcement and idempotence are relevant. Validate host groups, credentials, module/platform support, planned differences and post-change running configuration. Terraform can manage certain network platforms through appropriate providers, so the distinction is not that Terraform is categorically incapable; it is that this scenario explicitly requests existing-switch CLI configuration tasks using inventory, where Ansible's network automation workflow is a direct fit. Do not perform an unreviewed fleet-wide push.
Incorrect Answers
B:Terraform is a powerful declarative infrastructure tool when an appropriate provider supports the target resource, but the proposed option explicitly lacks a provider capable of configuring the IOS devices. It therefore cannot achieve the described SSH CLI changes by itself. Use a tool and connection plugin with confirmed reachability to this specific platform.
C:DNS cache management can help resolve stale hostname lookup information, but switch interface descriptions and NTP server commands are device configuration state, not records created by a resolver cache. Flushing DNS does not install authorized settings on a fleet of existing IOS switches or verify their actual running configuration.
D:Unstructured UDP probes neither authenticate to management services nor express idempotent device configuration actions. A switch might ignore them, log them, or treat them as unrelated traffic. The requirement calls for controlled, auditable configuration enforcement over a supported management interface using planned changes and verification.
Question 685
A network automation job should apply an approved SNMP setting to the `[branch_switches]` inventory group. The playbook completes with no failed hosts, yet all 14 branch switches remain unchanged. Its run command used `--limit campus_switches`, and the recap lists only campus device names. Which defect explains the apparently successful but incomplete deployment?
- A non-idempotent configuration task appended duplicate SNMP lines on every branch switch.
- Terraform state drift proposed deletion of switch objects during a plan operation.
- The Ansible inventory limit selected the wrong host group, so the intended branch devices were never targeted.
- The Ansible connection plugin negotiated an unsupported network API on all 14 branch devices.
Explanation
Correct Answer
C:The CLI limit `--limit campus_switches` restricts execution to a group different from the approved `[branch_switches]` target. The recap showing only campus names confirms the tasks completed on the wrong devices: `failed=0` is not evidence that intended branch switches were changed. Correct the inventory limit, preview selected hosts with `ansible-playbook --list-hosts`, then run the authorized playbook and verify the SNMP configuration on the 14 branch devices. This diagnoses an incorrect deployment target, not an unreachable device or a failed configuration command.
Incorrect Answers
A:A non-idempotent playbook can create repeated commands or entries when run multiple times, but this incident does not show such duplicates. The branch switches never appear in the recap, and the command targets a different inventory group, so their absence is explained before examining what tasks would do on them. Auditing idempotence becomes relevant after selecting the correct inventory group and successfully reaching those devices. First compare the intended `[branch_switches]` names with the hosts in `--list-hosts` and the final recap.
B:Terraform's state and plan logic concerns infrastructure it manages through provider resources. There is no evidence that Terraform was invoked or that its state file controlled this Ansible playbook. The playbook reports success for devices in the wrong inventory group, which cannot be fixed by modifying Terraform state. A successful Ansible run can still be operationally wrong if its host selection is wrong. Inspect the active inventory path, group definitions, and command-line limit before considering a separate tool's state and resource lifecycle.
D:An unsupported connection method would generally produce connection or task failures against the affected hosts rather than a successful recap containing only a different set of devices. The current evidence shows no branch hosts were selected at all, so the environment did not attempt the supposedly incompatible API on them. If errors appear after correcting the inventory group, then review `ansible_connection`, the network OS and collection plugins. But those are later checks; the explicit `--limit` mismatch is already sufficient to explain this incident.
Question 686
Terraform tracks a managed resource that the current approved configuration intentionally removed from desired state. `terraform plan` proposes destroying that still-existing resource. Which interpretation is consistent with declarative reconciliation?
- Terraform always deletes resources because the provider API is temporarily unreachable.
- Any resource shown in `terraform state` must remain forever regardless of configuration changes.
- The plan is a live IOS `show interfaces status` read-only diagnostic instead of a change proposal.
- The plan identifies an existing tracked resource absent from desired configuration, so it proposes deletion to converge infrastructure state.
Explanation
Correct Answer
D:Declarative reconciliation compares tracked infrastructure with the desired configuration. Removing a managed resource declaration can produce a destroy proposal; review the plan carefully before applying it.
Incorrect Answers
A:A provider outage normally produces refresh or planning errors and is not evidence that every resource should be destroyed.
B:A state entry alone does not make a resource permanently desired if the configuration removes its management declaration.
C:Terraform plans describe infrastructure changes, not the same read-only CLI reporting workflow as an Ansible operational command.
Question 687
A network script is rerun twice to ensure that ACL 120 contains exactly one approved permit line. After the second run, `show access-lists 120` shows the same permit command appended a second time, and the task output reports another change despite the desired state already being present. Which automation defect is demonstrated?
- The Terraform state database proposes deleting a managed VPC due to a provider refresh.
- An Ansible `--limit` expression omitted the intended switch inventory group.
- A network module cannot reach the switch because its SSH service is down.
- The script appends the ACL line without checking existing state, so repeat execution is not idempotent.
Explanation
Correct Answer
D:An idempotent configuration operation achieves the same final device state when repeated with identical desired inputs. The script appends a duplicate permit each time and reports a change despite already meeting the requested policy, so it violates that property. Replace blind line appends with a state-aware network module or explicit comparison that ensures exactly one correct ACE. Re-run the operation in a test environment and verify a second pass makes no changes and produces no duplicate entries. The paired item is specifically about this later acceptance evidence.
Incorrect Answers
A:Terraform state drift can produce unexpected create, update, or delete proposals during a plan, but this case describes a script directly appending duplicate Cisco ACL entries. There is no Terraform provider or infrastructure state involved. The repeated identical permit is evidence of an absent desired-state check in the command sequence. Inspect how the automation determines whether the ACE already exists before executing its configuration step, rather than editing unrelated state records.
B:An inventory filter that selects the wrong hosts can produce a successful automation run against unintended devices, but the question shows actual duplicate ACL lines on the target switch after two runs. The correct device was reached and altered, so host selection is not the immediate defect. Verify the inventory scope separately for safety, then inspect the script's update logic. The duplication indicates the command was issued even though the desired ACE was already present.
C:If SSH or an API transport were unavailable, configuration tasks would generally fail to reach the switch, and the new ACL line would not appear a second time as a consequence of that failed connection. Here the second execution succeeded in changing the device in an unintended way. The problem lies in deciding whether a change is required, not in establishing management transport. Confirm connection health if needed, but correct the script's state comparison before production use.
Question 688
A team needs to run a repeatable operational command against 20 already-provisioned IOS switches to collect `show interfaces status`. It launches a Terraform infrastructure plan instead of a network automation playbook and gets no operational CLI output. What is the tool-selection problem?
- The switches have a wrong OSPF router ID and cannot return interface status.
- The Terraform state file necessarily contains a planned resource deletion.
- Terraform declarative resource provisioning is being used where an Ansible operational playbook or suitable API/CLI automation is needed.
- Ansible cannot run read-only IOS show commands and is only for creating cloud virtual machines.
Explanation
Correct Answer
C:Terraform is primarily used to declare and converge infrastructure resource state. Gathering live operational CLI status from existing IOS devices is better addressed by an appropriate Ansible network task or other SSH/API collection tool.
Incorrect Answers
A:OSPF router IDs do not prevent reading local interface status through authenticated management access.
B:No state drift or deletion plan is presented; the failure is asking a provisioning workflow for a live operational diagnostic function.
D:Ansible includes network modules for executing IOS CLI show commands; it is not limited to VM provisioning.
Question 689
The operator fixes the Ansible inventory limit and reruns the authorized SNMP playbook against 14 branch switches. Which evidence best verifies that the intended devices were contacted and the first implementation run completed as expected?
- Ansible `--list-hosts` shows the 14 intended switches, the play recap reports those same hosts with `failed=0`, and a post-run configuration check finds the authorized SNMP settings on them.
- A Terraform `plan` reports no changes to an unrelated virtual-network resource.
- The configuration of one campus core switch matches the target, but the branch inventory is not checked.
- The second playbook run shows `changed=0`, without recording which devices were targeted on either invocation.
Explanation
Correct Answer
A:The acceptance evidence must link target selection, execution outcome, and device state. `--list-hosts` confirms the corrected inventory and limit would act on all 14 branch switches; the play recap verifies that those devices actually participated without task failures; and reading their resulting SNMP settings confirms desired state. A recap showing `changed` or `ok` is informative but not a substitute for verifying which hosts were in scope and what configuration they ended with. This deliberately tests completion evidence, unlike the earlier question that diagnoses the wrong inventory limit.
Incorrect Answers
B:Terraform plan output can be useful when the workflow manages provider resources and detects desired-versus-actual infrastructure differences. In this case, the required operation is an Ansible playbook against 14 existing switches, and an unrelated Terraform plan cannot establish playbook host selection, reachability, or SNMP configuration. It is possible for a Terraform plan to be clean while an Ansible inventory points to the wrong devices. The validation should follow the tool and the affected resources actually involved, not a separate automation system.
C:A core switch can have correct SNMP settings while every branch switch remains unchanged. That was precisely the failure mode: a successful run on the wrong inventory group. Checking only one campus device can create another false positive. The owner specified 14 branch devices, so the acceptance evidence must identify those hostnames and verify their configuration or representative audited state after the corrected playbook. An unrelated correctly configured switch is not evidence that the intended deployment scope was met.
D:A second run with `changed=0` is potentially useful evidence that configuration tasks are idempotent, but it does not prove the correct devices were ever targeted. An empty or wrong inventory group can yield a no-change result while the 14 branch devices remain untouched. To validate this change, first show the branch host selection, inspect the recap for those names, and verify actual SNMP state on them. Idempotence is a separate acceptance property; it should be checked after the first deployment has demonstrably reached the intended inventory.
Question 690
A Terraform configuration and its tracked state were reconciled after a plan unexpectedly proposed destroying an in-use network resource. Before anyone applies another change, which action most directly verifies that the unintended deletion is no longer proposed?
- Run `terraform apply -auto-approve` and assume the result is safe if no CLI error appears.
- Run an unrelated Ansible playbook and inspect only its `ok` task count.
- Run `terraform plan` and inspect the resource diff, confirming there is no unexpected `destroy` or replacement action for the live resource.
- Read `terraform output` values without checking the planned actions or tracked resource change set.
Explanation
Correct Answer
C:Terraform evaluates configuration against refreshed real-world state and tracks planned create, update, replace or destroy operations. An inspected `terraform plan` is the direct opportunity to catch or confirm removal of an unintended deletion proposal before applying.
Incorrect Answers
A:Blindly applying a plan that proposes resource deletion could cause an outage. The proper safe checkpoint is review of the planned diff before making modifications, not applying without operator inspection.
B:Ansible results describe that playbook and its managed tasks, not Terraform's resource graph or planned deletes. An Ansible `ok` result cannot validate a Terraform state correction.
D:`terraform output` reads declared output values and does not list every planned infrastructure change. It can remain unchanged even while a pending plan would destroy an unrelated resource.
