Explanation:

Enterprise servers use a Baseboard Management Controller (BMC)—such as Dell iDRAC, HPE iLO, or IPMI-based systems—to monitor and control fan operation. These controllers continuously read tachometer signals from each fan and track internal temperature sensors (CPU, memory, PCIe zones, etc.).

When the BMC detects that one fan has failed (0 RPM, missing signal, or physical removal), it immediately commands the remaining fans to run at maximum speed. This is a built-in redundancy feature to maintain airflow and prevent overheating until the failed unit is replaced. The behavior is isolated to the affected server because each system manages its own cooling policy independently.

The ambient room temperature being normal rules out environmental causes. Only an internal event—like a single fan failure—explains why just one server in the rack is affected.

Why the other options are incorrect:

A. The server is in the process of shutting down...
Incorrect. During shutdown, fans typically spin down or stop entirely as power is removed. They do not ramp to full speed as a default behavior.

B. An incorrect fan size was inserted...
Incorrect. Server fan bays are designed with specific form factors and connectors. An incompatible fan cannot be installed without forcing it, which would trigger a POST error or critical log entry, not adaptive speed increase. The BMC expects correct fans and will not compensate indefinitely for a mismatch.

D. The server is utilizing more memory...
Incorrect. Fan speed is driven by temperature, not memory usage. Even at 100% memory utilization, heat output is minimal compared to CPU or GPU load. The cooling system responds to thermal sensors, not resource metrics.

References:

CompTIA Server+ SK0-005 Exam Objectives

1.2 – Troubleshoot common hardware failures (includes fan failure symptoms and redundancy behavior).

Dell iDRAC9 User’s Guide

“Upon detection of a fan failure, the system increases the speed of the remaining fans to maximum to preserve cooling redundancy.”

HPE iLO 5 User Guide – ProLiant Servers

“Fan failure event triggers Redundant Fan Mode; all functional fans operate at 100% until resolution.”

Intelligent Platform Management Interface (IPMI) v2.0 Specification

Defines fan presence detection, health monitoring, and automatic failover speed adjustment.

Exam Tip:

One server with loud/full-speed fans + normal room temp = single fan failure with redundancy kick-in.
This is a high-priority, testable troubleshooting scenario on the SK0-005 exam.

Explanation:

The scenario describes a classic test of a high-availability cluster. Let's break down the steps:

Initial State: A two-node cluster with one node "active" (handling the workloads) and one node "passive" (on standby).

Test Action: Ann shuts down the active node. This simulates a failure.

Cluster Behavior (Failover): The cluster correctly detects the failure, and the passive node becomes active. This process is known as Failover. The cluster is now functioning, but on the secondary node.

Goal: Ann wants to return the cluster to its original configuration, meaning she wants the originally active (and now powered-on) node to resume its role as the active server.

The specific feature that allows an administrator to manually or automatically return the workload to the primary node after a failover is called Failback.

Failback is the process of switching operations back to the primary, preferred, or most powerful node after it has been restored to a healthy state. This is exactly what Ann needs to do to complete her task.

Why the Other Options Are Incorrect:

A. Heartbeat: This is the mechanism the cluster uses to monitor the health of its nodes. A constant communication signal (the "heartbeat") is sent between nodes. If the signal is lost, the cluster assumes a node has failed and initiates a failover. While essential for the initial failover, the heartbeat itself does not perform the return-to-original operation.

C. Redundancy: This is a design principle, not a specific action or feature. Having a passive node is a form of redundancy, but the term describes the state of having backup components, not the process of switching between them.

D. Load Balancing: This is a technique to distribute workloads across multiple nodes to optimize resource use and prevent any single node from being overwhelmed. This scenario describes a high-availability (active-passive) cluster, not a load-balancing (active-active) cluster. In a load-balanced setup, there is no concept of "returning to an original" active node in the same way.

Reference:

This question touches on the core objective of high-availability clustering, which is a key topic in the SK0-005 exam, specifically under Domain 5.0: Disaster Recovery.
Understanding the difference between failover (automatic recovery to a secondary system) and failback (restoring operations to the primary system) is a fundamental concept for a server administrator.

Explanation:

1. Differential Backup

A differential backup stores all changes made since the last full backup.
This allows faster restores than incremental backups because you only need the last full + last differential to restore.
It also uses less media than performing a full backup every time.
Ideal balance between quick restore and moderate storage use.

2. Synthetic Full Backup

A synthetic full backup is created by combining an existing full backup with incremental or differential backups—without re-reading data from the source server.
This saves backup time and reduces media usage, while still allowing fast restores (since it acts like a full backup).
Offers both quick restoration and optimized media efficiency.

Incorrect Options:

C. Archive: Used for long-term storage, not fast restores.

D. Full: Provides fastest restores but uses the most backup media.

E. Incremental: Uses minimal storage but slow restore times (requires multiple files).

F. Open file: Refers to backup handling method, not a backup type.

Reference:

CompTIA Server+ (SK0-005) Exam Objectives, Domain 4.1 – "Explain different backup types, methodologies, and concepts."

CompTIA Server+ Study Guide (Exam SK0-005) by Mike Meyers, Chapter on Data Security & Backup Strategies.

Summary:

The best backup combination that provides quick restores while minimizing backup media use is Differential + Synthetic Full.

Explanation:

The disk is already mounted at /newdisk (as stated: “mounted a new hard disk… with a mount point of /newdisk”), but users cannot create files or directories — a classic symptom of the filesystem being mounted read-only.

In Linux, a filesystem can be mounted read-only due to:

Default mount behavior for certain devices (e.g., some USB drives)
Errors detected during mount (e.g., journal replay issues)
Explicit ro option in /etc/fstab or during manual mount

To fix write access without unmounting, use the remount option with rw (read-write):
bashmount -o remount,rw /newdisk
This command:

Keeps the filesystem mounted
Changes mount options in-place
Enables write permissions immediately

Why the other options are incorrect:

A. echo /newdisk >> /etc/fstab
Incorrect. This only appends a malformed line to /etc/fstab. It does not define a valid filesystem entry (missing device, type, options, etc.) and does nothing to fix current mount. It also won’t remount anything.

B. net use /newdisk
Incorrect. This is a Windows command (net use) used to map network drives. It has no meaning in Linux.

D. mount -a
Incorrect. This mounts all filesystems listed in /etc/fstab that are not already mounted. It does not remount currently mounted filesystems and does not change options like ro → rw.

References:

CompTIA Server+ SK0-005 Exam Objectives

2.3 – Given a scenario, perform basic Linux server administration tasks → Includes mounting filesystems and modifying mount options.

Linux mount(8) Man Page

“-o remount,rw — Re-mount a currently mounted filesystem with new options (e.g., from ro to rw).”

Red Hat Enterprise Linux – Storage Administration Guide

“Use mount -o remount,rw /mountpoint to enable write access on a read-only mounted filesystem.”

Exam Tip:

Users can’t write + mount point already exists = likely mounted read-only → use mount -o remount,rw
This is a common SK0-005 troubleshooting question involving Linux storage administration.

Explanation

The goal is to restrict access to a new folder to only specific users. The most efficient and manageable way to handle permissions on a server for multiple users is by using Groups.

C. Create a group that includes the specific users and assign the proper permissions. (Note: The prompt contains a typo, option C is the correct concept even if it repeats text from B/A. The correct administrative action is to create a group for the specific users.)

Create a Security Group: The administrator creates a group (e.g., "Project_Alpha_Users").

Add Specific Users: The administrator adds only the required users to this new group.

Assign Permissions: The administrator applies the necessary permissions (Read, Write, Full Control) directly to the group on the new folder.

This approach is best practice because:

Scalability: If a new user needs access, the administrator only needs to add them to the existing group, not modify the folder permissions.

Simplicity: The permissions list on the folder remains clean and manageable, showing only one entry for the group instead of many individual user entries.

Why the other options are incorrect:

A. Create a group that includes all users...: Assigning a group that includes all users would grant universal access, failing to meet the requirement of restricting access to only specific users.

B. Assign individual permissions on the folder to each user. While this would technically work, it is not the BEST solution. It becomes an administrative headache (a "permissions sprawl") to manage when dealing with many users or many folders. Using groups is universally considered better administration.

D. Assign ownership on the folder for each user. Assigning ownership only determines who has the right to set permissions. It doesn't grant or restrict access for other users. The folder can only have one owner at a time, making this concept inapplicable for granting multiple specific users access.

Reference/Domain

This question falls under CompTIA Server+ (SK0-005) Domain 2.0: Server Administration.

2.2 Given a scenario, manage server security. (Specifically, implementing the principle of least privilege and using security groups for efficient access control.)

Explanation:

This question tests your knowledge of the structured troubleshooting methodology, which is a critical skill for any IT professional and a core part of the CompTIA Server+ exam objectives.

The standard troubleshooting steps, as outlined by CompTIA and other best practices, are generally:

Identify the problem (which includes scoping the issue and notifying users).
Establish a theory of probable cause.
Test the theory to determine the cause.
Establish a plan of action to resolve the problem.
Implement the solution or escalate.
Verify full system functionality.
Document the findings, actions, and outcomes.

Let's analyze the options in the context of the question: "after a solution has been implemented."

A. Perform a root cause analysis: This is a crucial step that often happens after the immediate fire is put out. Once the system is stable, the administrator should investigate why the problem occurred in the first place to prevent it from happening again. This is a proactive step that follows the implementation of a solution.

C. Document the findings: This is the final step in the troubleshooting theory. After the solution is implemented and verified, you must document what happened, what the cause was, what you did to fix it, and any other relevant information for future reference and for other team members.

Why the Other Options Are Incorrect:

B. Develop a plan of action: This occurs before implementing the solution. You need a plan to know what you are going to do to fix the problem.

D. Escalate the issue: This is done when you cannot resolve the problem yourself. It happens before a solution is implemented, not after.

E. Scope the issue: This is one of the very first steps in the process. You need to understand the breadth and impact of the problem at the beginning.

F. Notify the users: While communication with users is ongoing, the initial notification happens early when the problem is identified. A final notification that the issue is resolved would happen after verification, but this is more of a communication task than a formal step in the troubleshooting theory itself. The formal step is "Document," which serves as the official record.

Reference:

This question directly maps to the CompTIA troubleshooting model, which is a foundational concept across all CompTIA certifications. For the SK0-005 exam, this falls under Domain 4.0: Troubleshooting. Knowing the correct order of operations is essential for efficient and effective problem resolution.

Explanation:

In a high availability (HA) cluster (e.g., VMware vSphere HA, Microsoft Failover Cluster, Linux Pacemaker, etc.), the best practice before patching a host is to live-migrate (or failover) all virtual machines to another healthy node. This ensures:

Zero downtime for workloads (if using vMotion, Live Migration, etc.)
The host being patched is completely empty of running VMs
The cluster remains fully protected during maintenance

This process is called putting the host into Maintenance Mode, which automatically triggers VM migration.

Why the other options are incorrect:

A. Disable the heartbeat network.
Incorrect and dangerous. The heartbeat network is how cluster nodes detect failures. Disabling it risks split-brain scenarios, false failovers, or total cluster outage.

B. Fallback cluster services.
Incorrect. “Fallback” is not a standard term in HA clustering. You do not revert services before patching — you evacuate them to another node.

C. Set the cluster to active-active.
Incorrect. Most HA clusters are already active-active or active-passive by design. Changing the cluster mode is not required and may not even be applicable or safe mid-operation.

References:

CompTIA Server+ SK0-005 Exam Objectives

4.1 – Explain the importance of patching and updates in a virtualized environment
3.5 – Given a scenario, perform server maintenance in a clustered environment

VMware vSphere Documentation – Entering Maintenance Mode

“Before applying patches, place the ESXi host in Maintenance Mode. vSphere DRS automatically migrates all powered-on VMs to other hosts.”

Microsoft Failover Cluster – Node Maintenance

“Use Suspend-ClusterNode and Move-ClusterVirtualMachineRole to evacuate VMs before patching.”

Red Hat Enterprise Linux HA Add-On

“Relocate services using pcs resource move before patching a node.”

Exam Tip:

Patching a host in HA cluster → always evacuate workloads first via failover/live migration.
Never disable heartbeat or change cluster mode.
This is a core SK0-005 best practice question on cluster maintenance.

Explanation:

The error message:
bash ./startup.sh: Permission denied

means the script does not have execute permission.

To fix this, the administrator must add execute permission to the file.

The command:
chmod +x startup.sh

gives execute permission to the file owner, group, and others (depending on umask).

After running it, the script can be executed normally using:
./startup.sh

Incorrect Options:

A. chmod +w startup.sh → Adds write permission, not execute permission.

B. chmod 444 startup.sh → Makes the file read-only, no execute permission.

D. chmod 466 startup.sh → Grants write and read permissions to owner and read-only to others, still no execute permission.

Reference:
CompTIA Server+ (SK0-005) Exam Objectives, Domain 1.2 – “Given a scenario, install, configure, and maintain server operating systems.”

GNU/Linux chmod manual: man chmod

Summary:
To resolve the “Permission denied” error when running a Linux script, the administrator should add execute permissions using:
chmod +x startup.sh

Explanation:

RTO (Recovery Time Objective) defines the maximum acceptable downtime an organization can tolerate before a service or system is restored after an unplanned outage. It answers:

“How long can the business be down before severe impact occurs?”

RTO is measured in time (e.g., 4 hours, 30 minutes) and directly guides disaster recovery planning, including failover, backup restoration, and high-availability design.

Why the other options are incorrect:

A. SLA (Service Level Agreement)
Incorrect. An SLA is a contractual commitment between a provider and customer (e.g., 99.9% uptime). It may reference RTO/RPO, but does not define tolerable downtime.

B. BIA (Business Impact Analysis)
Incorrect. A BIA identifies critical systems and estimates financial/operational impact of downtime — it feeds into defining RTO, but is not the measure itself.

D. MTTR (Mean Time To Repair/Recover)
Incorrect. MTTR is a historical metric — average time to fix failures. It measures performance, not tolerance.

References:
CompTIA Server+ SK0-005 Exam Objectives
5.1 – Explain the key concepts of high availability and disaster recovery
→ Explicitly includes RTO and RPO definitions.

NIST SP 800-34 – Contingency Planning Guide
“RTO: The amount of time a system can be down before causing significant business impact.”

ITIL v4 – Service Continuity Management
“RTO is determined from the Business Impact Analysis and represents maximum tolerable downtime.”

Exam Tip:
“How much downtime can we tolerate?” → RTO
“How much data can we lose?” → RPO
This distinction is heavily tested on SK0-005 in disaster recovery sections.

Explanation:

This question is about key metrics in disaster recovery and business continuity planning.

RTO (Recovery Time Objective): This is the maximum acceptable amount of time that an application or service can be offline after a failure. It directly answers the question: "How long can we afford to be down?" In this scenario, the "amount of time a company can afford to be down" is the literal definition of the RTO.

Why the Other Options Are Incorrect:

A. SLA (Service Level Agreement): An SLA is a formal contract between a service provider and a customer that defines the level of service expected. While an SLA may contain specific metrics like RTO, it is not the metric itself. It is the agreement that stipulates the metrics.

B. MTBF (Mean Time Between Failures): This is a reliability metric for hardware. It measures the average time a device is expected to operate before it fails. It describes how often a component breaks, not how long the recovery process takes.

D. MTTR (Mean Time To Repair): This is the average time it takes to repair a failed component and return it to service. While related to downtime, it is a measure of the repair duration, not the business's tolerance for downtime. RTO is the goal; MTTR is the actual time it takes to meet that goal.

Reference:
This is a fundamental concept in IT disaster recovery and is a key part of the SK0-005 exam objectives, specifically under Domain 5.0: Disaster Recovery. Understanding the difference between RTO (time tolerance for downtime) and RPO (Recovery Point Objective, which is the amount of data loss a business can tolerate) is critical for designing an effective recovery strategy.