server-administration practice questions

Load balancing

Why wrong: Load balancing distributes network traffic across multiple servers but does not automatically fail over if a server goes down; it may route traffic to a failed server if health checks are not configured.

Scheduled backups

Why wrong: Scheduled backups protect data but do not ensure application availability; recovery from backup typically incurs significant downtime.

RAID 1 mirroring

Why wrong: RAID 1 provides disk redundancy but does not automatically fail over the server itself; manual intervention would be required to bring the backup server online.

Enable default administrative shares

Why wrong: Default administrative shares (such as ADMIN$) are often targeted by attackers; they should be disabled if not needed.

Allow all inbound ICMP

Why wrong: Allowing all ICMP traffic can expose the server to ping floods and help attackers map the network.

Use telnet for remote CLI

Why wrong: Telnet transmits data, including credentials, in cleartext and is considered insecure; SSH should be used instead.

Disable DFSR and use robocopy with /MIR /COPYALL during the cutover window to copy all data

Why wrong: Robocopy copying 2 TB over the network will likely exceed the four-hour window and cause user disruption.

Perform a full backup of the old server and restore to the new server during the cutover window using Windows Backup

Why wrong: Full backup/restore of 2 TB over the network or locally will likely take longer than four hours, and may not preserve open file states.

Increase the DFSR staging quota and bandwidth throttling to accelerate initial replication

Why wrong: Tuning settings cannot make initial replication of 2 TB complete in four hours; the data volume is too large.

RAID 5

Why wrong: RAID 5 uses parity and requires at least three disks; it is often used for data volumes, but has write performance overhead.

RAID 6

Why wrong: RAID 6 uses double parity and requires at least four disks; it is overkill for an OS drive and reduces write performance.

RAID 0

Why wrong: RAID 0 stripes data with no redundancy, so a single disk failure causes data loss.

Perform a tail-log backup before each full backup

Why wrong: Tail-log backups are used for point-in-time recovery after a failure, not as a regular strategy to manage log growth.

Perform daily differential backups

Why wrong: Differential backups reduce time but still require a full backup; they don't control log growth.

Perform hourly copy-only backups

Why wrong: Copy-only backups do not truncate the transaction log, so they do not help manage log growth.

Update the server's BIOS to the latest version

Why wrong: BIOS updates rarely address random reboots unless a known bug exists, and this should not be the first step.

Replace the power supply unit

Why wrong: A failing PSU might cause reboots, but the UPS report suggests stable power; other symptoms like log errors would appear.

Disable the automatic restart feature in System Properties

Why wrong: This would only prevent the server from rebooting after a crash, but the underlying issue would remain, leading to possible data corruption.

Restart the Windows Server 2022 server to apply any pending policy changes.

Why wrong: Restarting does not assign the missing 'Log on as a service' right; the right must be explicitly granted before the service can start.

Configure the application to use a dynamic port instead of the static port 8443.

Why wrong: The application is designed to use a static port; changing to a dynamic port would likely break client connectivity and is not a proper fix for the logon failure.

Reset the service account password and update the service configuration.

Why wrong: The password was already verified correct, so resetting it is unnecessary and would not fix the missing 'Log on as a service' right.

Full backup daily, differential backup every hour

Why wrong: Hourly differential backups include all changes since the last full, growing larger each hour and extending backup windows.

Full backup weekly, differential backup every hour

Why wrong: Combining weekly fulls with hourly differentials results in increasingly large differentials that consume excessive storage and time.

Full backup weekly, incremental backup every hour

Why wrong: A weekly full with hourly incrementals may force restoration of many incrementals, potentially exceeding the 4-hour RTO.

The Nginx service is not running.

Why wrong: If Nginx were down, it would not log this error; the reverse proxy must be operational to generate the entry.

The firewall on the reverse proxy is blocking port 80.

Why wrong: A firewall block would typically result in a timeout, not an immediate connection refusal from the upstream server.

The client's DNS cannot resolve example.com.

Why wrong: The error occurs at the backend connection level, long after client DNS resolution has succeeded.

DHCP Server service

Why wrong: DHCP is not related to file services but could be needed in some configurations; disabling it is not universally required.

Server service

Why wrong: The Server service enables file and printer sharing; disabling it would break file server functionality.

DNS Server service

Why wrong: This service may be required if the server hosts DNS; it is not automatically a security risk if properly secured.

Delete log files in /var/log.

Why wrong: While it frees space, it might not free enough, and removing logs hampers troubleshooting and auditing.

Resize /dev/sda1 to 30G.

Why wrong: Resizing requires unmounting or rebooting and is not a quick solution; also, the root partition may be LVM-based or not easily extended online.

Change the RAID level of /dev/sda.

Why wrong: RAID level changes are unrelated to free space management and could introduce additional I/O load or data loss risk.

Full Control

Why wrong: Full Control would require both share and NTFS to allow it; NTFS restricts it to Read & Execute.

Write

Why wrong: NTFS does not grant Write; it is denied at the file system level, so the user cannot write.

No Access

Why wrong: No Access only results if an explicit Deny permission is set, which is not the case here.

The last DROP rule blocks all traffic, including established SSH sessions.

Why wrong: The last DROP rule blocks traffic, but the earlier ACCEPT for RELATED,ESTABLISHED allows return packets of existing connections, so this does not explain new SSH failure.

The default INPUT policy is set to ACCEPT, allowing all traffic.

Why wrong: A default ACCEPT policy does not override an earlier DROP rule; the DROP for SSH still takes effect.

The ACCEPT rule for port 22 is missing the ESTABLISHED state, preventing return traffic.

Why wrong: The ACCEPT rule uses state NEW, which is fine; the RELATED,ESTABLISHED rule permits return traffic. The problem is the order.

Use Telnet with SSH tunneling.

Why wrong: Telnet transmits data in cleartext, and SSH tunneling does not secure the Telnet protocol itself; it only encrypts the tunnel, but the underlying Telnet session remains vulnerable.

Use VNC with a strong password.

Why wrong: VNC is primarily a graphical desktop sharing tool and is not as secure or efficient as SSH for server administration tasks.

Use RDP with certificate-based authentication.

Why wrong: RDP is not commonly used for Linux server remote administration; it is more suited for Windows environments.

Add more virtual CPUs to the server's VM.

Why wrong: Adding vCPUs does not address CPU scheduling contention; the intensive task could still starve other processes.

Move the database to a server with faster CPU cores.

Why wrong: Faster CPUs might improve performance, but if the task is highly demanding, it could still cause contention during peak times; this is not the most direct or efficient solution.

Configure processor affinity to dedicate a core to the database process.

Why wrong: Processor affinity limits which CPU cores a process can run on, but it does not lower the process's priority or guarantee responsiveness for other applications.

Configure each web server to store sessions locally and use sticky sessions on the load balancer.

Why wrong: Sticky sessions bind a client to a single server, so if that server fails, the session is lost; also, servers do not share session data, so consistency is not guaranteed.

Use round-robin DNS to distribute traffic.

Why wrong: Round-robin DNS simply rotates IP addresses; it does not maintain session state or ensure users are directed to the same server after initial connection.

Implement database session storage with synchronous replication between servers.

Why wrong: Synchronous database replication can cause significant write latency, negatively impacting web application performance, especially under load.

logrotate -f /etc/logrotate.conf to force log rotation.

Why wrong: Forcing log rotation may not succeed if the disk is already full or the rotation mechanism is broken; truncation provides an immediate, reliable fix.

rm -rf /var/log/large.log to delete the file.

Why wrong: Deleting the file does not release disk space if any application still has the file open; space is only reclaimed when all file handles are closed.

mv /var/log/large.log /backup/ to move the file.

Why wrong: Moving the file to another location creates the same problem as deletion: the original process may still write to the old inode, so space is not freed immediately.

The database service is stopped.

Why wrong: If the database service is down, the backup tool would report a connection failure, not an access denied error.

The command-line tool is not installed.

Why wrong: A missing tool typically results in a 'command not found' or executable not recognized error.

The backup destination is full.

Why wrong: A full disk would cause a write error or disk space shortage message, not an access denied error.

Use Windows Memory Diagnostic tool to try to isolate the memory region and prevent the application from using it.

Why wrong: Windows Memory Diagnostic runs at boot and cannot dynamically restrict physical memory usage; the system would still attempt to use the faulty DIMM, risking another crash.

Continue running the server as is, as ECC memory can correct errors and the server will only crash if errors are uncorrectable; the risk is low.

Why wrong: The server has already experienced crashes, proving that uncorrectable errors have occurred. Relying solely on ECC is dangerous as it can lead to data corruption and additional unplanned downtime.

Immediately shut down the server, replace the faulty DIMM, and restart.

Why wrong: This action would abruptly halt the financial report processing, potentially causing data loss and missing the deadline, without following proper change control.

Replace all four drives with larger capacity drives to expand storage.

Why wrong: Expanding storage is not the immediate concern; replacing all four drives would be costly and time-consuming, and not required for a single drive failure.

Reboot the server and enter the RAID controller BIOS to mark the drive as offline.

Why wrong: A reboot is unnecessary and causes downtime; the failed drive is likely already marked as offline by the controller, and hot-swapping does not require a reboot.

Perform a full backup of the array before taking any action.

Why wrong: While backups are important, the priority is restoring redundancy; the array is still accessible and can be backed up, but delaying drive replacement increases risk of another failure.