Manage users and groups practice questions

usermod -l guest olduser

Why wrong: usermod -l guest olduser only changes the login name in /etc/passwd; it does not alter the UID, and file ownership is tracked by UID, not by the login name. Files previously owned by olduser therefore remain associated with olduser's numeric UID, and if that UID does not match guest's UID, no files are actually reassigned. Moreover, the command does not delete the account at all, so it fails the policy's requirement to reassign all files upon deletion.

userdel -r olduser

Why wrong: userdel -r olduser does the opposite of reassigning files: the -r flag removes the user's home directory contents and mail spool, permanently destroying those files. It does not hand ownership of any files to guest; instead, any files in that home directory are deleted, and files elsewhere under /home that were owned by olduser remain orphaned. This violates both the policy to reassign all files and common retention requirements, making it an incorrect choice.

rsync -a /home/olduser/ /home/guest/

Why wrong: rsync -a /home/olduser/ /home/guest/ creates a duplicate copy of olduser's home directory contents under /home/guest, but it leaves the original files untouched and still owned by olduser. Even if rsync runs as root and preserves ownership on the copy, the source files are not reassigned, and any files outside the home directory are not addressed at all. This approach is about copying data, not about reassigning ownership of existing files upon account deletion.

The file's group is wheel

Why wrong: The group ownership of report.txt is `project`, not `wheel`, as shown in the fourth column of the long listing. `wheel` is a privileged group typically used for sudo access on RHEL, but it has no relation to this file unless the file's group column actually lists it. Since Alice is the file owner, her access is determined by the owner bits, so this incorrect group claim does not affect her ability to write.

Alice cannot write to report.txt because she is not the owner

Why wrong: This statement is false because the exhibit clearly shows alice in the owner field of report.txt; the premise that she is not the owner is incorrect. In Linux, when a user owns a file, the owner permission bits take precedence, and the owner has `rw-` (write permission set). Therefore Alice can write to the file, and the reason given in the option contradicts the displayed metadata.

Reapply the setgid bit using chmod g+s /projects

Why wrong: The setgid bit on a directory forces newly created files to inherit the directory's group ownership, but it does not change the permission bits that are applied. A file created still has its discretionary permissions masked by the process's umask, so if the umask removes group write/execute, the inherited group still lacks them. Re-running chmod g+s /projects simply reaffirms an attribute that is probably already set, leaving the permission problem unresolved.

Change dev1's umask to 0002 in /etc/bashrc

Why wrong: Changing dev1's umask to 0002 in /etc/bashrc would alter the default file mode for every file dev1 creates in any directory, not just /projects. This is a system-wide shell configuration that affects all interactive sessions and could unintentionally grant more permissive rights to files outside the intended project area. Furthermore, it only applies to new shell sessions after the change, and it does not provide a directory-scoped solution for group inheritance nor does it address other users who may create files in /projects.

Set the sticky bit on /projects with chmod o+t /projects

Why wrong: The sticky bit (o+t) is a special permission that restricts file deletion within a directory, allowing only the file owner, directory owner, or root to unlink entries. It has no influence on the permission bits assigned to new files or on group ownership inheritance. Setting it on /projects would prevent users from deleting each other's files, but it would not give the developers group rwx access, so the stated problem would persist.

Lock the user account with 'usermod -L jdoe'

Why wrong: usermod -L jdoe prepends an exclamation mark to the encrypted password in /etc/shadow, disabling password-based authentication for every PAM-aware service, including FTP, SSH password login, and console login. This blocks the very FTP access the administrator wants to preserve, making it too broad a restriction for the desired outcome. The command does not merely stop interactive shells; it stops all credential validation, so it is the wrong tool here.

Delete the user's password with 'passwd -d jdoe'

Why wrong: passwd -d jdoe erases the password hash, leaving an empty password field. By default, PAM and most FTP servers treat an empty password as invalid and reject the authentication attempt entirely, so FTP login would fail; if the system has nullok enabled, it would allow passwordless login, which is a serious security vulnerability. Neither outcome meets the requirement of continuing to allow FTP while blocking interactive shell, and removing the password may also disable other account checks.

Remove the user's home directory

Why wrong: Deleting the home directory with something like rm -rf /home/jdoe has no effect on the account's authentication state because login validation uses /etc/passwd, /etc/shadow, and PAM, not the home directory. The user will still be able to log in via SSH or the console and will simply be placed in an empty or non-existent home directory, potentially causing application errors but not preventing shell access. FTP would also remain available, so this action fails to restrict the interactive login the admin needs to block.

useradd -g developers alice

Why wrong: useradd is intended for creating new accounts, not for modifying existing ones; when used with an existing username like alice, it refuses to run unless you also specify -o, and it will not add her to the developers group. Moreover, the lowercase -g option sets the primary group for a newly created user, never a supplementary group. Therefore, this command cannot satisfy the requirement of adding alice to an existing group.

groupmod -a alice developers

Why wrong: groupmod is used to change the properties of a group itself, such as its GID or name, not to manage its member list. The command also has no -a option at all, so this syntax is invalid and will fail with an error. Group membership should instead be updated with gpasswd -a or usermod -aG, not with groupmod.

usermod -g developers alice

Why wrong: The lowercase -g option in usermod changes the user's primary group, whereas the question asks for adding alice to developers as an additional, supplementary group. This command would replace alice's primary group with developers, potentially affecting ownership of files she creates and leaving her other supplementary groups unchanged. Since it does not append memberships, it does not achieve the required 'add to group' action without altering her existing primary group.

Change webuser's shell to /bin/bash to allow SFTP login

Why wrong: Changing webuser's shell to /bin/bash does not affect file permissions; SFTP login is independent of shell and already possible with a restricted shell like /sbin/nologin.

Change the SELinux context of /var/www/html to httpd_sys_rw_content_t

Why wrong: Changing SELinux context to httpd_sys_rw_content_t is relevant for Apache write access, but the question specifically requires SFTP uploads, which operate under different SELinux policies; not a necessary step.

Configure slave interfaces, then create bond interface config, then restart network

Why wrong: Configuring slave interfaces before the bond interface exists is backwards: ifcfg-eth0 can specify MASTER=bond0, but if ifcfg-bond0 is absent at boot, the bonding driver has no bond0 device to attach to, so the slaves are left unenslaved or the network script fails. Even if a later restart creates bond0, the system will not automatically reattach already-configured slaves unless the scripts process them in the correct dependency order. This sequence therefore produces a bond with zero active interfaces at the moment it is needed.

Restart network, then create bond interface config, then configure slave interfaces

Why wrong: Restarting the network before any bond or slave configuration has been written simply reloads the old, unmodified configuration, so the bond never comes up in that restart. After creating the bond and slave files, you would need yet another restart to apply the changes, making the third step in this sequence useless and the network needlessly interrupted. The bond configuration would not be active until a subsequent restart, which contradicts the intended one-cycle setup.

Create bond interface config, then restart network, then configure slave interfaces

Why wrong: Creating the bond config and then immediately restarting brings up an empty bond0 with no slaves, because no ifcfg-eth0/eth1 entries with MASTER=bond0 exist yet. Once the slave files are added later, simply running ifup on them may not attach them to the already-running bond, as the master is already up and the initscripts expect the bond to be configured before slaves load. You would then have to restart the network a second time, so this option defeats the goal of a clean two-step configuration.

drop: All network connections are accepted.

Why wrong: This answer confuses the drop zone's target with the trusted zone's ACCEPT target. The drop zone actually has a target of DROP, meaning incoming packets are silently discarded with no response sent, making it the least trusted zone. Accepting all network connections is the defining behavior of the trusted zone, which has the highest trust level, so this pairing is incorrect.

public: Medium to high trust.

Why wrong: Assigning medium-to-high trust to the public zone is incorrect because the public zone is explicitly intended for untrusted, public-facing networks. Its default configuration only allows a few basic services, such as SSH, and drops the majority of unsolicited inbound traffic. Medium-to-high trust characterizes the internal zone, which permits a wider range of services for corporate intranet hosts, not the public zone.

newgrp -c 'groups'

Why wrong: The `newgrp` command is used to start a subshell with a different group ID, not to list group memberships. The `-c` option is not a valid newgrp option; the command as written is syntactically invalid and would likely fail or launch a shell with unexpected arguments. Even if it were well-formed, newgrp would only change the active group for a new shell, not display any group information.

groups $(whoami)

Why wrong: The `groups $(whoami)` command substitutes the current username and asks the group database (e.g., /etc/group) for that user's memberships, which may be cached by NSS. It does not necessarily reflect the supplementary groups of the current process, so after usermod it could show a group that your shell doesn't actually have access to yet, or miss one due to caching. The `id` command, in contrast, shows the kernel-level group list for the current process.

usermod -g

Why wrong: The `usermod -g` option is a privileged administration command that changes a user's primary group in /etc/passwd; it does not query or display any group information. Running it without root privileges fails, and using it for verification would be both dangerous and pointless because it modifies rather than reports. It also only affects the primary group ID, not supplementary group memberships.

/etc/group with no user entry

Why wrong: The /etc/group file maps group names to GIDs and lists member usernames; it contains no password-aging attributes. A user missing from a group would simply fail to inherit that group's permissions, but `passwd` checks the user's shadow entry for aging constraints and never consults group membership. Therefore, a missing group entry cannot prevent a password change.

/etc/login.defs with PASS_MAX_DAYS set to 0

Why wrong: The PASS_MAX_DAYS parameter in /etc/login.defs defines the default maximum password age for newly created accounts. Setting it to 0 means no maximum age is enforced, so passwords never expire—this encourages or allows password changes rather than prohibiting them. Per-user restrictions that block changes reside in /etc/shadow, not in login.defs, which only supplies defaults.

/etc/passwd with incorrect shell

Why wrong: The shell field in /etc/passwd indicates which command interpreter is launched after authentication, such as /bin/bash or /usr/sbin/nologin. It is unrelated to password storage or aging: password hashes and expiration data are kept in /etc/shadow. Even an invalid shell cannot block the `passwd` binary, which does not read or depend on the shell field once the user has authenticated successfully.

The default group for new users will be changed to GID 10.

Why wrong: The -f option of useradd does not modify group membership or GID defaults; it sets the inactivity period for accounts after password expiration. Default group configuration is controlled by -g, -G, or the GROUP variable in /etc/default/useradd, not the -f flag. GID 10 is likewise unrelated to inactivity settings.

New user accounts will have a maximum password age of 10 days.

Why wrong: Maximum password age is an attribute set via -M or -K PASS_MAX_DAYS on useradd, or through /etc/login.defs, and it defines how long a password remains valid before the user must change it. The -f flag governs what happens after that password already expired, specifically the grace period before account deactivation. Therefore, -f 10 does not impose a 10-day password lifetime.

New user accounts will have a password expiration of 10 days.

Why wrong: Setting a password expiration of 10 days would mean the user must choose a new password every 10 days, which is handled by the -M or -E option (or PASS_MAX_DAYS in /etc/login.defs), not -f. Password expiration dictates when the credential becomes invalid, whereas -f dictates the post-expiration inactivity window. Mixing these up is a common administrative error that leaves accounts suspended or never suspended depending on the real password-aging policies.

Is readable by all users.

Why wrong: The /etc/shadow file is readable only by root or users in the shadow group, not all users.

Contains user ID numbers.

Why wrong: User ID numbers are stored in /etc/passwd, not in /etc/shadow.

cat /etc/group | grep user

Why wrong: Piping `cat /etc/group` through `grep` only finds lines that literally contain the username in the comma-separated member list, which is only true for supplementary group entries. The user's primary group is stored as a numeric GID in `/etc/passwd` and will not appear in `/etc/group` unless the user is also explicitly added there, so this approach silently omits the primary group. It also fails entirely when group information comes from NSS sources such as LDAP, where `/etc/group` is incomplete.

usermod -g user

Why wrong: `usermod -g` is a privileged account-modification command that changes the user's primary group; it does not list any group memberships. Running `usermod -g user` would attempt to set the primary group to a group named `user`, not to show which groups a user belongs to. This option misuses an administration tool that can modify `/etc/passwd` and requires root, and it produces no output of membership information.

getent group user

Why wrong: The `getent` command looks up individual database records, and `getent group user` treats `user` as a group name to be searched in the group database, not as a username. If a group named `user` does not exist, it returns nothing; if it does exist, it only shows that group's members, not the groups of the user. To list a user's groups with `getent`, you would need to iterate over all groups or use `id`, so this command does not answer the question.

Bob will not be able to read the file because the group bob has no members.

Why wrong: This is incorrect. Even though the group 'bob' has no members listed in /etc/group, Bob's primary group (from /etc/passwd) is 'bob' with GID 1002, which matches the file's group owner. Therefore, he inherits the group read permission (r--) from the file's 640 permissions and can read the file.

Bob will be able to read the file only if he is explicitly listed in /etc/group.

Why wrong: This is incorrect because explicit listing in /etc/group is not a prerequisite for group access. Bob's primary group is defined by the GID field (1002) in /etc/passwd, and that GID matches the file's group owner. The kernel compares the file's GID to Bob's effective GID, which includes his primary group automatically, regardless of whether he appears as a supplementary member in /etc/group.

Add jdoe to the wheel group and configure /etc/sudoers with '%wheel ALL=(ALL) ALL'

Why wrong: Configuring '%wheel ALL=(ALL) ALL' in /etc/sudoers allows all members of the wheel group to run any command with sudo, but this rule still demands that the invoking user authenticate with their own password. Since the question requires passwordless sudo access for jdoe, this setup does not meet that requirement unless it is paired with a NOPASSWD tag or a separate rule. The default sudo configuration for wheel on most distributions enforces password authentication.

Set the UID of jdoe to 0

Why wrong: Setting jdoe's UID to 0 makes the user numerically identical to the root superuser, granting absolute root ownership of every process and file the user creates. This bypasses sudo entirely and is extremely risky because any program run by jdoe runs with full kernel-level privileges, and it can break services that rely on distinct UIDs for user separation. It is not a standard or recommended method for granting administrative rights and would require unmounting and remounting filesystems to change the UID safely.

Add jdoe to the root group

Why wrong: Membership in the root group (GID 0) merely places jdoe in the same group as system administrators, but the group itself carries no inherent sudo or root execution permissions under the default policy. Sudo access is controlled exclusively by rules in /etc/sudoers, which must explicitly mention a user, a group name, or a %group specification. Without such a rule, being in the root group has no effect on whether jdoe can invoke sudo or run privileged commands.

The user is locked due to expired password

Why wrong: Password expiration does not permanently lock a user out; when the password is expired, PAM typically forces the user to set a new one at the next login before a session starts. The symptom of "cannot log in" with no prompt to change the password implies a different cause. The account's login shell /sbin/nologin is what prevents the session from being established, not an expired password policy.

The home directory does not exist

Why wrong: A missing home directory causes applications to fail or the user to land in the root directory, and it can trigger warnings from the login process, but it never blocks authentication or shell startup. The user would still be able to log in and interact with the system, albeit with a broken working environment. In this scenario, the inability to log in at all is due to the shell being set to /sbin/nologin, which terminates the session before the home directory is even evaluated.

The user is not in any supplementary groups

Why wrong: Supplementary group membership is not a login prerequisite; groups only affect file permissions and process access during the session. A user with no supplementary groups can still authenticate and start a shell in their primary group. Login failures are caused either by authentication problems, PAM restrictions, or a restricted shell binary like /sbin/nologin, not by missing group entries.

useradd -u <UID> -g <group> <user>

Why wrong: The -u flag in useradd specifies the user's UID, not the group's GID, and -g requires an existing group name or GID. Without running groupadd first, the command fails if <group> is not already defined in /etc/group. Additionally, this command does not attempt to create a group with the desired GID, so it cannot achieve the migration goal.

useradd -g <group> <user>

Why wrong: This command omits any attempt to create the group; useradd -g only assigns an existing primary group. If <group> does not already exist in /etc/group, useradd exits with an error before any user is created. There is also no way to enforce a particular GID for the group, since groupadd is never invoked.

groupadd -g <GID> <group> then useradd -g <group> <user>

Why wrong: The intended order is correct, but the word 'then' is not a valid shell command separator. The shell will attempt to execute a command named 'then', causing a syntax error or confusing behavior, so the two commands are never chained properly. To make this work, you would need to replace 'then' with '&&' or ';', which is why this answer is not acceptable.

setfacl -m u:bob:rwx /home/bob

Why wrong: Granting bob an ACL entry with setfacl does give him rwx access, but it leaves /home/bob owned by root, so the root cause is still present. ACLs are a supplementary permission mechanism layered on top of traditional ownership, and they can be lost when a file or directory is replaced, moved, or replicated to a filesystem that does not support ACLs. The standard administrative fix for a misowned home directory is to change ownership with chown, not to paper over the problem with an ACL.

usermod -d /home/bob bob

Why wrong: usermod -d /home/bob only updates the UID's home directory field in /etc/passwd; it does not touch the directory itself. bob already has /home/bob as his home, so this command is a no-op for the reported problem. Even if it did change the path, it would not alter the owner, group, or permission bits, so bob would still be unable to write because root remains the owner.

chmod 755 /home/bob

Why wrong: chmod 755 sets the mode to rwxr-xr-x, which gives the owner root full access and everyone else only read and execute. Since bob is not the owner and does not belong to the owning group, he receives no write permission. This command changes only the permission bits, not the ownership record, so root remains the owner and the original problem persists.

useradd -r -M -s /bin/false appuser

Why wrong: Using /bin/false as the login shell is problematic because it returns a non-zero exit status without any user-friendly message, whereas /sbin/nologin prints a polite notice and is specially integrated with PAM for service accounts. While -r and -M correctly designate a system account and suppress home directory creation, the non-standard shell choice breaks the expected behavior for a daemon account. According to Red Hat conventions, /sbin/nologin is the only acceptable shell for system users that must not log in.

useradd -r -s /sbin/nologin appuser

Why wrong: This command uses -r and -s /sbin/nologin, but omits -M, so useradd will create a home directory by default (because CREATE_HOME=yes in /etc/login.defs). For a system account, a home directory is unnecessary bloat and can be a security risk, since the service may not need local storage at all. The correct practice is to explicitly specify -M to prevent /home/appuser or /var/home/appuser from being created against the administrator's intent.

useradd -s /bin/false -M appuser

Why wrong: This command uses /bin/false instead of /sbin/nologin, which is non-standard for Red Hat-managed accounts, and it also omits -r, meaning the user gets a regular UID (e.g., 1000+) rather than a system UID. As a result, the account is not recognizable as a service account by tools like systemd or auditd that filter on UID ranges. The lack of -r further means the account may appear in user-listing utilities and is not subject to the system account protections, so it is unsuitable for a daemon.

chown root:root /etc/shadow && chmod 600

Why wrong: Running chown root:root /etc/shadow changes the group ownership from shadow to root, which is an unnecessary and nonstandard modification. The chmod 600 portion of the command is correct, but the audit only requires fixing the permission bits, not altering ownership from the typical root:shadow convention. Changing the group could also affect tools or processes that expect the shadow group to exist, so this combined command is not the appropriate remediation.

chmod 600 /etc/shadow

Why wrong: Setting chmod 600 on /etc/shadow grants read and write access exclusively to root, with no permissions for group members or other users. This is the required permission scheme because only root should be able to read or modify the password hash file. Unprivileged users cannot view the hashes, which prevents offline password cracking, and root-level tools like passwd and su can still access the file because they run with setuid root.

chmod 000 /etc/shadow

Why wrong: Applying chmod 000 /etc/shadow removes all permissions, including read access for root, which effectively blocks every process from opening the file unless it has special capabilities like CAP_DAC_OVERRIDE. System utilities such as su, sudo, and login must read the shadow file to verify passwords, so this over-restrictive mode breaks authentication entirely. It takes the principle of least privilege to an extreme, rendering the system unusable in a way that is not considered a valid fix.