User and Group Management practice questions

useradd -U 1050 -h /home/alice alice

Why wrong: Incorrect. -U is not a valid flag (it means create group with same name but uppercase) and -h is not a valid flag; the correct flag for home directory is -d.

useradd --uid 1050 --home /home/alice alice

Why wrong: Incorrect. --home specifies the home directory but does not create it; --create-home or -m is needed to create the directory.

The user's primary group is different from the 'developers' group.

Why wrong: Primary group mismatch does not prevent supplementary group access after re-login.

The user is using 'newgrp developers' but is no longer a member.

Why wrong: Using 'newgrp' without being a member will fail, but the issue is that the user hasn't refreshed their session properly.

The 'id' command shows the old group because the user's shell is still running.

Why wrong: 'id' reads from kernel; after re-login, it should show updated groups.

useradd -d /data/users -c 2025-12-31 john

Why wrong: -c sets the GECOS comment, not expiry.

adduser --home /data/users --expiredate 2025-12-31 john

Why wrong: adduser is distribution-specific and interactive; not the standard command.

useradd -m -e 2025-12-31 john

Why wrong: -m creates the home directory in /home/john by default, not /data/users.

chown root:projectteam /project; chmod 2775 /project; setfacl -m g:projectteam:rwx /project

Why wrong: Default ACL not set, so new files may not inherit group permissions.

chown root:projectteam /project; chmod 2775 /project

Why wrong: Sticky bit (1) prevents deletion of others' files, which is not desired.

chown root:projectteam /project; chmod 1770 /project; setfacl -m m::rwx /project

Why wrong: Sticky bit (1) prevents deletion; mask not inherited.

The password must be changed at next login.

Why wrong: That is indicated by the last change field set to 0.

The account is disabled.

Why wrong: Disabled accounts often have '!!' or '*'.

The password is expired.

Why wrong: Expired passwords are shown by a '!' at the start of the hash.

groupmod -p 30 contractors

Why wrong: Incorrect. `groupmod -p` is not a valid option; `groupmod` does not handle password aging.

passwd -x 30 -w 7 contractors

Why wrong: Incorrect. `passwd -x 30 -w 7` can set password aging, but it requires a username, not a group name.

usermod -e 30 contractors

Why wrong: Incorrect. `usermod -e` sets the account expiry date, not password aging.

last

Why wrong: Incorrect. `last` displays historical login and logout records, not current users.

id

Why wrong: Incorrect. `id` prints user identity and group memberships, not login status.

/etc/sudoers

Why wrong: Controls sudo access, not user/group management.

/etc/login.defs

Why wrong: Contains default values for user account creation, but not direct user/group data.

Configure the SSH daemon to allow password authentication for local users

Why wrong: The SSH server already allows password authentication.

Unlock the account using passwd -u jane

Why wrong: The account is not locked according to the administrator's verification.

Remove the password expiry for jane using chage -E -1 jane

Why wrong: Password expiry would cause a warning, not immediate denial.

setfacl -m g:developers:rwx /project/data && chmod 2775 /project/data

Why wrong: ACL grants access but without SGID, new files will inherit the creating user's primary group, not developers.

chown root:developers /project/data && chmod u+s /project/data

Why wrong: chmod u+s sets setuid bit (user), not SGID; new files will inherit the owner's primary group, not developers group.

chmod g+s /project/data && chown root:developers /project/data

Why wrong: Order matters: chmod g+s first on a directory owned by root:root will set SGID, but then chown changes group to developers but may clear SGID on some systems; also new files still inherit primary group without proper group ownership set first.

usermod -d /home/alice alice

Why wrong: -d changes the home directory, not the shell. The shell is still /sbin/nologin.

usermod -u 1002 alice

Why wrong: -u changes the UID, which is already 1002. Does not affect shell.

useradd -m -s /bin/bash alice

Why wrong: useradd creates a new user; alice already exists. This would fail or create a duplicate.

usermod -g docker bob

Why wrong: -g changes the primary group, not supplementary.

usermod -G docker bob

Why wrong: -G without -a replaces all supplementary groups with only docker, removing bob from any other groups.

usermod -G docker bob

Why wrong: Same as B; no -a flag.

chage -W 7 -I 90 svc_backup

Why wrong: -W sets warning days before password expiration; does not affect max days or inactivity.

chage -E 2025-01-01 -I 90 svc_backup

Why wrong: -E sets an absolute account expiration date, not password inactivity lock.

chage -M 90 -I 90 svc_backup

Why wrong: -M 90 sets maximum password age to 90 days, forcing password change; administrator wants password never to expire.

cat /etc/group

Why wrong: Lists all groups, not just those of the current user.

groupmems -l

Why wrong: groupmems lists members of a group, not groups of a user.

getent group

Why wrong: Lists all groups from configured sources.

The devteam group does not include all members; add each user to the devteam group.

Why wrong: The group membership is not the issue; the directory permissions are too restrictive.

The parent directory /data/projects lacks execute permission for devteam; add execute permission to /data/projects.

Why wrong: The parent directory already has rwx for group; execute is present (x in rwx).

The sticky bit is not set; set the sticky bit on proj1 to allow only owners to delete files.

Why wrong: Sticky bit does not affect ability to create files; it affects deletion of files. The immediate issue is no write access.

Set the suid bit on /bin/su.

Why wrong: Incorrect: The suid bit is already set on su; it does not bypass the password prompt.

Run 'usermod -L john'.

Why wrong: Incorrect: This locks the account, preventing any login.

Add 'john' to the 'root' group.

Why wrong: Incorrect: Being in the root group does not grant passwordless su.

'charlie' is not listed by name in the sudoers file.

Why wrong: Membership in the devops group is sufficient; the sudoers rule uses %devops.

'charlie' is also a member of another group that restricts sudo.

Why wrong: No evidence of restriction; the group devops grants the privilege.

The systemctl command is not executable by 'charlie'.

Why wrong: The command has execute permissions for all (chmod 755).

The sudoers file has a syntax error.

Why wrong: No, sudo -l works for alice and bob, so syntax is fine.

Change the group ownership of /var/www/html to 'staff' and set the setgid bit.

Why wrong: Incorrect: This would grant access to all staff members, which is too permissive.

Change John's primary group to 'webgroup' with 'usermod -g webgroup john'.

Why wrong: Incorrect: This changes his primary group, which may affect file creation in other directories.

Set the setgid bit on /var/www/html with 'chmod g+s /var/www/html'.

Why wrong: Incorrect: The setgid bit only affects new files; John still needs group membership to access existing files.

Step 1: Create the user account. Step 2: Set a password. Step 3: Test sudo access. Step 4: Add the user to the sudo group.

Why wrong: This is incorrect because testing sudo access before adding the user to the sudo group will fail, as the user does not yet have sudo privileges.

Step 1: Create the user account. Step 2: Add the user to the sudo group. Step 3: Test sudo access. Step 4: Set a password.

Why wrong: This is incorrect because testing sudo access requires the user to have a password set; otherwise, the test will fail or be insecure.

Step 1: Add the user to the sudo group. Step 2: Create the user account. Step 3: Set a password. Step 4: Test sudo access.

Why wrong: This is incorrect because the user must exist before being added to any group; adding a non-existent user to a group will result in an error.

Start the service, then create the unit file, then enable for boot, then check status.

Why wrong: This is incorrect because the unit file must be created before the service can be started; you cannot start a service that hasn't been defined yet.

Enable the service for boot, then create the unit file, then start, then check status.

Why wrong: This is incorrect because you cannot enable a service that does not have a unit file yet; enabling requires the file to be present.

Create the unit file, then start the service, then enable for boot, then check status.

Why wrong: This is incorrect because starting before enabling will not ensure the service starts at boot; enabling must be done before or after starting to set the boot behavior, but it's typically done before starting to avoid a missed boot dependency.