Skip to content
Log in Sign up My account

Infrastructure Services Practice Questions

15 original questions covering ENARSI 4.1 to 4.7. Answer every one before opening any explanation. Target: 12 of 15 (80%). These do not repeat the domain 4.0 questions in ENARSI Bank Part 2, so take both.


1. Blueprint 4.1 Refer to the exhibit. An administrator connects to R7 with SSH and logs in successfully, then types enable. What is the cause of the result shown, and what fixes it?

R7>enable
% No password set
R7>
username netops secret Adm1nPass
line vty 0 15
 login local
 transport input ssh
  • A. The VTY lines need transport input ssh telnet
  • B. SSH version 2 is required for privileged EXEC access
  • C. No enable secret is configured; add enable secret, or give the user privilege 15
  • D. The user needs login authentication default under the VTY lines
Answer: C

Over a VTY line, IOS refuses to enter privileged EXEC when no enable password or secret exists, and prints % No password set. Either configure enable secret, or change the user to username netops privilege 15 secret ... so that login local places them straight into privileged EXEC. A changes which protocols are accepted, which is irrelevant because the login already succeeded. D needs AAA, which is not configured. B is unrelated to privilege levels.


2. Blueprint 4.1 Refer to the exhibit. Administrators on 192.168.100.0/24 reach R4 through its management port GigabitEthernet0, which is in VRF Mgmt-intf. SSH sessions to the management address are refused, while SSH to R4's loopback in the global table from the same subnet works. What is the most likely fix?

ip access-list standard MGMT
 permit 192.168.100.0 0.0.0.255
line vty 0 15
 access-class MGMT in
 login local
 transport input ssh
  • A. Add ip vrf forwarding Mgmt-intf under the VTY lines
  • B. Change the line command to access-class MGMT in vrf-also
  • C. Add ip ssh source-interface GigabitEthernet0
  • D. Change the ACL to an extended ACL that permits TCP 22
Answer: B

Without vrf-also, an inbound access-class only permits sessions arriving in the global routing table, so sessions from a VRF interface are refused. Adding vrf-also applies the same ACL to VRF sessions. A is not a line command. D is not needed, because a standard ACL already matches the source. C changes the source of outbound SSH sessions from R4, not inbound access.


3. Blueprint 4.1 Refer to the exhibit. The TFTP server at 192.168.100.60 accepts uploads only from router loopback addresses in 10.255.255.0/24. R6 can ping the server. What should be changed?

R6# copy running-config tftp://192.168.100.60/R6.cfg
Address or name of remote host [192.168.100.60]?
Destination filename [R6.cfg]?
.....
%Error opening tftp://192.168.100.60/R6.cfg (Timed out)
  • A. Configure ip tftp source-interface Loopback0 on R6
  • B. Configure ip scp server enable on R6
  • C. Configure transport output all on the console line
  • D. Configure tftp-server flash:R6.cfg on R6
Answer: A

Without a source-interface setting, the TFTP request is sourced from R6's exit interface toward the server, which is not in the permitted loopback range, so the server ignores it and the router times out. Pinging the server proves reachability but uses the same exit address, so it does not prove the server accepts R6. B enables R6 as an SCP server, which does not affect a TFTP upload. C controls outbound terminal sessions. D makes R6 serve a file by TFTP, which is the opposite direction.


4. Blueprint 4.2 SNMPv3 polling of R2 worked for months. During a hardening change, an engineer configured snmp-server engineID local 00000009020000AABBCCDD. Since then, every SNMPv3 request from the NMS fails, although the group, user names and passwords have not changed. What is the fix?

  • A. Change the group security level from priv to auth
  • B. Configure snmp-server enable traps
  • C. Add the users to the running configuration with username commands
  • D. Re-create the SNMPv3 users with their passwords
Answer: D

SNMPv3 user keys are localized using the local engine ID. Changing the engine ID makes the stored keys invalid, so authentication fails for every user. Re-entering each snmp-server user command regenerates the keys against the new engine ID. A weakens security and does not fix the key mismatch. B concerns notifications, not polling. C creates local login users, which SNMP does not use.


5. Blueprint 4.2 Refer to the exhibit. The NMS reads interface counters from R3 without problems, but every attempt to change an interface description through SNMP fails. Which counter explains the failures, and what is the cause?

R3# show snmp | include PDUs|community|altered
    0 Unknown community name
    27 Illegal operation for community name supplied
    0 Number of altered variables
    5530 Get-request PDUs
    1103 Get-next PDUs
    27 Set-request PDUs
  • A. Unknown community name; the NMS is using the wrong community
  • B. Get-next PDUs; the NMS is walking the wrong MIB
  • C. Illegal operation for community name supplied; the NMS sends Set requests with a read-only community
  • D. Number of altered variables; the agent is out of memory
Answer: C

27 Set requests arrived and 27 illegal-operation errors were counted, while no variables were altered. That is the signature of Set requests using an RO community (or one whose view does not allow the write). Use a separate RW community, ideally limited by an ACL, or move to SNMPv3 with a group write view. A would show a rising unknown community count and reads would fail too. B and D do not match the numbers.

Free account required for the rest

This page has 15 questions and the first 5 are shown here. You're seeing a free sample. A free account unlocks everything: every question bank, the timed exams, the cram sheets, the simulations and the lab files.

Create a free account Log in