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

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 →

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 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 →

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 →

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 →

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-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 →

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 →

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 →

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 →

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 →