4.0 Infrastructure Services
Device Management Access Practice Questions
SSH prerequisites/versions, VTY hardening, SCP, and TFTP-based file transfer.
One solved question, so you can see how these are marked
SSH access to a router succeeds from hosts on the local LAN but is refused from a separate management subnet. The routing table shows a valid path in both directions, and the SSH server is confirmed enabled. The VTY lines carry access-class MGMT in. Where should troubleshooting focus next?
Whether the MGMT ACL actually permits the source addresses used by the management subnet
With routing confirmed and SSH already working from one subnet, the most likely remaining gate is the access-class ACL applied inbound on the VTY lines. If that ACL does not explicitly permit the new subnet's source range, connections from it will be silently dropped even though the service itself is healthy.
Every question in the set below is marked like this. The answers stay hidden until you pick one.
All 29 Device Management Access questions in this set
Answers and explanations appear when you work through the set above.
For day-to-day interactive device administration, which remote access protocol should be used in place of Telnet?
- SSH
- TFTP
- SNMPv2c
- NTP
A team wants to copy configuration and image files to and from Cisco IOS XE devices with the transfer encrypted end to end, riding on the same SSH session used for management. Which protocol fits this requirement?
- SCP
- TFTP
- RIP
- LDP
A router can successfully ping a TFTP server, yet an attempt to back up the running configuration to that server fails. What is the most plausible explanation, given that basic IP connectivity is already confirmed?
- The BGP local preference toward the server is set too low
- UDP transport to the TFTP service is being blocked somewhere in the path, or the file path/permissions on the server are wrong
- The OSPF router ID conflicts with another device
- The router has no MPLS label bound for the destination
A router has a locally defined username and the VTY lines are set to transport input ssh, but no RSA key pair has ever been generated on the device. What is the practical result?
- SSH sessions cannot be established until a suitable RSA (or other supported) key is generated on the device
- SSH will fall back automatically to using the enable secret as the key material
- Telnet will silently be used instead, ignoring the transport input setting
- The VTY lines will accept connections but skip authentication entirely
Generating an RSA key pair for SSH on a router fails because two pieces of basic device identity have not been configured. Which two are required first?
- A hostname and an IP domain name
- A loopback interface and a static route
- An NTP server and a time zone
- A banner message and an enable secret
Clients attempting to connect only use SSHv2, but show ip ssh reports the router is currently restricted to SSH version 1. What is happening?
- The router's configured SSH version and the clients' SSHv2-only requirement are incompatible, so those connections will fail
- SSHv1 and SSHv2 clients are always interoperable regardless of the configured version
- The mismatch only affects file transfer, not interactive login
- SSH version has no bearing on which clients can connect
VTY lines currently use login with only a shared line password configured, but the requirement is for each administrator to authenticate with their own local username and password over SSH. What change accomplishes this?
- Replace login with login local on the VTY lines, and ensure local username/password accounts exist
- Add access-class in to the VTY lines
- Change transport input from ssh to all
- Configure a longer line password to strengthen the existing scheme
A firewall in the path allows ICMP to reach a router but blocks TCP port 22. What symptom would this produce for an administrator trying to manage the device?
- Pings to the router succeed, but SSH connection attempts fail or time out
- SSH succeeds but pings fail
- Both ping and SSH fail identically
- SSH succeeds but falls back to an unencrypted session
An administrator tries to initiate an outbound SSH session from a router and receives '% SSH connections not permitted from this terminal.' Which line-level setting is the likely cause?
- transport output does not include ssh on the line being used to initiate the session
- The VTY access-class ACL is denying the outbound attempt
- The router's RSA key has expired
- IP domain lookup is disabled globally
Which command lists the SSH sessions currently connected to the device?
- show ssh
- show ip ssh
- show users
- show line vty
Which command confirms the SSH server's configured version and key information on a router?
- show ip ssh
- show ssh
- show crypto key mypubkey rsa detail
- show line summary
Which command shows which users are currently logged into a router and which console/VTY line each session is using?
- show users
- show ssh
- show line summary
- show ip ssh
Which file-transfer protocol rides on the SSH subsystem to provide encrypted copy operations to and from IOS/IOS XE devices?
- SCP
- TFTP
- FTP
- HTTP
Why is TFTP a poor choice compared to SCP for backing up configuration files over a network that cannot be fully trusted?
- TFTP has no encryption or authentication, while SCP inherits SSH's encrypted, authenticated transport
- TFTP cannot transfer files larger than 64KB under any circumstance
- TFTP requires a Cisco Catalyst Center license to operate
- TFTP only supports IPv6 destinations
A router can successfully resolve the hostname of a remote file server via DNS, yet a copy operation to that server still fails. What should still be verified?
- IP reachability to the resolved address, whether the required transport (UDP for TFTP, TCP/SSH for SCP) is permitted, and that the server-side path and permissions are correct
- Whether the router's hostname matches the server's hostname exactly
- Whether OSPF has converged on every link in the topology
- Whether the file being copied uses a .bin extension
A device is completely unreachable for remote management, but an administrator with physical or terminal-server access to the console port can still log in normally. What does this indicate about where to focus troubleshooting?
- The problem lies in the VTY/remote-management path (network reachability, ACLs, or transport settings), not in the device's console line itself
- The device's IOS image is corrupted
- The enable secret has been changed
- The console line's speed setting has drifted from the default
After a recent ACL change on the VTY lines, Telnet connections are refused but SSH connections continue to work normally. What is the most likely explanation?
- The updated ACL is blocking TCP port 23 while still permitting TCP port 22
- SSH bypasses VTY access-class filtering entirely
- Telnet requires a separate RSA key that was never generated
- The VTY transport input setting only supports one protocol at a time regardless of ACL content
Which command displays a router's logging configuration along with the contents of its local logging buffer?
- show logging
- show running-config | section logging
- show buffers
- show memory logging
Which transport and port should be permitted through any intermediate filtering device for messages to reach a traditional (non-TLS) syslog server?
- UDP port 514
- TCP port 514
- UDP port 162
- TCP port 22
Local buffered logging is working fine and shows the expected messages, but a configured remote syslog server never receives anything at all. What foundational fact about IOS logging behavior explains this?
- Logging to a remote host is not active by default; it must be explicitly enabled with the appropriate logging host configuration
- Remote logging automatically disables itself if the buffer is more than 50 percent full
- Remote syslog requires IPv6 connectivity even on an IPv4-only network
- The router can only log to one destination at a time, and the buffer takes priority
Remote syslog trap logging is set to the warnings severity level. Will messages at the errors and critical severity levels also be forwarded to the server?
- Yes, syslog severity thresholds are inclusive of all more severe levels above the configured threshold
- No, only messages tagged exactly warnings are ever sent
- Only critical is sent; errors is excluded because it is numerically adjacent
- It depends on whether the buffer size has been increased
Console logging severity is set to informational. Will debugging-level (severity 7) messages show up on the console?
- Yes, debugging is automatically included whenever informational is set
- No, debugging is a less severe (higher-numbered) level than informational, so it falls outside that threshold and will not display
- Only if terminal monitor has also been issued
- Only if the logging buffer has been resized
An administrator connected over SSH enables monitor-level logging but still sees no real-time syslog messages appear in that session. What command is most likely missing?
- terminal monitor
- logging synchronous
- service timestamps log datetime msec
- logging console
On a router with heavy logging activity, older entries in the local logging buffer are being lost even though nobody cleared them manually. Why does this happen?
- The logging buffer is a fixed-size, in-memory ring; once full, new messages overwrite the oldest existing entries
- The buffer automatically clears itself every 24 hours regardless of size
- A reload silently occurred without visible console output
- Debug-level messages are given priority and purge all other severities
Which change would help retain a longer history of locally logged events on a router that is losing older buffered messages too quickly?
- Increase the logging buffered size, or send logs to a remote syslog server for longer-term retention
- Lower the logging trap severity threshold on the console line
- Disable service timestamps to reduce message size
- Switch the buffer from RAM to NVRAM automatically at boot
A router is correctly configured with a logging host pointing at a real syslog server, but that server is currently powered off. What is the expected outcome?
- Remote syslog delivery fails for as long as the server is unreachable, though local buffered logging continues unaffected
- The router automatically queues messages and delivers them all once the server returns
- Local logging also stops until the remote server is reachable again
- The router falls back to sending messages over SNMP traps instead
An ACL somewhere along the path denies UDP port 514 traffic destined for the syslog server's address. What is the resulting impact on logging?
- Remote syslog messages are blocked from reaching the server, while local buffered and console logging remain unaffected
- All logging, including the local buffer, stops immediately
- The router automatically switches remote logging to TCP port 514
- Only debug-level messages are affected; other severities still reach the server
Why might a network engineer deliberately use conditional debugging (scoping debug output to a specific interface, interesting traffic condition, or protocol event) rather than enabling debugging broadly on a production router?
- To limit debug output to only the relevant events, reducing console/CPU load and avoiding an overwhelming flood of unrelated messages
- Because unconditional debugging is disabled by default on IOS XE and cannot be re-enabled
- To bypass control-plane policing rate limits entirely
- Because conditional debugging replaces the need for any logging configuration
Two administrators both connect to a router, one over the console port and one over SSH via a VTY line, at the same time. What is generally true about how these two access paths are secured and managed?
- They are governed by separate line configurations, so authentication methods and timeouts can differ; VTY access can additionally use an access-class to filter remote source addresses
- Console and VTY lines always share one identical configuration and cannot be set independently
- Only the VTY lines support username-based authentication; the console line only ever supports a line password
- The console line is automatically disabled whenever any VTY session is active