CCNA Manage users and groups Questions

Multi-Selectmedium

Which TWO commands can change the primary group of an existing user?

Select 2 answers

A.usermod -aG

B.gpasswd -a

C.vigr

D.groupmems -a

E.useradd -G

AnswersA, B

`usermod -aG` adds the user to a supplementary group, not the primary group.

Why this answer

None of the listed commands change the primary group of an existing user. The correct commands are `usermod -g` to change the primary group directly, or `groupmod -g` after ensuring the user is the only member of the group.

Exam trap

The trap is assuming that `usermod -aG` or `gpasswd -a` can change the primary group when they actually manage supplementary group membership only.

Practice this question →

MCQmedium

An administrator needs to create a user account that will be used by an application service. The account should not have a valid shell or home directory. Which command correctly creates such an account?

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

B.useradd -r -s /sbin/nologin -M appuser

C.useradd -r -s /sbin/nologin appuser

D.useradd -s /bin/false -M appuser

AnswerB

This is the canonical command for creating a service account: -r assigns a UID from the system range, -s /sbin/nologin sets the PAM-aware shell that immediately rejects interactive logins, and -M suppresses creation of a home directory. Together these flags produce a minimal, non-interactive account that follows Red Hat's recommended security baseline for daemon users. No home directory means less attack surface and no risk of user-owned files in /home.

Why this answer

It uses the `-r` flag to create a system account (no aging information), `-s /sbin/nologin` to set the shell to a program that politely refuses login, and `-M` to explicitly skip creating a home directory. This combination ensures the account has no valid shell and no home directory, meeting the requirement for an application service account.

Exam trap

Candidates often forget the `-M` flag when the requirement explicitly states no home directory. Additionally, they may incorrectly use `/bin/false` instead of `/sbin/nologin` for a service account on Red Hat systems.

How to eliminate wrong answers

Option A is wrong because `/bin/false` is a valid shell that simply exits with a non-zero status, but it is not the standard Red Hat Enterprise Linux shell for denying login; `/sbin/nologin` is the preferred choice as it prints a message and logs the attempt. Option C is wrong because it omits the `-M` flag, so a home directory will be created by default (unless overridden by `/etc/default/useradd`), which violates the requirement of no home directory. Option D is wrong because it lacks the `-r` flag, so the account will be created as a regular user with password aging and other normal user attributes, and it uses `/bin/false` instead of the standard `/sbin/nologin`.

Practice this question →

MCQmedium

Refer to the exhibit. A user named 'carol' has been added to the system with the command useradd -G wheel carol. Which line in /etc/group will confirm that carol is now a member of the wheel group?

A.wheel:x:10:carol,root,alice,bob

B.wheel:x:10:root,alice,bob,carol

C.wheel:x:10:root,alice,bob,carol,

D.wheel:x:10:root,alice,bob carol

AnswerB

Correct. The `useradd -G wheel carol` command adds 'carol' to the supplementary group 'wheel' by appending her username to the end of the comma-separated member list in `/etc/group`. The line `wheel:x:10:root,alice,bob,carol` shows 'carol' after the existing members, with no trailing comma, which is the correct format.

Why this answer

The `useradd -G wheel carol` command adds 'carol' to the supplementary group 'wheel', and the `/etc/group` file lists supplementary members as a comma-separated list with no trailing comma. The line `wheel:x:10:root,alice,bob,carol` shows 'carol' appended after the existing members, which matches the expected format.

Exam trap

In Red Hat Enterprise Linux, the /etc/group file format requires member lists to be comma-separated with no trailing comma, and the useradd -G command appends users to the end of the supplementary group member list.

How to eliminate wrong answers

Option A is wrong because it lists 'carol' before 'root', but the `useradd -G` command appends the new user to the end of the existing group member list, not at the beginning. Option C is wrong because it includes a trailing comma after 'carol', which is invalid in `/etc/group` — the file format does not allow a trailing comma. Option D is wrong because it uses a space instead of a comma to separate 'bob' and 'carol', but the `/etc/group` file requires commas as delimiters between usernames.

Practice this question →

Multi-Selecteasy

Which TWO commands can list all groups a user belongs to? (Choose exactly 2)

Select 2 answers

A.id -nG

B.cat /etc/group | grep user

C.usermod -g user

D.getent group user

E.groups

AnswersA, E

The `id -nG` command prints all group IDs for the named user (or the current user if no user is given) and then converts those numeric IDs to names via the `-n` flag. Because `id` queries the system's user and group databases through NSS, it includes the primary group from `/etc/passwd` and every supplementary group from `/etc/group` (or LDAP/SSSD), making it a complete and script-friendly listing.

Why this answer

Option A, `id -nG`, is correct because it prints the names of all groups the specified user is a member of, including both the primary group and supplementary groups, using the `-n` flag to show names instead of numeric GIDs and `-G` to list all group memberships. Option E, `groups`, is correct because it displays the groups a user belongs to, defaulting to the current user or accepting a username argument, and it reads from the same system group database to show all memberships. Option B, `cat /etc/group | grep user`, is not reliable because it only matches the literal string 'user' in the group file and may miss memberships or match unintended entries, and it does not handle network-based group sources.

Option C, `usermod -g user`, is incorrect because it modifies a user's primary group rather than listing group memberships. Option D, `getent group user`, is incorrect because it queries the group database for a group named 'user' and lists that group's members, not all groups a user belongs to.

Exam trap

The trap here is that candidates often think `cat /etc/group | grep user` or `getent group user` will list all groups for a user, but these commands only search for a group named 'user' or lines containing the string, not the user's actual group memberships, which is a common misconception tested on the EX200 exam.

Practice this question →

MCQhard

An administrator is migrating user accounts to a new system. They want to preserve the user's primary group name and GID. Which commands should be used in sequence?

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

B.useradd -g <group> <user>

C.groupadd --gid <GID> <group> && useradd -g <group> <user>

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

AnswerC

This is the correct sequence because groupadd --gid explicitly creates the group with the requested GID, and the && operator ensures the subsequent useradd runs only if groupadd succeeds. The useradd -g then sets that newly-created group as the user's primary group. This atomic two-step chain guarantees both objects exist with the intended numeric GID.

Why this answer

To preserve the primary group name and GID during migration, you must first create the group with the desired GID using `groupadd --gid <GID> <group>`, then create the user with that group using `useradd -g <group> <user>`. Option A fails because the group does not exist; Option B fails for the same reason if the group is new; Option D is not a valid shell command sequence because 'then' is not a command.

Practice this question →

MCQmedium

A system administrator needs to change the primary group of an existing user to a group that already exists. Which command should be used?

A.groupmod -g existinggroup username

B.usermod -g existinggroup username

C.usermod -p existinggroup username

D.usermod -G existinggroup username

AnswerB

This is correct because `usermod -g` directly modifies the user's primary group by changing the GID field in the `/etc/passwd` entry. The specified group must already exist on the system, otherwise `usermod` will return an error and make no changes. After this command, newly created files and directories will inherit this group as their owning group by default, until the user changes it.

Why this answer

The `usermod -g` command changes the primary group of an existing user to a specified group that already exists on the system. The `-g` option sets the initial login group (GID) for the user, which must be a valid group name or GID from `/etc/group`.

Exam trap

The trap here is confusing the `-g` (primary group) and `-G` (supplementary groups) options of `usermod`, leading candidates to pick option D when they need to change the primary group.

How to eliminate wrong answers

Option A is wrong because `groupmod -g` changes the GID of an existing group, not the primary group of a user. Option C is wrong because `usermod -p` is used to set or change the user's password (encrypted), not their group membership. Option D is wrong because `usermod -G` sets the supplementary (secondary) group list for the user, not the primary group.

Practice this question →

MCQmedium

A junior administrator is asked to create a new group named 'qa' with an explicit GID of 4500 on a Red Hat Enterprise Linux 8 server. After running the appropriate command, they verify the result with getent group qa and see 'qa:x:4500:'. Which command did the junior administrator most likely run?

A.usermod -g 4500 qa

B.groupmod -g 4500 qa

C.groupadd -g 4500 qa

D.newgrp -g 4500 qa

AnswerC

This is correct because groupadd with the -g option creates a new group and assigns the specified GID value of 4500 to it. The output from getent group qa confirms the group exists with GID 4500 and no members, which is exactly what groupadd -g produces. No other command in the list creates a group entry in /etc/group with a custom GID.

Why this answer

Creating a group with a specific GID requires the groupadd command with the -g option. The -g flag sets the numeric GID, and the final argument is the group name. The getent output shows the group exists with the requested GID and no supplementary members, which matches exactly what groupadd -g 4500 qa produces.

None of the other commands create a new group entry.

Exam trap

The trap here is confusing group management commands: assuming usermod or groupmod creates groups, when only groupadd can add a new group entry.

Practice this question →

MCQmedium

A system administrator needs to ensure that a user named 'jdoe' can execute commands as root without being prompted for a password. Which configuration change should be made?

A.Add 'jdoe ALL=(ALL) NOPASSWD: ALL' to /etc/sudoers via visudo

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

C.Set the UID of jdoe to 0

D.Add jdoe to the root group

AnswerA

Adding 'jdoe ALL=(ALL) NOPASSWD: ALL' to /etc/sudoers via visudo grants jdoe the ability to execute any command as any user on any host without being prompted for a password. The visudo command validates the syntax of the file before saving, preventing lockouts from malformed entries. The NOPASSWD tag overrides the default requirement to supply the user's own password when invoking sudo.

Why this answer

The sudoers directive 'jdoe ALL=(ALL) NOPASSWD: ALL' grants user jdoe the ability to run any command as any user (including root) on any host without a password prompt. This configuration must be added using visudo to ensure syntax validation and prevent lockout. The NOPASSWD tag overrides the default password requirement for sudo.

Exam trap

The trap here is that candidates often confuse the wheel group's default sudo behavior (password required) with passwordless access, or they incorrectly assume that group membership (root group) or UID changes are equivalent to sudo configuration.

How to eliminate wrong answers

Option B is wrong because '%wheel ALL=(ALL) ALL' requires members of the wheel group to enter their own password when using sudo; it does not provide passwordless access. Option C is wrong because setting the UID of jdoe to 0 would effectively make jdoe a second root user, which is a severe security risk and violates the principle of least privilege; it also does not use sudo at all. Option D is wrong because adding jdoe to the root group grants group-level permissions but does not allow command execution as root via sudo; root group membership does not bypass sudo password requirements.

Practice this question →

MCQmedium

A user named jdoe is receiving 'Permission denied' errors when trying to access a file owned by root with permissions 644. The user is a member of the root group. What is the most likely cause?

A.The directory containing the file lacks execute permission for the group or others.

B.The file's group owner is not root.

C.The file's read permission is not granted to the root group.

D.The user needs to be added to the root group again.

AnswerA

The directory containing the file lacks execute permission for the group or others. This is the most likely cause because to access a file inside a directory, the user needs execute (x) permission on the directory. Without it, even with correct file permissions, the user will get 'Permission denied'.

Why this answer

The file has permissions 644, meaning the owner (root) has read/write, and the group (root) and others have read-only access. Since jdoe is a member of the root group, the file's group read permission should allow access. However, to traverse a directory and access any file within it, the user needs execute (x) permission on that directory.

If the directory lacks execute for the group or others, jdoe will get 'Permission denied' even if the file permissions are correct.

Exam trap

The trap here is that candidates focus solely on file permissions (644) and overlook that directory execute permission is required for file access, leading them to incorrectly suspect group membership or file group ownership issues.

How to eliminate wrong answers

Option B is wrong because the file's group owner is root (as stated in the scenario), and the user jdoe is a member of the root group, so group ownership is correct. Option C is wrong because the file's permissions 644 grant read (4) to the group, so the root group does have read permission. Option D is wrong because the user is already a member of the root group; re-adding them would not resolve a directory permission issue.

Practice this question →

MCQhard

A server has a requirement that all users in the 'finance' group must have a password aging policy that forces password change every 90 days. Which approach best achieves this for existing users?

A.Set PASS_MAX_DAYS 90 in /etc/login.defs

B.Edit /etc/shadow and change the fifth field for all users

C.Configure pam_pwquality.so to enforce password age

D.Write a script to run 'chage -M 90' for each user in the finance group

AnswerD

A script that calls chage -M 90 for each user in the finance group is the correct approach because chage directly updates the maximum password age field in /etc/shadow for existing user accounts. For example, you can iterate over `getent group finance | cut -d: -f4`, and run chage for each member, which precisely targets the intended accounts and leaves all other users untouched.

Why this answer

`chage -M 90` sets the maximum password age for a specific user, and by scripting it to apply to all members of the 'finance' group, you directly enforce the 90-day policy on existing users. This approach works regardless of the default settings in `/etc/login.defs`, which only affect new users, and avoids the manual and error-prone editing of `/etc/shadow`.

Exam trap

The trap here is that candidates often confuse `/etc/login.defs` as applying to all users (including existing ones), when in fact it only sets defaults for new user creation via `useradd`.

How to eliminate wrong answers

Option A is wrong because `/etc/login.defs` only sets default values for newly created users; it does not retroactively apply to existing users. Option B is wrong because manually editing the fifth field in `/etc/shadow` is fragile, error-prone, and not a supported or recommended administrative practice; the `chage` command is the proper tool for this task. Option C is wrong because `pam_pwquality.so` is a module for password quality/complexity checks (e.g., length, character classes), not for enforcing password aging policies like maximum days between changes.

Practice this question →

MCQeasy

A user reports they cannot log in to a Linux system. Their account was recently created. The administrator checks /etc/passwd and sees the entry: jsmith:x:1001:1001::/home/jsmith:/sbin/nologin. What is the likely issue?

A.The user is locked due to expired password

B.The home directory does not exist

C.The user is not in any supplementary groups

D.The user's shell is set to /sbin/nologin which prevents login

AnswerD

The login shell in /etc/passwd is the program executed after authentication, so setting it to /sbin/nologin makes the login process run a binary that immediately prints "This account is currently not available" and exits. Since no command interpreter is ever started, the user cannot obtain a shell, making this the direct cause of the reported inability to log in. This is the standard way to deliberately disable interactive logins for system accounts while keeping the account enabled for other services.

Why this answer

The user's shell is set to /sbin/nologin, which is a shell that displays a message and exits immediately, preventing interactive login. This is the direct cause of the login failure, as the system uses the shell field in /etc/passwd to determine the login program.

Exam trap

The trap here is that candidates may confuse the shell field with account lockout mechanisms (like using 'passwd -l' or setting the password expiration) or assume that a missing home directory is the cause. In Red Hat Enterprise Linux, the shell field in /etc/passwd directly controls whether an interactive login is allowed; /sbin/nologin explicitly denies login.

How to eliminate wrong answers

Option A is wrong because an expired password would typically be indicated by a password aging flag in /etc/shadow, not by the shell field in /etc/passwd. Option B is wrong because a missing home directory does not prevent login; the user would still be able to log in but might see a message like 'Could not chdir to home directory'. Option C is wrong because supplementary groups are not required for login; the user's primary group (GID 1001) is sufficient for authentication and shell access.

Practice this question →

MCQhard

Refer to the exhibit. What effect does the value INACTIVE=-1 have on newly created user accounts?

A.The account expires immediately.

B.Passwords never expire.

C.Account is disabled if password expires but user does not log in within -1 days (immediately).

D.The password inactivity period is disabled.

AnswerD

When INACTIVE is set to -1, the password inactivity period is disabled entirely. After a user's password expires, the account will not be automatically locked due to the user failing to log in within a set number of days. The user remains able to log in and is typically forced to change the expired password, provided other account expiration policies such as EXPIRE are not also set.

Why this answer

The `INACTIVE=-1` setting in the `useradd -D` or `/etc/default/useradd` configuration disables the password inactivity period. This means that after a password expires, the account will not be locked due to inactivity, effectively turning off the inactivity timer. The value -1 is a special sentinel that indicates no inactivity period is enforced.

Exam trap

Red Hat often tests the distinction between password expiration (`PASS_MAX_DAYS`) and the inactivity period (`INACTIVE`), trapping candidates who confuse the two or misinterpret -1 as 'immediate' rather than 'disabled'.

How to eliminate wrong answers

Option A is wrong because `INACTIVE=-1` does not cause immediate account expiration; account expiration is controlled by the `EXPIRE` field or `-e` option, not the inactivity setting. Option B is wrong because password expiration is controlled by `PASS_MAX_DAYS` (e.g., in `/etc/login.defs`), not by the inactivity period; `INACTIVE` only affects what happens after a password expires. Option C is wrong because a negative value (-1) disables the inactivity check entirely; it does not mean 'immediately' — the account is not disabled at all due to inactivity when set to -1.

Practice this question →

MCQmedium

A user jdoe, who is a member of the group staff, reports they cannot access the directory /shared. The administrator runs getfacl /shared and receives the output shown. Which of the following explains the issue?

A.The group staff does not have execute permission

B.An ACL entry denies all permissions for jdoe

C.The mask entry restricts group permissions

D.The directory is read-only for the owner

AnswerB

Access control list evaluation checks a named user entry for jdoe before it checks the owning group. The entry user:jdoe:--- supplies no read, write, or execute bits, which causes every attempted operation on the directory to fail for jdoe. This explicit deny overrides the otherwise permissive group::rwx entry that staff members would normally inherit.

Why this answer

The getfacl output shows a user ACL entry for jdoe with permissions '---' (no read, write, or execute), which explicitly denies all access. This user-specific ACL entry overrides any group or other permissions, so jdoe cannot access /shared regardless of group staff membership.

Exam trap

The trap here is that candidates often focus on group permissions or the mask, overlooking that a user-specific ACL entry with no permissions explicitly denies access, overriding all other entries.

How to eliminate wrong answers

Option A is wrong because the group staff may have execute permission (indicated by 'r-x' in the group ACL entry), but the user-specific deny entry for jdoe takes precedence. Option C is wrong because the mask entry (often 'r-x') restricts only the maximum permissions for named users and groups, but it does not override a user-specific deny entry; the deny entry explicitly sets permissions to none. Option D is wrong because the owner's permissions (e.g., 'rwx') are irrelevant when a user-specific ACL entry denies all access; the deny entry applies directly to jdoe.

Practice this question →

MCQhard

An administrator accidentally deleted the group 'sales' which is the primary group of several users. What is the immediate effect on those users?

A.Their files will show a missing GID in directory listings

B.The system will recreate the group automatically

C.Their primary group will be changed to their UID

D.They will be unable to log in

AnswerA

When the sales group is deleted, the group definition is removed from /etc/group, but the GID itself remains in the inode metadata of any files previously owned by that group. The ls command invokes getgrgid() to map that GID back to a group name; when the mapping fails, ls falls back to printing the raw numeric GID. As a result, directory listings show an unresolved numeric GID rather than the name 'sales', while the files themselves remain intact and fully accessible.

Why this answer

When a group is deleted, the system does not retroactively change the GID stored in the /etc/passwd file for users whose primary group was that group. The GID field in /etc/passwd still contains the numeric GID of the deleted group, but since the group no longer exists in /etc/group, the system cannot resolve that GID to a group name. As a result, commands like ls -l will display the numeric GID instead of the group name for files owned by those users, because the GID-to-name mapping fails.

Exam trap

A common misconception is that deleting a group will prevent users from logging in or will automatically reassign their primary group. In Red Hat Enterprise Linux, login is unaffected and the GID remains in /etc/passwd until manually changed, so files will show the numeric GID instead of the group name.

How to eliminate wrong answers

Option B is wrong because Linux does not automatically recreate deleted groups; group management is entirely manual via groupadd, groupdel, and groupmod commands. Option C is wrong because the primary group GID in /etc/passwd remains unchanged; it is not replaced by the user's UID — the UID and GID are independent fields. Option D is wrong because login authentication checks the user's password and shell, not the existence of the primary group; users can still log in even if their primary group is missing.

Practice this question →

Multi-Selecteasy

Which TWO commands can be used to add a user to an existing supplementary group without removing them from other groups?

Select 2 answers

A.groupmod -a user group

B.usermod -a -G group user

C.usermod -g group user

D.usermod -G group user

E.gpasswd -a user group

AnswersB, E

The -a (append) flag, when combined with -G, adds the specified supplementary group to the user's existing set of supplementary groups without disturbing any current memberships. Because -a is required to prevent -G from overwriting the full list, this is the standard, safe method for adding a user to a secondary group. For instance, usermod -a -G wheel alice would let alice retain all her other group memberships while gaining wheel privileges.

Why this answer

The `usermod -a -G group user` command appends the user to the specified supplementary group without affecting their membership in other groups. The `-a` (append) flag must be used with `-G` to add the user to additional groups; without `-a`, the `-G` option replaces all supplementary group memberships with the listed groups.

Exam trap

The trap here is that candidates often confuse `-g` (primary group) with `-G` (supplementary groups) and forget that `-G` without `-a` overwrites all supplementary group memberships, leading to accidental removal from other groups.

Practice this question →

MCQhard

A Red Hat Enterprise Linux 9 system enforces a security policy that user accounts must be disabled after 90 days of inactivity. The system administrator has configured /etc/shadow accordingly with the proper fields. User 'bob' has been on leave for 95 days. When bob returns and tries to log in, he is unable to do so. The administrator checks the shadow file and sees that bob's password expiration date has passed and the account is locked due to inactivity (the inactivity period has exceeded). The administrator wants to immediately reactivate bob's account without changing the password, and also wants to set the account to expire in 30 days from now (relative to the current date). Which set of commands should the administrator run to achieve this goal?

A.chage -E $(date -d +30days +%Y-%m-%d) bob; chage -I -1 bob

B.usermod -e 2024-12-31 bob; passwd -S bob

C.chage -d 0 bob; usermod -L bob

D.usermod -e $(date -d +30days +%Y-%m-%d) bob; passwd -u bob

AnswerA

This combination is correct because chage -E $(date -d +30days +%Y-%m-%d) bob dynamically sets the account expiration date to exactly 30 days from today, while chage -I -1 bob sets the inactivity period to -1, which disables the automatic locking of an account whose password has expired. This directly clears the lockout caused by exceeding the inactivity threshold, so Bob's account can be used again for the next 30 days. It addresses both the expired expiration date and the inactivity-based lock.

Why this answer

`chage -E $(date -d +30days +%Y-%m-%d) bob` sets the account expiration date to 30 days from now, and `chage -I -1 bob` disables the inactivity period (sets it to -1, meaning no inactivity lockout), which immediately reactivates the account without changing the password. This directly addresses the requirement to unlock the account (which was locked due to exceeding the inactivity period) and set a new expiration date.

Exam trap

The trap here is that candidates confuse password lock (`passwd -l`/`passwd -u`) with inactivity lock (`chage -I`), and assume `passwd -u` can reactivate an account disabled by inactivity, when in fact only `chage -I` or modifying the INACTIVE field in `/etc/shadow` can do that.

How to eliminate wrong answers

Option B is wrong because `usermod -e 2024-12-31 bob` sets a static expiration date (not relative to current date) and `passwd -S bob` only shows the password status, it does not unlock the account or disable the inactivity lock. Option C is wrong because `chage -d 0 bob` forces a password change on next login (which violates 'without changing the password'), and `usermod -L bob` locks the account, which is the opposite of reactivating it. Option D is wrong because `usermod -e $(date -d +30days +%Y-%m-%d) bob` correctly sets the expiration date, but `passwd -u bob` only unlocks a password-locked account (via `passwd -l`), not an account locked due to inactivity in /etc/shadow (the INACTIVE field); it does not reset the inactivity counter or disable the inactivity period.

Practice this question →

MCQhard

You are managing a Red Hat Enterprise Linux 8 server that hosts backup scripts. A user named 'backup' (UID 1005) is a member of the 'backup' group. The directory /var/backups is owned by root:backup with permissions 775. The 'backup' user needs to create files in this directory. However, when the user attempts to create a file, they receive 'Permission denied'. You verify that 'backup' is indeed listed in the backup group in /etc/group. The user's current shell was started after their last login. Which of the following is the most likely cause and solution?

A.The directory lacks the setgid bit; set it with 'chmod g+s /var/backups'.

B.The user needs to log out and log back in to refresh their group membership.

C.The user's umask is too restrictive, preventing file creation. Change the umask to 002.

D.The user should use 'newgrp backup' to switch to the backup group temporarily.

AnswerB

Linux determines a user's supplemental groups at login time from the /etc/group database and stores them in the process credentials via initgroups(). When a user is added to a new group after their current login, existing shells and daemons keep the old group set; simply editing /etc/group does not update running sessions. The user must end the session and log in again so that login(1) or systemd user session reinitializes the supplementary groups, allowing access to files and directories that require that group.

Why this answer

The user 'backup' is already a member of the 'backup' group in /etc/group, but the current shell session was started before the group membership was added or refreshed. On Linux, group membership is determined at login time by the PAM modules; simply adding a user to a group does not affect already running processes. The user must log out and log back in (or start a new login shell) to acquire the new group membership via the initgroups() system call, which populates the process's supplementary group list.

Exam trap

The trap here is that candidates often think the setgid bit or umask is the issue, but the real problem is that group membership changes do not apply to existing login sessions—a fundamental Linux behavior that Red Hat EX200 frequently tests.

How to eliminate wrong answers

Option A is wrong because the setgid bit (chmod g+s) would cause new files to inherit the group of the directory, but the user already has group write permission via the 775 permissions; the issue is that the user's process does not have the 'backup' group in its supplementary groups, not that the directory lacks setgid. Option C is wrong because umask only affects the default permissions of newly created files, not the ability to create files at all; even with a restrictive umask (e.g., 077), the user could still create files if they had write permission, but they would be created with no group/other permissions. Option D is wrong because 'newgrp backup' would work to switch the user's effective group to 'backup' temporarily, but it is not the most likely cause or the best solution; the question asks for the most likely cause and solution, and the standard fix is to log out and log back in to refresh group membership for all future sessions.

Practice this question →

MCQhard

A system administrator needs to ensure that a user named 'bob' can access a shared directory '/data' owned by group 'developers'. The directory has permissions 2775 and is owned by root:developers. Bob is a member of the 'developers' group. However, when Bob tries to create a file in '/data', it fails with 'Permission denied'. What is the most likely cause?

A.The directory has incorrect SELinux context

B.Bob's umask is set to 0077

C.The setgid bit is not set

D.Bob's primary group is not developers

AnswerA

Even when the directory's mode and ownership (2775, root:developers) grant Bob write access, SELinux performs a separate mandatory access control check. If /data carries a context type that Bob's domain is not allowed to write to (for example, default_t instead of a type like public_content_rw_t or a domain-specific type), the kernel denies the operation with EACCES. This appears as a permission problem though standard permissions are correct. To fix, restore or apply the correct context, e.g., restorecon -Rv /data or a custom semanage fcontext rule.

Why this answer

The directory '/data' has permissions 2775, which grants read, write, and execute to the group 'developers'. Bob is a member of 'developers', so standard Unix permissions should allow him to create files. However, the failure with 'Permission denied' despite correct group membership and permissions strongly indicates that SELinux is enforcing a policy that denies Bob write access.

The most likely cause is that the directory lacks the correct SELinux context (e.g., `default_t` instead of a type like `public_content_rw_t` or a context that allows write operations).

Exam trap

Red Hat often tests the misconception that group membership alone guarantees access, ignoring that SELinux can block operations even when Unix permissions are correct; the trap here is that candidates focus on umask or primary group instead of recognizing SELinux as the likely cause when permissions and group membership appear correct.

How to eliminate wrong answers

Option B is wrong because umask affects the default permissions of newly created files, not the ability to create them; a umask of 0077 would not cause a 'Permission denied' error when creating a file if the directory permissions allow write access. Option C is wrong because the setgid bit (2775) is already set (the '2' in the permissions), so it is not missing; the setgid bit ensures new files inherit the group, but its absence would not cause a 'Permission denied' error. Option D is wrong because Bob's primary group does not need to be 'developers'; as a member of the 'developers' group, he has group-level access to the directory regardless of his primary group.

Practice this question →

MCQhard

Alice tries to run 'sudo less /var/log/messages' and gets 'Sorry, user alice is not allowed to execute /usr/bin/less /var/log/messages as root on this host.' Why?

A.The command path must exactly match, including arguments

B.The secure_path does not include /usr/bin

C.The sudoers allows only specific commands with specific arguments

D.The /var/log/messages file does not exist

AnswerC

This is the correct reason. A sudoers entry such as 'alice ALL=(root) /usr/bin/less /var/log/secure' grants permission only for that exact command line, including the specific argument. Because alice is attempting '/usr/bin/less /var/log/messages', sudo finds no matching entry in the user's command list and reports 'not allowed to execute'—the error is purely a policy mismatch.

Why this answer

Sudoers rules can restrict commands to specific arguments. The error message indicates that the sudoers configuration explicitly allows 'less' only with certain arguments (or none), and the attempt to run 'less /var/log/messages' violates that restriction. Sudo matches both the command path and the argument list against the sudoers entries, and if the arguments do not match, access is denied.

Exam trap

Red Hat RHCSA often tests the misconception that sudo denies commands based on the binary path alone, when in fact argument-specific restrictions in sudoers are the cause of such errors.

How to eliminate wrong answers

Option A is wrong because sudo does not require the command path to include arguments in the sudoers rule; arguments are matched separately, and the error is not about path mismatch. Option B is wrong because secure_path affects the default PATH for commands run via sudo, but the error message explicitly states the command '/usr/bin/less /var/log/messages' is not allowed, indicating the path is resolved and the issue is with the argument restriction. Option D is wrong because if the file did not exist, sudo would still execute less (which would then fail with a 'No such file' error), not produce a sudo permission error.

Practice this question →

MCQmedium

An administrator wants to ensure that any new user accounts created on the system have a default primary group matching the username. What change is needed?

A.Set GROUP to same name in /etc/default/useradd

B.Set USERGROUPS_ENAB to no; then create user with -g

C.Set USERGROUPS_ENAB to yes in /etc/login.defs

D.Set CREATE_HOME to yes in /etc/login.defs

AnswerC

When USERGROUPS_ENAB is set to yes, useradd automatically creates a private group whose name and GID match the new username and sets that group as the user's primary group. This is the default behavior on RHEL and derivatives, providing a one-to-one mapping between user and group. As long as this setting remains enabled, every new user account will have its own private primary group.

Why this answer

Setting USERGROUPS_ENAB to yes in /etc/login.defs instructs the useradd command to automatically create a private group with the same name as the new user and assign it as the user's primary group. This is the default behavior in Red Hat Enterprise Linux and ensures that each new user has a matching primary group without manual intervention.

Exam trap

The trap here is that candidates often confuse the GROUP setting in /etc/default/useradd (which sets a fixed default group) with the USERGROUPS_ENAB mechanism that dynamically creates a matching group, leading them to incorrectly select Option A.

How to eliminate wrong answers

Option A is wrong because the GROUP setting in /etc/default/useradd specifies the default primary group for new users (e.g., GROUP=100 for users group), not a group matching the username. Option B is wrong because setting USERGROUPS_ENAB to no disables the automatic creation of a private group, and using -g manually would require the group to already exist, not create it automatically. Option D is wrong because CREATE_HOME controls whether a home directory is created for new users, not the primary group assignment.

Practice this question →

Multi-Selecteasy

Which TWO commands can be used to create a new user account in Red Hat Enterprise Linux 8?

Select 2 answers

A.adduser

B.groupadd

C.usermod

D.passwd

E.useradd

AnswersA, E

On RHEL, adduser is a symbolic link to useradd, so it invokes the exact same low-level tool and creates a user account with the defaults defined in /etc/login.defs and /etc/default/useradd. Because it is just an alias, it does not provide an interactive front-end as it does on Debian-based systems, but it is still a valid way to create a new user.

Why this answer

Both `adduser` and `useradd` are commands that create a new user account in Red Hat Enterprise Linux 8. `adduser` is a symbolic link to `useradd` in RHEL 8, so they perform the same function. The `useradd` command creates a new user with default settings from `/etc/default/useradd` and `/etc/login.defs`, while `adduser` behaves identically.

Exam trap

The trap here is that candidates may think `adduser` is a separate, interactive command (as in Debian-based systems), but in RHEL 8 it is identical to `useradd`, and `passwd` or `groupadd` are often mistakenly chosen for user creation.

Practice this question →

MCQeasy

A helpdesk ticket states that user 'bob' cannot write to his own home directory. The directory /home/bob has permissions drwxr-xr-x and is owned by root:root. What command will fix this?

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

B.usermod -d /home/bob bob

C.chmod 755 /home/bob

D.chown bob:bob /home/bob

AnswerD

chown bob:bob changes both the user and group ownership of /home/bob to bob, making bob the owner with the rwx bits applying to him. This is the standard fix because each user's home directory should be owned by that user and their primary group, not by root. After this command, bob's existing owner permissions take effect, and he can create, modify, and delete files in his home directory.

Why this answer

The home directory /home/bob is owned by root:root with permissions drwxr-xr-x, meaning only root can write to it. User 'bob' cannot write because he is not the owner. Option D (chown bob:bob /home/bob) changes the owner and group to bob, granting him write access via the owner 'w' permission.

Exam trap

Red Hat exams often test the distinction between permission bits and ownership; candidates may mistakenly think changing permissions (chmod) will fix a write issue when the real problem is that the user is not the owner.

How to eliminate wrong answers

Option A is wrong because setfacl adds an ACL entry for bob, but the underlying ownership issue remains; ACLs are not the standard fix for incorrect ownership and may not be enabled or expected in a basic EX200 scenario. Option B is wrong because usermod -d changes the home directory path in /etc/passwd but does not alter permissions or ownership of the existing directory. Option C is wrong because chmod 755 sets permissions to rwxr-xr-x, which already matches the current permissions; it does not address the ownership problem that prevents bob from writing.

Practice this question →

MCQmedium

A company policy requires that when a user is deleted, all files owned by that user in /home should be reassigned to a 'guest' account. Which command accomplishes this?

A.usermod -l guest olduser

B.find /home -user olduser -exec chown guest {} +

C.userdel -r olduser

D.rsync -a /home/olduser/ /home/guest/

AnswerB

find /home -user olduser -exec chown guest {} + is correct because it searches /home for every file whose owner matches the username olduser (which resolves to the UID) and executes chown guest on them in one batched command, thanks to the + terminator. This directly transfers ownership of each located file to guest, satisfying the policy efficiently. The find approach also covers files outside olduser's home directory that reside anywhere under /home, whereas other options only handle the home directory itself.

Why this answer

Uses `find` to locate all files owned by `olduser` under `/home` and then executes `chown guest` on them, which reassigns ownership to the `guest` account. This directly satisfies the policy requirement without affecting the user account itself or copying files.

Exam trap

Red Hat often tests the distinction between modifying user attributes (usermod), deleting users (userdel), copying files (rsync), and directly reassigning file ownership (find + chown), expecting candidates to recognize that only the latter changes ownership without altering or removing the files.

How to eliminate wrong answers

Option A is wrong because `usermod -l` changes the login name of an existing user, not ownership of files; it would rename `olduser` to `guest`, which does not reassign ownership to a separate `guest` account and may conflict if `guest` already exists. Option C is wrong because `userdel -r` removes the user and their home directory, which deletes files rather than reassigning ownership. Option D is wrong because `rsync -a` copies files from one directory to another, leaving the original files still owned by `olduser` and not reassigning ownership of the originals.

Practice this question →

Multi-Selectmedium

Which TWO commands can be used to add a user to a secondary group without removing existing supplementary group memberships? (Choose exactly 2)

Select 2 answers

A.usermod -aG group user

B.usermod -AG group user

C.adduser user group

D.gpasswd -a user group

E.groupadd -a user group

AnswersA, D

The `-a` flag in `usermod -aG group user` is the critical component: it stands for 'append', meaning the specified user is added to the supplementary group listed after `-G` without removing the user from any existing supplementary groups. Omitting `-a` would replace the user's entire supplementary group membership list with just the one group, which can unexpectedly strip access to other groups. This command directly edits /etc/group and /etc/passwd to update group membership.

Why this answer

`usermod -aG` appends the user to the specified supplementary group(s) without affecting any existing supplementary group memberships. The `-a` flag (append) must be used with `-G` to avoid overwriting the current list of supplementary groups. This is the standard method in Red Hat Enterprise Linux for adding a user to an additional group while preserving all other group memberships.

Exam trap

The trap here is that candidates often confuse `usermod -G` (which replaces all supplementary groups) with `usermod -aG` (which appends), and may also mistakenly think `groupadd` or `adduser` can modify group memberships, when in fact only `usermod -aG` and `gpasswd -a` are the correct tools for this task.

Practice this question →

Multi-Selectmedium

A system administrator needs to ensure that the user 'jdoe' can read files in the shared directory /project/data which is owned by group 'project'. The user 'jdoe' is currently not a member of the 'project' group. Which TWO steps should the administrator take to add 'jdoe' to the 'project' group? (Choose two.)

Select 2 answers

A.gpasswd -a jdoe project

B.groupmod -A jdoe project

C.vigr to add jdoe to project group

D.useradd -G project jdoe

E.usermod -aG project jdoe

AnswersA, E

gpasswd -a jdoe project is correct because it directly appends the existing user jdoe to the supplementary group 'project' by modifying the /etc/group file. The -a (add) flag explicitly instructs gpasswd to add the user to the group, making it a dedicated group-administration command. This is a safe, standard method that does not affect the user's primary group or any other group memberships.

Why this answer

`gpasswd -a jdoe project` adds the user 'jdoe' to the 'project' group by appending the user to the group's member list in /etc/group. This command is specifically designed for group membership management and does not require the user to be logged out; the change takes effect on the next login.

Exam trap

In Red Hat RHCSA exams, a common trap is confusing `usermod -G` (which overwrites all supplementary groups) with `usermod -aG` (which appends). Also, candidates may mistakenly think `useradd` modifies an existing user, but it is only for new users. The correct commands to add a user to an existing group are `usermod -aG` or `gpasswd -a`.

Practice this question →

MCQeasy

A new employee named asmith needs a user account with a home directory and a specific UID of 1500. Which command accomplishes this?

A.useradd -m -u 1500 asmith

B.adduser -uid 1500 asmith

C.useradd -h /home/asmith -u 1500 asmith

D.useradd -d /home/asmith -U 1500 asmith

AnswerA

The `-m` flag tells `useradd` to create the user's home directory (`/home/asmith`) immediately, and `-u 1500` explicitly assigns UID 1500. This is the correct way to create a new account for asmith with both a usable home directory and a known UID for ownership purposes.

Why this answer

`useradd -m -u 1500 asmith` creates the user asmith with a home directory (via `-m`) and assigns a specific UID of 1500 (via `-u`). The `-m` flag ensures the home directory is created if it does not exist, which is required by the question.

Exam trap

The trap here is confusing `-u` (UID) with `-U` (create user group) and mistaking `-h` for home directory instead of the correct `-d` flag.

How to eliminate wrong answers

Option B is wrong because `adduser` is a Perl script (not a standard command on RHEL/CentOS) and `-uid` is not a valid flag; the correct flag for UID with `adduser` would be `--uid`, but the question expects the standard `useradd` command. Option C is wrong because `-h` is not a valid flag for `useradd`; the flag to specify a home directory is `-d`, and `-h` is used for help. Option D is wrong because `-U` creates a user group with the same name as the user (not a UID), and the UID should be specified with `-u` (lowercase), not `-U`.

Practice this question →

MCQeasy

A company needs to create a user account for a temporary contractor who will work for exactly 90 days. The account must be automatically disabled after 90 days. Which command should the administrator use?

A.useradd -f 90 contractor

B.useradd -e $(date -d '+90 days' +%Y-%m-%d) contractor

C.useradd -e 90 contractor

D.useradd -f 90 -e 0 contractor

AnswerB

Correct. The -e option specifies an account expiration date in YYYY-MM-DD format. Using $(date -d '+90 days' +%Y-%m-%d) dynamically calculates the date 90 days from today, ensuring the account is disabled after exactly 90 days.

Why this answer

The `-e` (expiration date) option sets the date on which the user account will be disabled. Using `$(date -d '+90 days' +%Y-%m-%d)` dynamically calculates the exact date 90 days from today in YYYY-MM-DD format, which meets the requirement for automatic disable after exactly 90 days.

Exam trap

The trap here is confusing the `-e` (account expiration date) option with a number of days, when it actually requires a specific date in YYYY-MM-DD format, and confusing `-f` (inactive days after password expiry) with account expiration.

How to eliminate wrong answers

Option A is wrong because the `-f` option sets the number of days after a password expires until the account is permanently disabled (inactive), not the account expiration date itself; it does not disable the account after 90 days from creation. Option C is wrong because the `-e` option expects a date in YYYY-MM-DD format, not a number of days; passing `90` will be interpreted as an invalid date and the account will not be set to expire. Option D is wrong because `-f 90` sets the inactivity period to 90 days after password expiry, and `-e 0` sets the account expiration date to January 1, 1970 (epoch), which disables the account immediately, not after 90 days.

Practice this question →

MCQhard

After being added to a new supplementary group with usermod -aG, a user logs out and back in but still cannot access files owned by that group. Which command should the user run to verify current effective group membership?

A.newgrp -c 'groups'

B.id

C.groups $(whoami)

D.usermod -g

AnswerB

The `id` command with no arguments reads the kernel's credential data for the current process via getgroups(), displaying the real UID, effective UID, all supplementary GIDs, and, where available, SELinux context. Because it reports actual process credentials rather than performing a database lookup, it is the definitive way to verify which groups your current shell truly belongs to after a group change.

Why this answer

The `id` command displays the real and effective user/group IDs and all supplementary groups for the current process, making it the correct way to confirm whether the new group is actually active in the current shell. `groups $(whoami)` is incorrect because it uses the username argument, which reads the group membership from the user database (e.g., getgrouplist) and does not necessarily reflect the groups in the current process. This can misleadingly show the new group even if the current shell has not inherited it. `newgrp -c 'groups'` is not standard and is meant for changing the real group ID, not for displaying groups. `usermod -g` modifies group settings and requires superuser privileges, so it does not verify membership.

Exam trap

After `usermod -aG`, the new group is only active in new login sessions. To verify if the current shell actually has the group, use `id` (no arguments). Do not use `groups $(whoami)`, because that checks the user's group list from /etc/group and may show the new group even if the current process does not have it.

How to eliminate wrong answers

Option A is wrong because `newgrp -c 'groups'` is not a valid syntax; `newgrp` is used to start a new shell with a different primary group, not to list groups, and the `-c` option is not supported in that way. Option C is wrong because `groups $(whoami)` runs the `groups` command for the username returned by `whoami`, which may reflect the user's group membership from the user database but does not necessarily show the effective groups of the current shell session if the session was started before the group change. Option D is wrong because `usermod -g` is used to change a user's primary group, not to verify current group membership; it requires root privileges and modifies the user database, not the running session.

Practice this question →

Matchingmedium

Match each firewall zone to its default trust level.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Low trust; only allow selected incoming connections

Moderate trust; for private networks

High trust; accept all connections

For publicly accessible systems isolated from internal network

Why these pairings

Correct matches: drop blocks all traffic silently, public allows only basic services, internal allows more services, trusted allows all. Common confusions include mixing drop with trusted or public with internal.

Practice this question →

MCQmedium

A user was recently added to the 'testgrp' group using `usermod -aG testgrp user1`. However, when they try to access a file owned by testgrp with permissions 660, they get permission denied. What is the most likely reason?

A.The user's primary group is not testgrp.

B.The user did not log out and log back in.

C.The file's group owner is not testgrp.

D.The file's ACL overrides group permissions.

AnswerB

When a user is added to a group via usermod -aG or gpasswd, the change is written to /etc/group, but the running login session still holds the old supplementary group list cache. The kernel caches group memberships in the process credential structure at login, and does not reload them dynamically. Until the user logs out and back in (or runs newgrp/su), the new testgrp membership will not be reflected in group-based permission checks. This is exactly why the user cannot access the file.

Why this answer

When a user is added to a supplementary group with `usermod -aG`, the group membership change does not take effect in the user's current login session. The user must log out and log back in (or start a new login shell) for the new group to be recognized by the kernel's process credential system. Without this, the user's process lacks the group ID in its supplementary group list, so access to a file with group permissions (660) is denied.

Exam trap

The trap here is that candidates assume `usermod -aG` immediately grants access, overlooking that group membership changes require a new login session to take effect in the process's credential cache.

How to eliminate wrong answers

Option A is wrong because the primary group is irrelevant for accessing a file owned by a supplementary group; the file's group permissions are checked against all groups the user belongs to, including supplementary groups. Option C is wrong because the question states the file is owned by testgrp, so the group owner is correct; if it were not, the user would not get group permissions but could still get 'other' permissions (which are 0 in 660). Option D is wrong because there is no mention of ACLs in the scenario, and standard POSIX permissions (660) are in effect; ACLs would only override if explicitly set, and the question does not indicate that.

Practice this question →

Drag & Dropmedium

Arrange the steps to configure a network bond (mode 1) using two interfaces (eth0, eth1) in RHEL.

Drag or tap steps into the slots.

Steps

Order

1Step 1

2Step 2

3Step 3

4Step 4

Why this order

Network bonding requires creating a bond interface and configuring slaves, then restarting network.

Practice this question →

MCQeasy

An administrator wants to modify the default expiration settings for new user passwords. Which file should be modified?

A./etc/shadow

B./etc/pam.d/passwd

C./etc/security/pwquality.conf

D./etc/login.defs

AnswerD

The /etc/login.defs file contains the system-wide defaults used by useradd (and other account tools) when creating new accounts, including PASS_MAX_DAYS, PASS_MIN_DAYS, and PASS_WARN_AGE. These values determine the default password aging policy for newly created users and are stored later in the shadowed per-user fields. Modifying login.defs changes the default for future accounts; chage or usermod can override an individual account afterward.

Why this answer

The /etc/login.defs file contains default settings for user account creation, including password aging parameters such as PASS_MAX_DAYS, PASS_MIN_DAYS, and PASS_WARN_AGE. Modifying this file changes the default expiration settings for new user passwords system-wide, as these values are applied when a user is created via useradd or similar tools.

Exam trap

Candidates often mistake /etc/shadow as the place to modify default password expiration settings because it contains per-user expiration fields. However, /etc/login.defs defines system-wide defaults for new users.

How to eliminate wrong answers

Option A is wrong because /etc/shadow stores per-user encrypted password hashes and aging information, not system-wide default expiration settings; modifying it would only affect individual users, not defaults for new users. Option B is wrong because /etc/pam.d/passwd is a PAM configuration file for the passwd command, controlling authentication behavior during password changes, not default expiration values. Option C is wrong because /etc/security/pwquality.conf configures password quality and strength requirements (e.g., length, complexity), not expiration or aging defaults.

Practice this question →

Multi-Selecthard

Which THREE statements about /etc/shadow are true? (Choose exactly 3)

Select 3 answers

A.Contains account expiration dates.

B.Contains the date of last password change.

C.Contains encrypted password hashes.

D.Is readable by all users.

E.Contains user ID numbers.

AnswersA, B, C

The /etc/shadow file stores account expiration dates in the eighth field (field 8), which is the number of days since the epoch until the account is disabled. This field is used by the system to enforce account aging policies.

Why this answer

The /etc/shadow file stores account expiration dates in the ninth field (field 9), which is the number of days since the epoch until the account is disabled. This field is used by the system to enforce account aging policies, such as automatically locking accounts after a set period of inactivity.

Exam trap

Red Hat often tests the distinction between /etc/passwd and /etc/shadow, trapping candidates who think UIDs or group membership are in shadow, or that shadow is world-readable like passwd.

Practice this question →

MCQeasy

A system administrator needs to ensure that the user 'jdoe' cannot log in via SSH but can still use other services like FTP. Which approach should the administrator take?

A.Lock the user account with 'usermod -L jdoe'

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

C.Remove the user's home directory

D.Change the user's shell to /sbin/nologin

AnswerD

Setting jdoe's shell to /sbin/nologin in /etc/passwd makes PAM deny interactive login sessions, typically printing 'This account is currently not available.' FTP daemons such as vsftpd or proftpd authenticate against /etc/shadow without invoking the user's shell, so they still allow file transfers. Because /sbin/nologin only blocks shell access and does not alter the password hash, it is the standard, targeted solution for allowing non-login services while prohibiting interactive logins.

Why this answer

Changing the user's shell to /sbin/nologin prevents interactive login via SSH (which requires a valid shell listed in /etc/shells) while still allowing non-interactive services like FTP, which typically do not check the user's shell. This approach specifically blocks SSH access without locking the account or affecting other authentication methods.

Exam trap

The trap here is that candidates often confuse account locking (usermod -L) with shell restriction, assuming that locking the account only affects SSH, when in fact it blocks all password-based authentication, including FTP and other services.

How to eliminate wrong answers

Option A is wrong because 'usermod -L' locks the account by placing an exclamation mark in the password hash field, which prevents all password-based authentication, including FTP, thus blocking the user from using other services. Option B is wrong because 'passwd -d' deletes the password, leaving the account with an empty password, which may allow login without a password (depending on PAM configuration) and does not specifically block SSH while allowing FTP. Option C is wrong because removing the home directory does not prevent SSH login; the user could still authenticate and log in, though they would have no home directory, potentially causing errors but not blocking access.

Practice this question →

MCQeasy

A server has been compromised, and the administrator suspects an unauthorized user account may have been created. Which file should be examined to list all local user accounts?

A./etc/shadow

B./etc/passwd

C./etc/shells

D./etc/login.defs

AnswerB

/etc/passwd is the authoritative, world-readable file that lists every local user account on a Linux system, with one line per account. Each colon-separated record contains the username, a placeholder for the password (typically x), the numeric UID, primary GID, GECOS comment, home directory, and login shell. This is exactly what an administrator should inspect to identify unexpected accounts, such as a newly added UID 0 user or a bad actor’s backdoor entry.

Why this answer

The /etc/passwd file is the primary local user account database on Linux systems, listing all user accounts with fields such as username, UID, GID, GECOS, home directory, and login shell. Examining this file reveals every local user account, including any unauthorized ones that may have been created, because each account must have an entry here to be recognized by the system.

Exam trap

Red Hat often tests the misconception that /etc/shadow contains the list of user accounts, but it only stores password hashes and aging data; the actual account list is always in /etc/passwd.

How to eliminate wrong answers

Option A is wrong because /etc/shadow stores encrypted password hashes and password aging information, not the list of user accounts; it is a companion file to /etc/passwd but does not contain usernames by itself. Option C is wrong because /etc/shells lists valid login shells (e.g., /bin/bash, /bin/sh) and is used by chsh and FTP daemons to validate shell choices, not to enumerate user accounts. Option D is wrong because /etc/login.defs defines configuration defaults for user account creation (e.g., UID ranges, password aging parameters) but does not contain the actual list of user accounts.

Practice this question →

MCQhard

An administrator used the command useradd -D -f 10 to change the default inactivity period. What effect does this have on future user accounts?

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

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

C.New user accounts will be disabled after 10 days of inactivity if the password has expired.

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

AnswerC

The -f 10 option sets the INACTIVE field in /etc/default/useradd, which becomes the seventh field in the /etc/shadow entry, specifying how many days after a password expires the account is disabled. If the password never expires or is changed before that, inactivity does not apply; only after expiry does the 10-day countdown begin. When the countdown ends, the account is locked, preventing login until an administrator reactivates it.

Why this answer

The `useradd -D -f 10` command modifies the default value for the `INACTIVE` field in `/etc/default/useradd`. This field sets the number of days after a password expires that the account will be disabled if the password is not changed. Option C correctly describes this behavior: new user accounts will be disabled after 10 days of inactivity following password expiration.

Exam trap

The trap here is confusing the `-f` (inactivity period after password expiration) with password aging (`-M` or `PASS_MAX_DAYS`), leading candidates to incorrectly select options B or D.

How to eliminate wrong answers

Option A is wrong because `-f` sets the inactivity period, not the default group; the default group is set with `-g` or `-G`. Option B is wrong because the maximum password age is controlled by the `PASS_MAX_DAYS` parameter in `/etc/login.defs`, not by the `-f` flag. Option D is wrong because the `-f` flag sets the inactivity period after password expiration, not the password expiration itself; password expiration is set with `-e` or via `chage -M`.

Practice this question →

MCQeasy

An administrator wants to add the user 'jane' to the supplementary groups 'wheel' and 'docker' without removing her from other groups. Which command should be used?

A.groupmems -a jane -g wheel,docker

B.usermod -aG wheel,docker jane

C.usermod -a -G wheel,docker jane

D.usermod -G wheel,docker jane

AnswerB, C

The -aG form is a compact combined option where -a enables append mode and -G specifies the supplementary group list, so the effect is exactly the same as usermod -a -G. It adds jane to wheel and docker while retaining any other supplementary groups she already has. Although it is less readable than the separated form, it is a fully valid and correct way to accomplish the task.

Why this answer

Both `usermod -aG wheel,docker jane` and `usermod -a -G wheel,docker jane` are valid commands to append the user to the specified supplementary groups without removing her from other groups. The `-a` (append) flag can be combined with `-G` as `-aG` or provided separately (`-a -G`); both forms work identically. Option D (`usermod -G`) without `-a` would overwrite all supplementary groups, which is incorrect.

Option A uses `groupmems`, which is not the standard command for this task and has incorrect syntax.

Exam trap

The exam may include both `-aG` and `-a -G` as options. Both are correct and achieve the append effect. The dangerous trap is choosing `-G` alone (option D), which replaces all existing supplementary groups.

How to eliminate wrong answers

Option A is wrong because `groupmems` is used to manage members of a single group (e.g., add/remove users from one group at a time) and does not support specifying multiple groups in a comma-separated list; it would fail or behave unexpectedly. Option C is wrong because `-a -G` is syntactically valid but functionally identical to `-aG`; however, the option order `-a -G` is non-standard and may cause parsing issues on some systems, making it less reliable than the combined `-aG` form. Option D is wrong because `usermod -G wheel,docker jane` without the `-a` flag will replace all supplementary groups for 'jane' with only 'wheel' and 'docker', removing her from any other groups she belongs to, which violates the requirement to not remove her from other groups.

Practice this question →