server-administration practice questions

Perform a tail-log backup before each full backup

Why it fails: 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 it fails: Differential backups reduce time but still require a full backup; they don't control log growth.

Perform hourly copy-only backups

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

Delete log files in /var/log.

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

Resize /dev/sda1 to 30G.

Why it fails: 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 it fails: RAID level changes are unrelated to free space management and could introduce additional I/O load or data loss risk.

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

Why it fails: 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 it fails: 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 it fails: The ACCEPT rule uses state NEW, which is fine; the RELATED,ESTABLISHED rule permits return traffic. The problem is the order.

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

Why it fails: 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 it fails: 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 it fails: 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.

Increase the VM's memory from 16 GB to 32 GB to reduce paging and improve performance

Why it fails: The issue is CPU-bound, not memory-bound; adding memory will not resolve the CPU bottleneck shown inside the VM.

Increase the VM's vCPU count to 8 to handle the workload and reduce contention

Why it fails: More vCPUs can worsen co-scheduling problems if the underlying issue is scheduler contention rather than raw capacity.

Check the host's overall CPU usage in Task Manager and increase the VM's vCPU count if the host has spare capacity

Why it fails: The host CPU is not saturated overall; adding vCPUs may increase scheduling overhead and contention without fixing the root cause.

Execute 'rm -rf /tmp/*' to clear temporary files and regain space

Why it fails: This may disrupt running processes that rely on files in /tmp and is not a thorough solution; logs are more likely to consume space.

Use 'find / -type f -size +100M -exec rm {} \;' to delete all files larger than 100MB

Why it fails: This is extremely dangerous because it may delete important application or system files without discrimination.

Extend the root logical volume by 10 GB using 'lvextend' and then resize the filesystem with 'resize2fs'

Why it fails: While feasible, this is a reactive measure that doesn't address the accumulation of unnecessary files and might encourage poor storage hygiene; cleaning up first is best practice.

Upgrade the tape library to use multiple tape drives for parallel backups and rotate tapes offsite daily

Why it fails: Parallel drives can improve speed but do not reduce the daily data volume; offsiting tapes is manual and risky.

Switch to synthetic full backups combined with incremental forever; store backups locally on disk

Why it fails: Synthetic fulls can reduce backup time but still require a full pass of changed data; offsite copy is not addressed.

Continue weekly fulls but perform daily incremental backups instead of differentials; keep tapes on-site

Why it fails: Incrementals would be faster but the full backup still takes 12 hours and offsite requirement is not met.

Use a script to stop and start the application pool service every hour

Why it fails: Frequent restarts would cause constant interruptions to users and are less efficient than condition-based recycling.

Increase the physical RAM to 64 GB and raise the private memory limit to 4 GB

Why it fails: This only delays the inevitable recycling and does not address the memory leak; the pool will still eventually hit the limit.

Schedule a nightly reboot of the server to clear memory and reset the application pool

Why it fails: This would cause downtime each night and is not an optimal solution compared to targeted pool recycling.

The teaming mode is set to 'Switch Independent' instead of LACP

Why it fails: The scenario explicitly states LACP is being used; if it were Switch Independent, the team would not require LACP and would handle failover differently, but this contradicts the given information.

Spanning Tree Protocol is blocking the failover path

Why it fails: STP might temporarily block a port during topology changes, but it would not consistently cause loss of all connectivity after a NIC failure in a properly configured LACP team.

NIC driver version mismatch between the two adapters

Why it fails: While a mismatch could cause instability, it typically does not result in complete loss of connectivity during a failover event if LACP is properly configured.

Add more RAM to the server.

Why it fails: More RAM could help overall, but the immediate bottleneck is that the query cache is turned off, not insufficient memory.

Rebuild all indexes on the database tables.

Why it fails: Index maintenance may improve some queries but does not enable the query cache, which is the immediate issue.

Enable the slow query log to identify inefficient queries.

Why it fails: This is a diagnostic step, not a performance fix; the low cache hit ratio directly points to query_cache_size.

Delete the current /home logical volume and create a new one from the snapshot, then restore the data using `dd if=/dev/vg_users/home_snap_20250101 of=/dev/vg_users/lv_home`.

Why it fails: Using dd in this manner can lead to data corruption if the snapshot is not the exact same size as the original, and it circumvents LVM tools, introducing unnecessary risk.

Create a new logical volume from the snapshot using `lvconvert --splitsnapshot`, mount it, and restore only user123's directory, then update /etc/fstab to use the new volume.

Why it fails: This unnecessarily creates a new volume, complicating the restoration and requiring fstab updates, and may not restore the entire /home directory correctly.

Mount the snapshot volume to /mnt/snap, copy the entire contents back to /home using `cp -a /mnt/snap/* /home/`, then unmount the snapshot and remove it.

Why it fails: Manual copy is possible but not the most efficient or risk-free method; permissions and hidden files may not be perfectly replicated, and it requires more steps and time.

Alice's user token was not updated after her OU move; she needs to log off and log back on to obtain the new group membership, but the token hadn't expired. The administrator should wait or force logoff.

Why it fails: Effective permissions check would reflect current token; since it shows Read, the token is likely updated. Additionally, other Sales members can access, suggesting it's not a group membership sync issue.

Her workstation's offline files cache is corrupt, causing access denied. The administrator should clear the CSC cache on her machine.

Why it fails: Offline files cache corruption typically results in synchronization errors, not access denied to a live share, and there is no indication offline files are enabled.

The share permissions 'Everyone Full Control' are invalid because 'Everyone' does not include authenticated users from other domains. The administrator should add 'Authenticated Users' with Change permission.

Why it fails: 'Everyone' includes all authenticated users; share permissions are not the issue since other domain users can access the share.

Create a GPT partition and format with FAT32.

Why it fails: While GPT supports large volumes, FAT32 has a maximum file size limit of 4 GB and is not suitable for a file server storing large files. Additionally, FAT32 lacks security features like ACLs, making it a poor choice for a business file server.

Create an MBR partition and format with ReFS.

Why it fails: MBR partitioning limits volume size to 2 TB, so it cannot accommodate a 10 TB volume. ReFS is a resilient file system, but it requires GPT for large volumes. Thus, this combination fails to meet the size requirement.

Create an MBR partition and format with NTFS.

Why it fails: MBR partitions have a 2 TB limit, so they cannot support volumes larger than 2 TB. Although NTFS is suitable, the MBR partitioning scheme would prevent the administrator from utilizing the full capacity of the 10 TB RAID 6 array.

RAID 5

Why it fails: RAID 5 uses block-level striping with distributed parity, allowing it to survive a single disk failure. However, performance can degrade during rebuilds, and there is a risk of data loss if another disk fails during the rebuild. For a database requiring high availability, RAID 5 may not provide the same level of fault tolerance as RAID 1 in terms of simplicity and rebuild speed.

RAID 0

Why it fails: RAID 0 provides striping without parity or mirroring, offering improved performance but no fault tolerance. If a single disk fails, all data on the array is lost. This does not meet the requirement for surviving a disk failure without data loss, making it unsuitable for a high-availability database server.

RAID 6

Why it fails: RAID 6 provides double parity, allowing it to survive two simultaneous disk failures. While it offers high fault tolerance, it requires at least four disks and has higher write overhead compared to RAID 1. For a simple two-disk configuration, RAID 6 is not applicable, and the question implies a need for basic fault tolerance.

RAID 1

Why it fails: RAID 1 mirrors data across pairs of drives, providing fault tolerance and good read performance. However, with six drives, it would create three mirrors, resulting in only 900 GB usable capacity and no write performance improvement. It does not maximize capacity or write performance as effectively as other levels.

RAID 0

Why it fails: RAID 0 offers excellent performance and full capacity utilization, but it provides no fault tolerance. A single drive failure results in total data loss, which is unacceptable for a database server requiring high fault tolerance. Therefore, it does not meet the requirements despite its performance benefits.

RAID 5

Why it fails: RAID 5 offers fault tolerance and good read performance with a capacity of 1.5 TB (five drives worth). However, write performance is degraded due to parity calculations, and rebuild times are long. For a database with high write demands, RAID 5 may not provide the needed performance.

Install a new certificate that uses only the TLS 1.3 cipher suites and bind it to the sites.

Why it fails: Certificates are used for authentication and encryption key exchange, but they do not control which TLS protocol versions are negotiated. Even a certificate with modern cipher suites would still allow clients to connect using TLS 1.0 or 1.1 if those protocols remain enabled on the server.

Configure IIS to require SSL and set the minimum TLS version to 1.3 in the site bindings.

Why it fails: IIS site bindings allow you to require SSL and select a certificate, but they do not provide a setting to specify a minimum TLS version such as 1.3. Protocol versions are controlled at the operating system level, so this approach would not disable weaker protocols or enforce TLS 1.3.

Use the netsh http add sslcert command to set the TLS version to 1.3 for all HTTPS listeners.

Why it fails: The netsh http add sslcert command binds an SSL certificate to an IP address and port, but it does not include an option to set the TLS protocol version. TLS version enforcement on Windows is handled through SCHANNEL registry settings, not through netsh.

Storage Spaces with a simple volume.

Why it fails: A simple volume in Storage Spaces does not provide fault tolerance; it stripes data across disks without parity or mirroring. If a disk fails, data is lost. The scenario requires fault tolerance, so a simple volume is inappropriate. Additionally, expanding a simple volume may require taking the server offline if not configured properly, but the main issue is lack of redundancy.

Disk Management with a spanned volume.

Why it fails: A spanned volume combines space from multiple disks but provides no fault tolerance. If any disk fails, the entire volume is lost. It can be expanded online, but the lack of redundancy violates the requirement. Spanned volumes are not suitable for critical data that must survive disk failures.

Disk Management with a mirrored volume.

Why it fails: A mirrored volume in Disk Management provides fault tolerance but cannot be expanded online. To add space, the administrator would need to break the mirror, extend, and recreate, which requires downtime. The requirement is to expand without taking the server offline, so this option fails. Mirrored volumes also require two separate disks for redundancy.

Configure NIC teaming in Switch Independent mode with Dynamic load balancing.

Why it fails: Switch Independent mode does not require switch configuration and works with any switch, but it does not provide aggregated bandwidth for a single connection because the switch sees multiple links. While it provides failover, the bandwidth aggregation is limited to multiple simultaneous connections, not a single high-bandwidth stream. The scenario requires both failover and aggregated bandwidth, which is better achieved with a switch-dependent mode.

Configure each network adapter with a separate IP address and enable DNS round-robin.

Why it fails: DNS round-robin distributes connections across multiple IP addresses but does not provide failover if one adapter fails, and it does not aggregate bandwidth. Clients may still attempt to connect to a failed adapter. This approach also complicates management and does not leverage the switch's link aggregation capabilities.

Configure NIC teaming in Switch Independent mode with Hyper-V Port load balancing.

Why it fails: Hyper-V Port load balancing is designed for virtual machine traffic and distributes traffic based on the virtual switch port. It does not aggregate bandwidth for the host itself and is not ideal for a database server that is not running Hyper-V. It provides failover but not the desired bandwidth aggregation for physical workloads.

Disable IP forwarding and configure a static route between the two networks.

Why it fails: Disabling IP forwarding prevents the server from routing packets between the two interfaces, so no traffic would pass between the internal network and the DMZ. Static routes alone do not enable forwarding. This would break the required connectivity for the web application to be accessible from the DMZ while allowing internal-initiated connections.

Enable IP forwarding and configure a firewall rule to drop all traffic from eth1 to eth0.

Why it fails: Dropping all traffic from eth1 to eth0 would block return traffic for connections initiated from the internal network, breaking established sessions. The correct approach is to allow established and related connections, not to drop all traffic from the DMZ interface. This would prevent the internal network from receiving responses from the DMZ.

Enable IP forwarding and configure iptables with a rule to allow all traffic between eth0 and eth1.

Why it fails: Enabling IP forwarding and allowing all traffic between the interfaces would create a bridge between the internal network and the DMZ, violating the security requirement. This would allow unrestricted access from the DMZ to the internal network, which is not desired. The rule must restrict traffic to only established connections initiated from the internal network.

Disable write caching in the operating system disk properties

Why it fails: Disabling write caching in the operating system affects only the OS-level cache, not the RAID controller cache. The vendor's recommendation is about disk write caching at the hardware level. This action would reduce performance without addressing the RAID controller's cache, which is the primary concern. It does not meet the recommendation effectively.

Configure the RAID controller to use write-through caching

Why it fails: Write-through caching means writes are only acknowledged after being written to disk, which ensures data integrity but reduces performance. This would meet the vendor's data integrity requirement but at a performance cost. Since the controller has a battery-backed cache, write-back caching with battery protection is a better choice, as it maintains performance while ensuring data safety.

Disable the write cache on the RAID controller

Why it fails: Disabling the write cache on the RAID controller would ensure data integrity but would significantly degrade performance because all writes would be committed directly to disk. The battery-backed cache is designed to protect data during power loss, so disabling it defeats the purpose of having the cache. This action would meet the vendor's recommendation but at an unnecessary performance cost.