Courseiva

CCNA Manage Security Questions

38 questions · Manage Security topic · All types, answers revealed

Practice these questionsExam hubAll questions
1
MCQeasy

A system administrator needs to allow members of the 'developers' group to run any command as root without being prompted for a password. Which sudoers configuration line should be added?

A.%developers ALL=(root) PASSWD: ALL
B.%developers ALL=(ALL) NOPASSWD: ALL
C.developers ALL=(ALL) NOPASSWD: ALL
D.%developers ALL=(ALL) ALL
AnswerB

This line grants the developers group passwordless sudo for every command as any user on any host. The leading % marks it as a group entry, ALL=(ALL) permits running commands as any target user, and NOPASSWD: ALL overrides the default password prompt. This is the exact configuration needed to satisfy the requirement of allowing group members to run commands without supplying a password.

Why this answer

The line `%developers ALL=(ALL) NOPASSWD: ALL` grants all members of the 'developers' group (indicated by the `%` prefix) permission to run any command as any user (including root) via sudo without being prompted for a password. The `NOPASSWD` tag is the key directive that bypasses password authentication, which directly matches the requirement to run commands as root without a password.

Exam trap

Red Hat often tests the distinction between user and group entries in sudoers, where omitting the `%` prefix causes candidates to mistakenly apply the rule to a user instead of a group, leading to a non-functional configuration.

How to eliminate wrong answers

Option A is wrong because it uses `PASSWD: ALL` instead of `NOPASSWD: ALL`, which would still require the user to enter a password when running sudo commands, contrary to the requirement. Option C is wrong because it omits the `%` prefix before 'developers', which means the rule applies to a user named 'developers' rather than the group, so members of the group would not be affected. Option D is wrong because it lacks the `NOPASSWD` tag entirely, meaning sudo would prompt for a password by default, and it also uses `ALL` for the user specification without the `%` prefix, making it apply to a user named 'developers' instead of the group.

Practice this question →
2
MCQmedium

A file has been assigned an incorrect SELinux context, preventing a service from accessing it. Which command restores the default SELinux context for that file?

A.restorecon
B.chcon
C.fixfiles
D.setfiles
AnswerA

restorecon resets a file's SELinux context to the policy-defined default by consulting the file_contexts rules, typically with `restorecon -v /path/to/file`. It is the correct tool when a file's context has become incorrect because it determines the intended context from the policy rather than relying on a manually specified value, and it only changes files whose current context does not match the default.

Why this answer

The `restorecon` command is used to restore the default SELinux security context for a file or directory based on the system's policy store (the file_contexts database). When a file has an incorrect context that prevents a service from accessing it, `restorecon` resets the context to the correct default, allowing the service to access the resource as intended.

Exam trap

The trap here is that candidates often confuse `chcon` (which changes context manually) with `restorecon` (which restores the default from policy), leading them to pick `chcon` because they think they need to 'change' the context rather than 'restore' it to the correct default.

How to eliminate wrong answers

Option B (chcon) is wrong because `chcon` changes the SELinux context manually to a user-specified value, but it does not restore the default context from the policy database; it can introduce further misconfiguration if the wrong context is specified. Option C (fixfiles) is wrong because `fixfiles` is a script that corrects file contexts on entire filesystems or directories (e.g., after a policy update), not for a single file, and it is overkill for a targeted restoration. Option D (setfiles) is wrong because `setfiles` is a low-level tool used to initialize or verify file contexts on a filesystem, typically during system installation or policy reloads, and is not intended for routine single-file context restoration.

Practice this question →
3
Drag & Dropmedium

Order the steps to configure firewall rules to allow HTTP and HTTPS traffic using firewalld.

Drag or tap steps into the slots.

Steps
Order
1Step 1
2Step 2
3Step 3
4Step 4

Why this order

Firewalld rules are added with --permanent flag and then reloaded to take effect.

Practice this question →
4
MCQhard

An administrator needs to grant user 'dev' the ability to execute /usr/local/bin/deploy.sh as root without a password, but no other commands. Which sudoers entry accomplishes this?

A.dev ALL=(root) PASSWD: /usr/local/bin/deploy.sh
B.dev ALL=(root) NOPASSWD: /usr/local/bin/deploy.sh
C.dev ALL=(ALL) NOPASSWD: /usr/local/bin/deploy.sh
D.%dev ALL=(root) NOPASSWD: /usr/local/bin/deploy.sh
AnswerB

This rule correctly grants dev the ability to run /usr/local/bin/deploy.sh with root privileges without entering a password. The NOPASSWD tag overrides the default password requirement, and the fully qualified command path restricts execution to exactly that binary, preventing PATH-based substitution. The (root) runas specification ensures the command runs only as root, matching the requirement precisely.

Why this answer

The sudoers entry 'dev ALL=(root) NOPASSWD: /usr/local/bin/deploy.sh' grants user dev permission to run only that command as root without a password prompt. The NOPASSWD tag removes the password requirement, and specifying the single command restricts the privilege to exactly that binary.

Exam trap

EX200 often tests whether candidates confuse the PASSWD/NOPASSWD tags, the (root) vs (ALL) runas specification, and the '%' group prefix, any of which changes the meaning of the sudoers rule.

How to eliminate wrong answers

Option A is wrong because PASSWD: requires the user to enter their password, contradicting the no-password requirement. Option C is wrong because (ALL) allows running the command as any user, not just root, which is broader than needed. Option D is wrong because the '%' prefix denotes a group named dev, not the user dev, so it would not apply to the user account.

Practice this question →
5
MCQmedium

A system administrator is managing a Red Hat Enterprise Linux 9 web server running Apache httpd. The server hosts a custom application that stores its files in /var/www/custom. The administrator has set ownership to apache:apache and file permissions to 755. However, when users access the web application, they receive a 'Forbidden' error. The httpd service is running, and SELinux is in enforcing mode. The administrator checks the SELinux context of the /var/www/custom directory and sees 'unconfined_u:object_r:default_t:s0'. What should the administrator do to resolve the issue without disabling SELinux?

A.Use semanage fcontext to set the SELinux type to httpd_sys_content_t and run restorecon
B.Set SELinux to permissive mode
C.Use chcon to set the SELinux type to httpd_sys_content_t
D.Add the apache user to the group that owns the directory
AnswerA

The correct procedure is to use `semanage fcontext` to add a persistent rule to the SELinux policy database that maps the target directory and its contents to the `httpd_sys_content_t` type, then run `restorecon` to apply that context to the filesystem. Because the rule is stored in the file context database, it survives system reboots and filesystem relabels initiated by `restorecon -R` or `fixfiles`. This is the standard, supported method for serving static web content from non-default directories such as `/var/www/html` or custom paths, and it ensures the type enforcement allows `httpd_t` to read the files.

Why this answer

The directory /var/www/custom has the SELinux type default_t, which the httpd_t domain is not permitted to read. Apache runs confined by SELinux, so even with correct Unix ownership and permissions, the kernel blocks access and returns 'Forbidden'. The correct fix is to persistently label the directory with httpd_sys_content_t using semanage fcontext, then apply it with restorecon.

This preserves SELinux enforcement while granting httpd the access it needs.

Exam trap

The trap is confusing DAC (Unix permissions/ownership) with MAC (SELinux type enforcement) — candidates see 755 and apache:apache and assume permissions are fine, missing that SELinux is the actual blocker.

How to eliminate wrong answers

Option B is wrong because setting SELinux to permissive mode disables enforcement — it masks the symptom rather than fixing the labeling and violates the requirement to keep SELinux enforcing. Option C is wrong because chcon changes the context only for the current files and is not persistent; a future restorecon or relabel will revert it, and it doesn't update the policy database. Option D is wrong because Unix group membership is irrelevant when SELinux type enforcement is the blocking control — the denial is at the SELinux layer, not the DAC layer.

Practice this question →
6
Multi-Selecteasy

Which TWO commands can be used to display SELinux contexts of files? (Choose two.)

Select 2 answers
A.stat -c %C
B.chcon -l
C.id -Z
D.ls -Z
E.getenforce
AnswersA, D

The `stat -c %C` option is correct because the `stat` command's `%C` format specifier directly prints the SELinux security context of the specified file, such as `system_u:object_r:etc_t:s0`. This works on any filesystem object and is a precise, scriptable way to retrieve only the context string.

Why this answer

The `stat -c %C` command displays the SELinux security context of a file by using the `%C` format specifier, which outputs the security context string. The `ls -Z` command also shows SELinux contexts for files in a directory listing, with the `-Z` flag specifically requesting security context information. Both commands are standard tools for viewing SELinux labels on files.

Exam trap

The trap here is that candidates confuse commands that display process or system-wide SELinux status (like `id -Z` and `getenforce`) with those that display file contexts, leading them to select options that show user or enforcement mode instead of file labels.

Practice this question →
7
Matchingmedium

Match each networking term to its definition.

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

Concepts
Matches

Automatically assigns IP addresses to hosts

Resolves hostnames to IP addresses

Translates private IPs to public IPs

Combines multiple network interfaces for redundancy or throughput

Why these pairings

The correct matches are: IP address (unique identifier), Subnet mask (network/host division), Default gateway (router to external networks), DNS server (name resolution). Common confusions include swapping definitions between IP address and subnet mask, or between default gateway and DNS server.

Practice this question →
8
MCQhard

Refer to the exhibit. A web server is serving content from /var/www/html. SELinux is in enforcing mode. The web client reports 'Forbidden'. What is the most likely cause?

A.The file is owned by root, and Apache runs as apache user, so it cannot read.
B.The directory /var/www/html may have incorrect context or permissions preventing Apache from listing files.
C.The file permissions are 644, which restricts access.
D.The file has an incorrect SELinux context; it should be httpd_user_content_t.
AnswerB

The directory /var/www/html must be both readable and executable (searchable) for Apache to enter it and list or serve files; if it is 700 root:root or has a restrictive context, Apache is denied. SELinux also requires the httpd_sys_content_t type on this directory; if it was incorrectly relabeled, httpd cannot access it. This is the classic cause of a 403 'Forbidden' error even when the file itself is world-readable.

Why this answer

The most likely cause of a 'Forbidden' error when SELinux is enforcing is that the directory or file lacks the correct SELinux context (e.g., httpd_sys_content_t) or the permissions do not allow the Apache user (apache) to read or traverse the directory. Even if file permissions are 644, SELinux can block access if the context is wrong, such as being set to default_t or user_home_t. The error indicates Apache cannot access the content, which is typically resolved by restoring the correct context with restorecon or setting it with chcon.

Exam trap

A common pitfall in Red Hat RHCSA is assuming that file permissions alone cause 'Forbidden' errors, but with SELinux enforcing, incorrect context (e.g., httpd_user_content_t instead of httpd_sys_content_t) is the primary cause. Candidates must remember that SELinux overrides DAC permissions.

How to eliminate wrong answers

Option A is wrong because file ownership by root does not inherently prevent Apache from reading it; Apache runs as the apache user, and as long as the file has world-readable permissions (e.g., 644) and the directory is traversable, the apache user can read it. Option C is wrong because file permissions of 644 (owner read/write, group read, others read) are standard for web content and do not restrict access; they allow the apache user (as 'others') to read the file. Option D is wrong because the correct SELinux context for web content served by Apache is httpd_sys_content_t, not httpd_user_content_t, which is used for user-specific content (e.g., in public_html directories).

Practice this question →
9
MCQhard

A company runs a web application on a Red Hat Enterprise Linux 8 server. The application is served by Apache HTTPD, and it requires read/write access to a custom directory /var/www/app_data. The SELinux context for the directory is set to httpd_sys_rw_content_t. Apache runs in enforcing mode. Recently, a new feature was added that requires Apache to connect to a database on the same server via a Unix socket. The database serves on /var/run/mysqld/mysqld.sock. After the feature deployment, the web application fails to connect to the database. The error logs show permission denied on the socket file. The socket file has permissions 660 and is owned by mysql:mysql. SELinux audit logs show AVC denials for httpd_t trying to connect to mysqld_var_run_t. Which of the following solutions should the administrator implement to allow Apache to read the database socket while maintaining security?

A.Change the SELinux context of the socket file to httpd_sys_rw_content_t using chcon.
B.Enable the SELinux boolean httpd_can_network_connect_db using setsebool -P httpd_can_network_connect_db on.
C.Enable the SELinux boolean httpd_can_connect_db using setsebool -P httpd_can_connect_db on.
D.Use semanage to add a context mapping for the socket file to httpd_var_run_t and set the httpd to permissive mode.
AnswerC

This is the correct boolean because httpd_can_connect_db allows the httpd daemon to connect to a database through local Unix socket files, such as /var/run/mysql/mysql.sock, while leaving network controls unchanged. Using setsebool with -P is essential because it writes the change to the persistent policy so the permission survives a reboot, matching the intended production configuration. The boolean directly addresses the SELinux denial shown in the audit log instead of masking the problem.

Why this answer

The correct solution is to enable the SELinux boolean `httpd_can_connect_db` using `setsebull -P httpd_can_connect_db on`. This boolean specifically allows the `httpd_t` domain to connect to MySQL/MariaDB databases via Unix sockets, which is exactly the scenario described: Apache needs to connect to a local database socket with context `mysqld_var_run_t`. The AVC denial confirms that the default policy blocks this socket connection, and enabling this boolean grants the necessary permission without weakening other security controls.

Exam trap

The trap here is that candidates often confuse `httpd_can_connect_db` (for local database connections via Unix sockets) with `httpd_can_network_connect_db` (for remote TCP connections), leading them to choose the wrong boolean when the scenario involves a local socket file.

How to eliminate wrong answers

Option A is wrong because changing the SELinux context of the socket file to `httpd_sys_rw_content_t` would mislabel a socket file (which should remain `mysqld_var_run_t`) and could break the database daemon's ability to use it; moreover, the issue is about connecting to the socket, not file read/write access. Option B is wrong because `httpd_can_network_connect_db` controls TCP network connections to remote databases, not Unix socket connections to a local database. Option D is wrong because adding a context mapping to `httpd_var_run_t` does not address the socket connection permission (the socket is already labeled `mysqld_var_run_t`), and setting httpd to permissive mode would disable SELinux enforcement entirely, which is not a secure or recommended solution.

Practice this question →
10
MCQmedium

After configuring sudo, a user reports: 'sudo: unable to open /etc/sudoers: Permission denied'. The admin checks the file permissions and sees '-rw-r-----' owned by root:root. What is the most likely cause?

A.The file is owned by the wrong user.
B.The sudo binary is missing the setuid bit.
C.The file permissions are too permissive (0640 instead of 0440).
D.SELinux is blocking access.
AnswerC

Sudo requires /etc/sudoers to be owned by root:root and have mode 0440 (read-only for owner and group). A mode of 0640 grants write permission to root, which sudo considers unsafe because it suggests the file was modified manually outside visudo's validation; sudo then refuses to open it for policy parsing and reports an error. Changing the mode back to 0440 with `chmod 0440 /etc/sudoers` resolves the issue. The message may explicitly say 'sudo: /etc/sudoers is mode 0640, should be 0440'.

Why this answer

The sudoers file requires strict permissions of 0440 (owner read, group read) to be considered secure by sudo. The current permissions of 0640 (owner read/write, group read) are too permissive, as they grant write access to the owner (root), which violates sudo's security model. When sudo detects that /etc/sudoers has permissions other than 0440, it refuses to open the file and reports 'Permission denied' to prevent potential tampering.

Exam trap

The trap here is that candidates assume 'Permission denied' always means the user lacks read access, but sudo specifically rejects files with write permissions for root to enforce its security policy, not because the user cannot read the file.

How to eliminate wrong answers

Option A is wrong because the file is owned by root:root, which is the correct ownership for /etc/sudoers; the issue is with permissions, not ownership. Option B is wrong because the sudo binary's setuid bit is unrelated to this error; the error message specifically references /etc/sudoers, not the sudo executable, and a missing setuid bit would cause a different error like 'sudo: must be setuid root'. Option D is wrong because SELinux would produce a different error message (e.g., 'Permission denied' with an AVC denial logged in audit.log) and the file permissions are the direct cause here; SELinux is not indicated by the given permission string.

Practice this question →
11
MCQmedium

A web server is running in enforcing mode with SELinux, but Apache cannot read content in a custom directory /web. The directory has been labeled correctly with httpd_sys_content_t. However, access is still denied. What is the most likely cause?

A.SELinux boolean httpd_enable_homedirs is off.
B.The httpd process is running in permissive mode.
C.The directory has incorrect permissions of 700.
D.The files are labeled with default_t.
AnswerC

A directory mode of 700 grants full permissions only to its owner, which is typically root, while the httpd process runs as the non-owner user apache (or www-data). That places the daemon in the 'other' permission class, which has no read or execute rights, so even an otherwise correct SELinux context and enabling booleans won't help because DAC checks are evaluated first. The fix is to use a mode like 755, or 750 with proper group ownership, so the web server can traverse and read the content.

Why this answer

Even though the SELinux context is correctly set to httpd_sys_content_t, the directory has permissions of 700 (rwx------). This means only the owner (typically root) can read, write, or execute the directory. The Apache httpd process runs as the 'apache' or 'httpd' user, which is not the owner, so it is denied read access.

SELinux enforces its own policy, but DAC (Discretionary Access Control) permissions are checked first; if DAC denies access, SELinux never gets to evaluate the context match.

Exam trap

The trap here is that candidates focus solely on SELinux context and booleans, forgetting that DAC permissions are evaluated first and can block access even when SELinux labels are perfectly correct.

How to eliminate wrong answers

Option A is wrong because the httpd_enable_homedirs boolean controls whether httpd can access user home directories (e.g., /home/*/public_html), not a custom directory like /web. Option B is wrong because the question states the system is running in enforcing mode, and if httpd were permissive, SELinux would log denials but still allow access, so access would not be denied. Option D is wrong because the question explicitly says the directory is labeled correctly with httpd_sys_content_t, not default_t; if files were labeled default_t, SELinux would deny access with an AVC denial, but the problem states the label is correct, so the issue must be DAC permissions.

Practice this question →
12
MCQeasy

Which file contains the hashed passwords for local user accounts?

A./etc/security/passwd
B./etc/passwd
C./etc/shadow
D./etc/gshadow
AnswerC

The /etc/shadow file is the correct location for hashed passwords of local users on RHEL. It is readable only by root (and members of the shadow group) and stores each user's password hash, along with password aging information such as last change, minimum and maximum days, and expiration warning. The 'x' in /etc/passwd references this file for the actual hash.

Why this answer

The /etc/shadow file stores hashed passwords for local user accounts, along with password aging and expiration information. It is readable only by root (or privileged processes) to prevent unauthorized access to password hashes, unlike /etc/passwd which is world-readable.

Exam trap

Red Hat often tests the distinction between /etc/passwd (world-readable, stores user info but not hashes) and /etc/shadow (restricted, stores hashes), exploiting the common misconception that passwords are still in /etc/passwd.

How to eliminate wrong answers

Option A is wrong because /etc/security/passwd does not exist in standard Linux; it may be confused with /etc/security/opasswd (used by pam_pwhistory) or /etc/security/limits.conf, but none store hashed passwords. Option B is wrong because /etc/passwd historically stored password hashes but now uses an 'x' placeholder; it is world-readable and would expose hashes, so modern systems moved hashes to /etc/shadow. Option D is wrong because /etc/gshadow stores hashed passwords for group accounts (for group administrators), not for local user accounts.

Practice this question →
13
MCQmedium

A user reports that the Apache web server cannot serve the file /var/www/html/index.html on a RHEL 9 system when SELinux is in enforcing mode. Given the exhibit output, what is the most likely cause?

A.The firewalld service is blocking HTTP traffic on port 80.
B.The file is owned by root and Apache cannot read it.
C.The file permissions do not allow the apache user to read the file.
D.The SELinux context of the file is incorrect for web serving.
AnswerD

The SELinux context user_home_t is intended for files in user home directories, and the httpd_t domain is not allowed to read files with that type by default. Even with correct Unix permissions, Apache will receive a permission denial from SELinux because the file is not labeled with a type such as httpd_sys_content_t or public_content_t. This is a classic SELinux mislabeling problem, easily verified with ls -Z and fixed with restorecon or semanage fcontext.

Why this answer

The default SELinux context for files served by Apache in /var/www/html is `httpd_sys_content_t`. If the file has a different context (e.g., `unconfined_u:object_r:admin_home_t:s0`), SELinux will deny Apache read access even if standard Linux permissions are permissive. The `ls -Z` output would reveal the mismatch, and `restorecon -v /var/www/html/index.html` would fix it.

Exam trap

The trap here is that candidates often focus on file permissions or ownership (options B and C) because they are familiar from non-SELinux systems, but the question explicitly states SELinux is in enforcing mode, which overrides DAC permissions when a type mismatch exists.

How to eliminate wrong answers

Option A is wrong because firewalld blocking HTTP traffic would prevent remote clients from reaching the server, but the user reports the server cannot serve the file locally, and SELinux enforcing mode is the stated condition. Option B is wrong because file ownership by root does not inherently prevent Apache from reading it; Apache runs as the apache user and can read files owned by root if permissions allow (e.g., 644). Option C is wrong because the exhibit output (not shown here but implied) would show standard permissions like 644, which grant read access to the apache user; the issue is SELinux, not DAC permissions.

Practice this question →
14
MCQhard

A system administrator wants to allow user 'jdoe' to execute any command as root via sudo without being prompted for a password, but only from the host 'client1.example.com'. Which sudoers rule achieves this?

A.jdoe client1.example.com=(root) NOPASSWD: ALL
B.jdoe client1.example.com=(root) ALL
C.jdoe ALL=(root) NOPASSWD: ALL
D.jdoe ALL=(root) ALL
AnswerA

This is the correct rule. It confines the privilege to client1.example.com, specifies that commands run as root via (root), and uses the NOPASSWD tag so jdoe is not prompted for a password. The syntax exactly matches the sudoers grammar: user host_list = (runas) TAG: command_list, so it satisfies the requirement without unnecessary wildcards.

Why this answer

The sudoers rule 'jdoe client1.example.com=(root) NOPASSWD: ALL' specifies the user 'jdoe', the host 'client1.example.com' as the source host from which the command is run, the target user '(root)', the NOPASSWD tag to skip password authentication, and the command 'ALL' to allow any command. This matches the requirement exactly: passwordless root access restricted to a specific client host.

Exam trap

The trap here is that candidates often forget the NOPASSWD tag when passwordless access is required, or they use 'ALL' for the host list instead of specifying the exact hostname, assuming 'ALL' means 'all commands' rather than 'all hosts'.

How to eliminate wrong answers

Option B is wrong because it omits the NOPASSWD tag, so 'jdoe' would still be prompted for a password when running sudo commands from client1.example.com. Option C is wrong because it uses 'ALL' as the host specification, allowing the rule to apply from any host, not just client1.example.com. Option D is wrong because it both omits the NOPASSWD tag and uses 'ALL' for the host, allowing password-protected sudo from any host.

Practice this question →
15
Multi-Selectmedium

Which THREE commands are used to manage SELinux file security contexts? (Select exactly three.)

Select 3 answers
A.setenforce
B.chcon
C.selinux
D.semanage fcontext
E.restorecon
AnswersB, D, E

chcon is the direct, immediate way to change the SELinux context of an existing file or directory by explicitly specifying a context, such as 'chcon -t httpd_sys_content_t /var/www/html/index.html'. It writes the new security.selinux extended attribute value on the file itself, which makes the change take effect right away without a policy reload. However, chcon does not update the persistent SELinux policy mappings, so the label can be lost if restorecon is later run or the filesystem is relabeled.

Why this answer

B (chcon) is correct because it changes the SELinux security context of a file or directory immediately, without reference to the SELinux policy database. This is useful for temporary or one-off changes, but the context may be overwritten by restorecon or a file system relabel.

Exam trap

Red Hat frequently tests the distinction between commands that modify the running SELinux file context (chcon), commands that modify the policy defaults (semanage fcontext), and commands that restore contexts from policy (restorecon). Candidates often confuse 'setenforce' (which controls SELinux enforcing/permissive mode) with context management commands.

Practice this question →
16
MCQeasy

A security policy requires that all files in /home have the default SELinux context for user home directories. Which command recursively restores the default context?

A.restorecon -Rv /home
B.semanage fcontext -a -t user_home_t /home
C.chcon -Rv default_t /home
D.setfiles -Rv /home
AnswerA

restorecon -Rv /home is correct because it rereads the active SELinux file context policy (from /etc/selinux/*/contexts/files) and applies the proper default type to every file and directory under /home. The -R flag makes it recursive, and -v shows exactly what is being relabeled, so this command directly satisfies the security policy requirement without altering policy definitions.

Why this answer

`restorecon -Rv /home` recursively resets the SELinux context of all files under `/home` to the default type defined in the SELinux policy for user home directories (typically `user_home_t`). The `-R` flag enables recursion, and `-v` provides verbose output, ensuring compliance with the security policy requirement.

Exam trap

The trap here is that candidates often confuse `restorecon` with `chcon` or `semanage fcontext`, mistakenly thinking that adding a rule with `semanage` or manually setting a context with `chcon` is sufficient, when in fact only `restorecon` (or `setfiles`) applies the policy-defined default context to existing files.

How to eliminate wrong answers

Option B is wrong because `semanage fcontext -a -t user_home_t /home` adds a new default context rule to the SELinux policy database, but it does not immediately apply the context to existing files; a subsequent `restorecon` or `setfiles` is needed to actually relabel the files. Option C is wrong because `chcon -Rv default_t /home` manually sets the context to `default_t`, which is not the correct default type for user home directories (the correct type is `user_home_t`), and `chcon` does not use the policy database, so changes are not persistent after a full relabel. Option D is wrong because `setfiles -Rv /home` is used to relabel files based on a file context specification file (usually `/etc/selinux/targeted/contexts/files/file_contexts`), but it requires root and is typically used for initial labeling or after policy changes, not for simply restoring the default context as `restorecon` does; `setfiles` is more complex and not the standard command for this routine task.

Practice this question →
17
MCQmedium

A server's firewall is managed by firewalld. The admin adds a rule to allow HTTPS traffic to the public zone, but clients still cannot connect. What is the most likely cause?

A.The rule was added with --permanent but firewall-cmd --reload was not run.
B.The rule must be added as a rich rule, not a simple service.
C.The default zone is not set to public.
D.firewalld is just a wrapper for iptables, so iptables rules must be cleared.
AnswerA

Rules added with `--permanent` are written to the on-disk configuration but not loaded into the running firewalld instance. Without `firewall-cmd --reload`, the active ruleset never includes the HTTPS allowance, so clients remain blocked despite the saved rule.

Why this answer

When a rule is added with the `--permanent` flag in firewalld, it is written to the configuration files but not applied to the runtime firewall. Until `firewall-cmd --reload` is executed, the runtime configuration remains unchanged, so the new rule allowing HTTPS traffic is not active. Clients cannot connect because the firewall is still blocking HTTPS based on the old runtime rules.

Exam trap

The trap here is that candidates often assume adding a rule with `--permanent` immediately takes effect, forgetting that firewalld requires a reload or the `--runtime-to-permanent` approach to synchronize changes.

How to eliminate wrong answers

Option B is wrong because HTTPS traffic can be added as a simple service using `firewall-cmd --add-service=https`; rich rules are not required for standard services like HTTPS. Option C is wrong because the rule was explicitly added to the public zone, so the default zone setting is irrelevant; the rule applies to the public zone regardless of whether it is the default. Option D is wrong because firewalld manages its own runtime and permanent configurations independently of iptables; clearing iptables rules would disrupt firewalld's state and is not necessary or recommended.

Practice this question →
18
MCQmedium

An administrator wants newly created files to be readable and writable only by the owner, and readable by group and others. Which umask value should be set?

A.027
B.022
C.002
D.077
AnswerB

With umask 022, the mask removes the write bit from group and others (2 = write) from the base 666, resulting in files with 644. That gives the owner read/write and both the group and others read permission, so every user can read the file. This is the standard, desired value for making newly created files world-readable.

Why this answer

The umask value 022 removes write permissions for group and others, while leaving read and execute permissions intact. Since the default base permissions for files are 666 (rw-rw-rw-), applying umask 022 results in 644 (rw-r--r--), which gives the owner read/write access and group/others read-only access — exactly matching the requirement.

Exam trap

A common pitfall is confusing the umask as the permissions to grant rather than to subtract. In Red Hat Enterprise Linux, the default file creation mask is 022, which results in files with 644 permissions (rw-r--r--). Candidates often incorrectly select 002 (which would allow group write) or 077 (which would remove all group/other permissions).

How to eliminate wrong answers

Option A (027) is wrong because it removes read and execute permissions from others (resulting in 640 for files), making files unreadable by others, which violates the requirement. Option C (002) is wrong because it only removes write permissions from others (resulting in 664), leaving group with write access, which is not allowed. Option D (077) is wrong because it removes all permissions for group and others (resulting in 600), making files completely inaccessible to anyone except the owner.

Practice this question →
19
Multi-Selectmedium

Which three statements about firewalld zones are correct? (Choose three.)

Select 3 answers
A.The default zone can be changed using firewall-cmd.
B.A network interface can be assigned to multiple zones simultaneously.
C.The 'public' zone is more restrictive than the 'trusted' zone.
D.Rich rules can specify source and destination addresses.
E.Zones can have a default target of only 'DROP' or 'ACCEPT'.
AnswersA, C, D

The default zone can be changed with `firewall-cmd --set-default-zone=<zone>`. This command updates the default zone in the firewalld configuration, so the change persists across reboots. The default zone applies only to interfaces or source addresses that have not been explicitly bound to another zone.

Why this answer

The default zone in firewalld can be changed using the 'firewall-cmd --set-default-zone=<zone>' command. This command updates the runtime and permanent configuration, ensuring that all new network interfaces are automatically assigned to the specified zone unless explicitly overridden.

Exam trap

The trap here is that candidates often assume a network interface can belong to multiple zones simultaneously (like in some other firewall systems), but firewalld enforces a strict one-interface-per-zone binding, and they may also forget that zones support 'REJECT' and 'default' targets, not just 'DROP' and 'ACCEPT'.

Practice this question →
20
MCQhard

Refer to the exhibit. A CGI script located at /var/www/cgi-bin/test.cgi fails to execute. What is the most likely cause?

A.The script is in the wrong directory.
B.The SELinux context should be httpd_sys_script_exec_t.
C.The script is not marked as executable.
D.The file permissions are incorrect.
AnswerB

SELinux prevents httpd from executing scripts unless the file has the httpd_sys_script_exec_t type, which allows a transition into the httpd_sys_script_t domain when the script runs. If the script retains a generic context such as httpd_sys_content_t or user_home_t, httpd is blocked even when permissions and location are correct, producing a 500 error. Running `restorecon -R /var/www/cgi-bin` or `chcon -t httpd_sys_script_exec_t /var/www/cgi-bin/script.cgi` is the correct fix, not changing permissions.

Why this answer

SELinux contexts control which processes can access files and directories. The CGI script at /var/www/cgi-bin/test.cgi requires the httpd_sys_script_exec_t context to allow the Apache HTTP server (httpd) to execute it. Without this context, SELinux will deny execution even if file permissions and ownership are correct.

Exam trap

The pitfall in this question is that examinees often focus on file permissions or script location, overlooking that SELinux contexts (specifically httpd_sys_script_exec_t) are required for CGI execution in Red Hat systems.

How to eliminate wrong answers

Option A is wrong because /var/www/cgi-bin/ is the default directory for CGI scripts on Red Hat-based systems, so the script is in the correct location. Option C is wrong because the question does not indicate that the script lacks execute permissions; SELinux can block execution even when the file is marked executable. Option D is wrong because file permissions (e.g., 755) may be correct, but SELinux enforces its own policy that overrides standard permissions.

Practice this question →
21
Multi-Selecteasy

Which TWO statements about the /etc/shadow file are true? (Select exactly two.)

Select 2 answers
A.Contains hashed passwords for local users.
B.Contains the user's UID.
C.Is used to store encrypted group passwords.
D.Is readable by all users.
E.Contains password aging information such as minimum and maximum days.
AnswersA, E

This file is the central repository for each local user's password hash, stored as a salted string using an algorithm identifier such as $6$ for SHA-512 or $y$ for yescrypt. Because /etc/passwd must be world-readable for tools like ls -l to map UIDs, the encrypted password field there was moved out to this protected file. The presence of a password hash here is what makes local login authentication possible; an x field in /etc/passwd simply indicates the hash is in /etc/shadow.

Why this answer

The /etc/shadow file stores hashed user passwords using algorithms like SHA-512 or yescrypt, as defined by the pam_unix module. It also contains password aging fields (e.g., minimum days, maximum days, warning period) that enforce password expiration policies. These two functions make options A and E correct.

Exam trap

A common pitfall on Red Hat exams is confusing /etc/passwd (which contains UIDs and is world-readable) with /etc/shadow (which contains hashed passwords and is root-only). Many candidates incorrectly think /etc/shadow contains UIDs or is readable by all users.

Practice this question →
22
MCQeasy

A junior admin needs to ensure that the 'apache' user (UID 48) cannot log in via SSH or console. Which command achieves this?

A.usermod -s /sbin/nologin apache
B.passwd -l apache
C.chage -l apache
D.usermod -e 1 apache
AnswerA

Setting the login shell to /sbin/nologin blocks interactive SSH and console sessions for apache while leaving the account valid for service processes. This satisfies the requirement to deny login without deleting the UID 48 account.

Why this answer

Setting the user's login shell to `/sbin/nologin` prevents the user from obtaining an interactive shell via SSH or console login. When the user attempts to log in, the system executes `/sbin/nologin`, which prints a polite message and exits immediately, effectively denying shell access while leaving other services (e.g., Apache) functional.

Exam trap

The trap here is that candidates often confuse password locking (`passwd -l`) with shell restriction, not realizing that SSH key authentication or console login via `su` bypasses password locks, while changing the shell to `/sbin/nologin` blocks all interactive login methods.

How to eliminate wrong answers

Option B is wrong because `passwd -l apache` locks the user's password, preventing password-based authentication, but it does not prevent SSH key-based authentication or console login via other methods (e.g., su, sudo). Option C is wrong because `chage -l apache` lists the user's password aging information; it does not modify any setting that would block login. Option D is wrong because `usermod -e 1 apache` sets the account expiration date to January 1, 1970 (epoch), which disables the account entirely, but this is an overly aggressive approach that also prevents the Apache service from running as that user, whereas the requirement is only to prevent interactive login.

Practice this question →
23
MCQeasy

A junior administrator is tasked with setting up SELinux contexts on a Red Hat Enterprise Linux 9 server to allow Apache HTTPD to read and write to a custom directory /var/www/customcontent. The directory already exists and contains several files. The administrator has confirmed that the httpd service is running and SELinux is in enforcing mode. After changing the context to httpd_sys_content_t using chcon, the web server can read files but cannot write to the directory. The administrator needs to fix this without disabling SELinux or changing the mode to permissive. Which of the following is the correct next step?

A.Set the SELinux boolean httpd_enable_homedirs to on using setsebool.
B.Run restorecon -R -v /var/www/customcontent after setting the default context with semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/customcontent(/.*)?'
C.Change the context to httpd_sys_content_t using chcon -R -t httpd_sys_content_t /var/www/customcontent
D.Run semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/customcontent(/.*)?' without running restorecon.
AnswerB

The correct approach uses semanage fcontext to add a persistent default rule that maps /var/www/customcontent and its contents to the httpd_sys_rw_content_t type. Running restorecon -R -v then applies that rule immediately, relabeling existing files to match the policy. The -R flag ensures recursive relabeling and -v shows which files are being relabeled. This combination establishes the writable SELinux type persistently, so future files created in that directory inherit the correct context.

Why this answer

The directory already has the httpd_sys_content_t type, which allows reading but not writing. To enable write access, the correct type is httpd_sys_rw_content_t. Option B correctly uses semanage fcontext to set the default context to this type and then runs restorecon to apply it persistently, ensuring Apache can both read and write.

Exam trap

The trap here is that candidates may think setting the context with chcon or semanage alone is sufficient, but they overlook the need to run restorecon to apply the new default context to existing files, or they confuse httpd_sys_content_t (read-only) with httpd_sys_rw_content_t (read-write).

How to eliminate wrong answers

Option A is wrong because the httpd_enable_homedirs boolean controls access to user home directories, not to /var/www/customcontent, and does not grant write permissions to custom content directories. Option C is wrong because it sets the context to httpd_sys_content_t, which is read-only; the administrator already confirmed this type allows reading but not writing, so repeating the same action does not fix the write issue. Option D is wrong because running semanage fcontext without restorecon only sets the default context in the policy but does not apply it to the existing files and directories; the files retain their current context, so write access is not granted.

Practice this question →
24
MCQeasy

To allow a user to run a specific program with root privileges without providing the root password, which configuration file should be modified?

A./etc/passwd
B./etc/security/limits.conf
C./etc/sudoers
D./etc/sysconfig/sshd
AnswerC

The /etc/sudoers file is the central configuration for the sudo utility, which permits designated users to execute commands as root or another user. Rules use a syntax like "user host=(runas) commands" and can be tailored to allow a specific binary without granting a general root shell. This file must always be edited with the visudo command to prevent syntax errors that could break sudo, and it supports including drop-in files from /etc/sudoers.d.

Why this answer

The /etc/sudoers file is the correct configuration file to modify because it controls the sudo command, which allows specified users to execute programs with root privileges. By adding an entry such as `username ALL=(ALL) NOPASSWD: /path/to/program`, the user can run that specific program without being prompted for a password. This is the standard mechanism in Red Hat Enterprise Linux for granting passwordless privilege escalation.

Exam trap

Candidates often mistakenly think that modifying /etc/passwd or /etc/security/limits.conf can grant root privileges, but only /etc/sudoers controls passwordless sudo access for specific programs.

How to eliminate wrong answers

Option A is wrong because /etc/passwd stores user account information (UID, GID, home directory, shell) and does not control privilege escalation or passwordless execution. Option B is wrong because /etc/security/limits.conf sets resource limits (e.g., file size, number of processes) for users and does not manage sudo or root access. Option D is wrong because /etc/sysconfig/sshd contains configuration for the SSH daemon (e.g., port, protocol versions) and has no role in granting root privileges to run programs.

Practice this question →
25
Multi-Selecteasy

Which two statements about SELinux modes are correct? (Choose two.)

Select 2 answers
A.Permissive mode denies actions but does not log.
B.Permissive mode logs violations but does not deny actions.
C.Enforcing mode only logs violations but does not deny.
D.Enforcing mode logs violations and denies actions.
E.Disabled mode completely disables SELinux without requiring a reboot.
AnswersB, D

In permissive mode, SELinux policy is not enforced, so processes can perform operations that would normally be prohibited; those violations are recorded as AVC denial messages in the audit log. This behavior is intentional: it allows administrators to observe how SELinux would react without breaking functionality. Therefore, the statement correctly identifies both actions of permissive mode: logging and not denying.

Why this answer

SELinux permissive mode allows all actions but logs any violations that would have been denied in enforcing mode. Option D is correct because enforcing mode both logs violations and denies actions that violate the SELinux policy, providing full security enforcement.

Exam trap

The trap here is that candidates often confuse permissive mode with logging-only behavior, forgetting that permissive mode does not deny actions, while enforcing mode both logs and denies, and that disabling SELinux requires a reboot, not just a runtime change.

Practice this question →
26
MCQmedium

You are the system administrator for a small company. A developer, Alice, needs to restart the web server (httpd.service) on server 'web1.example.com' without being prompted for a password. She should also be able to run any command as root on that server, but only from the server itself (not remotely). Currently, Alice can SSH into the server using her SSH key, but when she runs 'sudo systemctl restart httpd', she is prompted for her password. You have verified that Alice is in the 'wheel' group. The sudoers file currently has the line '%wheel ALL=(ALL) ALL'. You want to modify sudoers to satisfy the requirement with minimal privilege. Which action should you take?

A.Add 'alice web1.example.com=(root) NOPASSWD: ALL' to /etc/sudoers.d/alice.
B.Add 'alice web1.example.com=(root) NOPASSWD: /usr/bin/systemctl restart httpd' to /etc/sudoers.d/alice.
C.Add 'alice web1.example.com=(root) /usr/bin/systemctl restart httpd' to /etc/sudoers.d/alice.
D.Change '%wheel ALL=(ALL) ALL' to '%wheel ALL=(ALL) NOPASSWD: ALL' in /etc/sudoers.
AnswerB

This entry precisely scopes alice's sudo privilege to the exact systemctl invocation required to restart httpd, with NOPASSWD so the service can be restarted without interactive password entry. The command path /usr/bin/systemctl is verified as a literal command; arguments are permitted as given. This meets the stated requirement of minimal access while allowing the action.

Why this answer

It grants Alice passwordless sudo access specifically to the command `/usr/bin/systemctl restart httpd` on the host `web1.example.com` as root, meeting the requirement with minimal privilege. The `NOPASSWD:` tag is essential to bypass the password prompt, and the host restriction ensures the rule applies only when Alice is on that server.

Exam trap

The trap here is that candidates often forget the `NOPASSWD:` tag when the requirement explicitly says 'without being prompted for a password', leading them to choose Option C, which grants the command but still requires authentication.

How to eliminate wrong answers

Option A is wrong because it grants Alice passwordless sudo access to ALL commands as root on web1.example.com, which exceeds the minimal privilege requirement (she only needs to restart httpd). Option C is wrong because it lacks the `NOPASSWD:` tag, so Alice would still be prompted for a password when running the command. Option D is wrong because it modifies the wheel group rule to allow all wheel members passwordless sudo for all commands, which is excessive and violates the principle of least privilege.

Practice this question →
27
MCQmedium

Which command checks if a user's password has expired and forces a password change at next login?

A.chage -d 0 username
B.passwd -f username
C.usermod -L username
D.passwd -l username
AnswerA

chage -d 0 sets the 'date of last password change' field to 0, representing the epoch date (1970-01-01). When the user attempts to log in, the system compares the current date to this zero epoch and determines that the password has already exceeded its maximum age, forcing an immediate password change. This command is the standard method to expire a user's existing password without locking the account or requiring manual intervention.

Why this answer

The `chage -d 0 username` command sets the last password change date to the epoch (January 1, 1970), which forces the password to be considered expired immediately. On the next login, the system will prompt the user to change their password before granting access, as defined by the PAM (Pluggable Authentication Modules) password aging policy.

Exam trap

The trick is to distinguish between password expiration (chage -d 0) and account locking (passwd -l, usermod -L). Many candidates incorrectly choose an account lock command because they think it forces a password change at next login, but locking prevents login entirely until unlocked.

How to eliminate wrong answers

Option B is wrong because `passwd -f username` forces a password change on the next login only if the password has already expired; it does not expire the password itself. Option C is wrong because `usermod -L username` locks the user account by placing an exclamation mark in the shadow password file, preventing login entirely rather than forcing a password change. Option D is wrong because `passwd -l username` locks the account by adding a '!' prefix to the encrypted password in /etc/shadow, which also denies login access.

Practice this question →
28
Multi-Selectmedium

A system administrator needs to configure a firewall using firewalld to allow incoming HTTPS traffic and deny incoming SSH traffic from a specific source IP 192.168.1.100. Which two commands should be run? (Choose two.)

Select 2 answers
A.firewall-cmd --runtime-to-permanent
B.firewall-cmd --add-rich-rule='rule family=ipv4 source address=192.168.1.100 service name=ssh reject' --permanent
C.firewall-cmd --add-service=https --permanent
D.firewall-cmd --add-service=http --permanent
E.firewall-cmd --add-rich-rule='rule family=ipv4 source address=192.168.1.100 service name=ssh drop' --permanent
AnswersC, E

This command correctly adds the predefined https service to the permanent zone configuration, allowing inbound TCP traffic on port 443. Using --permanent ensures the rule survives reboots, and the https service entry in firewalld maps cleanly to the standard HTTPS port. Since the requirement is to permit secure web traffic, adding the https service is the appropriate, concise way to achieve that with firewalld.

Why this answer

`firewall-cmd --add-service=https --permanent` adds the HTTPS service (TCP port 443) to the permanent firewall configuration, which is required to allow incoming HTTPS traffic persistently across reboots. The `--permanent` flag ensures the rule survives a reload or restart, and the `--add-service` option uses predefined service definitions from firewalld to simplify rule creation.

Exam trap

The trap here is that candidates often confuse `reject` with `drop` in rich rules, or they mistakenly add the HTTP service instead of HTTPS, failing to distinguish between the two services and their respective ports.

Practice this question →
29
MCQhard

A server uses firewalld with the default zone set to 'drop'. SSH is allowed only for the 192.168.1.0/24 subnet via a rich rule in the 'internal' zone. After a reboot, SSH connections from that subnet are refused. What is the most likely cause?

A.The subnet 192.168.1.0/24 is not a valid source for rich rules.
B.The network interface is not assigned to the 'internal' zone.
C.The rich rule was not made permanent.
D.The SSH service is not enabled in the default zone.
AnswerB

This is the root cause. firewalld applies zones to traffic based on the ingress interface or source address; if the interface is not permanently assigned to the `internal` zone, it remains in the default zone, which here is `drop` and thus silently discards all incoming packets. The rich rule lives in `internal`, but without the interface assigned there, the rule never sees the SSH traffic. You must run `firewall-cmd --permanent --zone=internal --change-interface=eth0` (then `--reload`) to make the assignment persistent across reboots.

Why this answer

After a reboot, firewalld applies the default zone to all interfaces not explicitly assigned to another zone. Since the rich rule allowing SSH from 192.168.1.0/24 is defined in the 'internal' zone, the network interface must be assigned to that zone for the rule to take effect. If the interface is not assigned (e.g., it remains in the default 'drop' zone), all incoming traffic, including SSH from the allowed subnet, is dropped by default.

Exam trap

The trap here is that candidates assume rich rules are globally evaluated regardless of zone assignment, but firewalld enforces rules only within the zone bound to the interface, so a rule in the wrong zone is effectively invisible to traffic on that interface.

How to eliminate wrong answers

Option A is wrong because 192.168.1.0/24 is a valid source address in firewalld rich rules; rich rules support CIDR notation for source filtering. Option C is wrong because if the rich rule were not made permanent, it would be lost after reboot, but the question states the rule exists (it was configured), and the issue is that it is not being applied—the interface assignment is the missing link. Option D is wrong because the default zone is 'drop', which by design does not allow any services; the SSH service is intentionally allowed only via a rich rule in the 'internal' zone, not in the default zone, so this is expected behavior and not the cause of the refusal.

Practice this question →
30
MCQmedium

Refer to the exhibit. What is the primary security concern with this sudo configuration?

A.The NOPASSWD option eliminates the need for a password.
B.The entry uses (ALL) instead of (root), allowing jane to run as any user.
C.The less command allows executing shell commands via !, enabling privilege escalation.
D.The command /usr/bin/less can be used to read any file.
AnswerC

The less pager has a built-in feature that allows users to execute shell commands by typing ! followed by a command. When less is run with sudo as root, that shell is spawned as root, effectively giving jane a root shell. This is a well-known sudo escape vector listed in GTFOBins, and it is the primary reason this sudoers entry is dangerous, far more than the NOPASSWD or (ALL) attributes.

Why this answer

The `less` command, when executed with sudo, allows the user to escape to a shell by typing `!command` from within the pager. This bypasses the intended restriction of only running `/usr/bin/less` as root, enabling arbitrary command execution with elevated privileges. The NOPASSWD directive further compounds the risk by removing the password prompt, making the escalation trivial.

Exam trap

The trap here is that candidates focus on the NOPASSWD or the (ALL) syntax, missing the fact that the command itself (`less`) has built-in shell escape capabilities that can be exploited for privilege escalation.

How to eliminate wrong answers

Option A is wrong because while NOPASSWD eliminates the password requirement, it is not the primary security concern; the real issue is the ability to escape to a shell via `less`. Option B is wrong because using `(ALL)` allows jane to run commands as any user, but the primary concern is the privilege escalation vector within the allowed command itself, not the user specification. Option D is wrong because reading any file with `less` is a consequence of the command's functionality, but the critical security flaw is the shell escape feature that allows executing arbitrary commands, not just reading files.

Practice this question →
31
MCQmedium

Refer to the exhibit. An administrator wants to add the HTTP service (port 80) to the internal zone permanently. Which sequence of commands should be used?

A.firewall-cmd --add-service=http --zone=internal; firewall-cmd --reload
B.firewall-cmd --permanent --add-service=http --zone=internal; systemctl restart firewalld
C.firewall-cmd --zone=internal --add-service=http; firewall-cmd --runtime-to-permanent
D.firewall-cmd --zone=internal --add-service=http --permanent; firewall-cmd --reload
AnswerD

This command correctly combines --permanent to write the http service rule for the internal zone into the active firewalld configuration, then --reload to apply that persisted configuration to the running firewall. Unlike a restart, reload preserves current connections while seamlessly activating the new permanent rule. This two-step sequence is the canonical, exam-accepted method for adding a service and making it effective immediately and after reboot.

Why this answer

It uses the --permanent flag to make the rule persistent across reboots, and then runs firewall-cmd --reload to apply the permanent configuration to the running runtime environment without restarting the firewalld service. This sequence ensures the HTTP service is added to the internal zone permanently while maintaining active connections.

Exam trap

The trap here is that candidates often confuse --reload with restarting the service, or they think runtime changes persist without the --permanent flag, leading them to choose options that either lose the change (A) or unnecessarily restart firewalld (B).

How to eliminate wrong answers

Option A is wrong because it adds the service to the runtime configuration only (no --permanent flag), and then runs --reload, which discards runtime changes and reloads the permanent configuration, effectively removing the just-added rule. Option B is wrong because while it correctly uses --permanent, it then runs systemctl restart firewalld, which is unnecessary and disruptive (it drops all active connections); the proper method is firewall-cmd --reload. Option C is wrong because it adds the service to the runtime configuration first, then uses --runtime-to-permanent to save runtime changes to permanent; while this works functionally, it is not the most direct or recommended sequence for a single permanent addition, and the question asks for the correct sequence among the given options—D is more straightforward and avoids the extra step.

Practice this question →
32
MCQeasy

Which command sets the password maximum age for user 'bob' to 30 days?

A.chage -M 30 bob
B.passwd -x 30 bob
C.usermod -e 30 bob
D.chage -W 30 bob
AnswerA, B

chage -M 30 bob is the standard command for configuring password aging in RHCSA environments, setting the maximum password age to exactly 30 days. This writes to the fifth field of bob's /etc/shadow entry, after which the password will expire and require change. It is the direct equivalent of passwd -x, but is more commonly seen in scripts and documentation.

Why this answer

Both `chage -M 30 bob` and `passwd -x 30 bob` are valid commands to set the maximum password age for user 'bob' to 30 days. `chage -M` is the commonly used and RHCSA-recommended tool for password aging, but `passwd -x` also works on Red Hat systems. Option C (`usermod -e`) sets account expiration, not password maximum age. Option D (`chage -W`) sets the warning period before expiry.

Exam trap

Candidates often think only `chage -M` is valid for setting password max age, but `passwd -x` is also acceptable. The mistake is to mark B as wrong when it is actually correct.

How to eliminate wrong answers

Option B is wrong because `passwd -x 30 bob` sets the maximum password age, but the `-x` option is not a standard `passwd` flag; `passwd` uses `-x` only in some older or non-standard implementations, and on RHEL 8/9 the correct command for this is `chage -M`, not `passwd`. Option C is wrong because `usermod -e 30 bob` sets the account expiration date (in YYYY-MM-DD format or days since epoch), not the password maximum age; `-e` controls when the account itself expires, not the password. Option D is wrong because `chage -W 30 bob` sets the warning period (in days) before password expiration, not the maximum age; `-W` defines how many days before expiry the user is warned, not the expiry duration.

Practice this question →
33
MCQeasy

To enforce that user passwords expire every 90 days and users are warned 7 days before expiration, which command sets these policies for user 'john'?

A.chage -m 90 -W 7 john
B.chage -M 90 -W 7 john
C.usermod -e 90 -f 7 john
D.passwd -x 90 -w 7 john
AnswerB

The chage command manages password aging in /etc/shadow. The -M 90 flag sets maximum days before expiry, while -W 7 defines the warning period before that expiry, together enforcing the 90-day rotation and 7-day advance notice for john.

Why this answer

The `chage -M 90 -W 7 john` command sets the maximum number of days a password is valid (password aging) to 90 days via the `-M` flag, and the `-W` flag sets the warning period to 7 days before expiration. The `chage` command is the standard tool in Red Hat Enterprise Linux for modifying user password aging information stored in `/etc/shadow`.

Exam trap

A common pitfall is confusing the `-m` (minimum days) with `-M` (maximum days) flag in `chage`. The RHCSA exam tests this distinction, and candidates may incorrectly select `usermod` or `passwd` for password expiration settings. Only `chage -M` sets the maximum password age, and `-W` sets the warning period.

How to eliminate wrong answers

Option A is wrong because `-m` sets the minimum number of days before a password can be changed, not the maximum validity period; this would enforce a 90-day minimum password age, which is the opposite of the requirement. Option C is wrong because `usermod -e` sets an account expiration date (in YYYY-MM-DD format), not password aging, and `-f` sets the number of days after password expiration until the account is disabled, not a warning period. Option D is wrong because `passwd -x 90 -w 7` is a valid syntax for setting password maximum age and warning days, but the `passwd` command is not the standard tool for this purpose on RHEL 8/9; `chage` is the preferred and exam-relevant command for password aging policies.

Practice this question →
34
Multi-Selecthard

Which three actions enhance security for user accounts on a Red Hat Enterprise Linux system? (Choose three.)

Select 3 answers
A.Enforcing password complexity via pam_pwquality.
B.Disabling SSH root login by setting PermitRootLogin no.
C.Granting all users sudo access to run all commands.
D.Setting the password expiration to 0 days.
E.Using SSH key-based authentication instead of passwords.
AnswersA, B, E

pam_pwquality enforces password strength during password changes via configurable rules such as minlen, dcredit, ucredit, lcredit, and ocredit, forcing users to create passwords with sufficient length and character diversity. This dramatically shrinks the space of guessable or dictionary-based passwords that an attacker can attempt. As a PAM module typically stacked in system-auth or password-auth, it can also reject passwords too similar to the previous one, closing a common users' shortcut.

Why this answer

Option A is correct because enforcing password complexity via pam_pwquality (configured in /etc/security/pwquality.conf and applied through the pam_pwquality PAM module) requires users to choose strong passwords, reducing the risk of brute-force and dictionary attacks. Option B is correct because setting PermitRootLogin no in /etc/ssh/sshd_config prevents direct root logins over SSH, forcing attackers to compromise a normal account and then escalate privileges, which adds a layer of defense. Option E is correct because SSH key-based authentication uses asymmetric cryptographic key pairs instead of reusable passwords, making credential guessing, brute-force, and password-reuse attacks ineffective.

Option C is not appropriate because granting all users unrestricted sudo access to run all commands violates least privilege and effectively gives every account root-equivalent power. Option D is not appropriate because setting password expiration to 0 days disables expiration, allowing passwords to remain valid indefinitely and increasing the window of exposure if a password is compromised.

Exam trap

The trap here is that candidates may think granting all users full sudo access is a convenience feature for administration, but Red Hat exams emphasize security best practices, so any option that violates least privilege or introduces unnecessary risk is automatically incorrect.

Practice this question →
35
MCQmedium

An administrator runs 'getenforce' and sees 'Enforcing'. They then run 'setenforce 0' but SELinux still denies access to a custom application. What is the most likely reason?

A.SELinux is in enforcing mode and the policy is misconfigured.
B.The application's SELinux context is incorrect and needs relabeling.
C.The issue is due to file permissions or ACLs, not SELinux.
D.The change requires a reboot to take effect.
AnswerC

Because the administrator has already switched SELinux to permissive mode and the access is still refused, the remaining blocker must be from Linux's discretionary access control (DAC) layer — the classic Unix permissions (owner/group/others) or POSIX ACLs. SELinux is a mandatory access control (MAC) system layered on top of DAC, so it can only deny what DAC would otherwise permit; in permissive mode it adds no denials. Inspect ls -l, getfacl, and ownership to find the real permission or ACL problem.

Why this answer

`setenforce 0` switches SELinux to permissive mode, which logs but does not enforce denials. If access is still denied after this command, the issue is not caused by SELinux enforcement but by traditional Linux file permissions (DAC) or ACLs. The administrator should check `ls -l` and `getfacl` to verify the file's ownership and permissions.

Exam trap

The trap here is that candidates assume any denial after `setenforce 0` must still be SELinux-related, overlooking that traditional Linux permissions (DAC) operate independently and can block access even when SELinux is permissive.

How to eliminate wrong answers

Option A is wrong because `setenforce 0` disables enforcing mode, so a misconfigured policy would not cause denials in permissive mode. Option B is wrong because an incorrect SELinux context would only cause denials in enforcing mode; in permissive mode, context mismatches are logged but not enforced, so the application would still run. Option D is wrong because `setenforce` takes effect immediately without requiring a reboot; SELinux runtime mode changes are instantaneous.

Practice this question →
36
Multi-Selecthard

Which TWO methods are considered best practices for securing SSH access to a server? (Select exactly two.)

Select 2 answers
A.Disable root login by setting PermitRootLogin no.
B.Use only password authentication for simplicity.
C.Use key-based authentication with passphrase-protected keys.
D.Change the default SSH port to a high-numbered port.
E.Allow SSH access for all users in the system.
AnswersA, C

Setting PermitRootLogin no in /etc/ssh/sshd_config blocks direct SSH logins as the root user. This forces administrators to authenticate as an unprivileged account and then use sudo, which provides an auditable trail of privileged commands. Since root has unrestricted access to the entire system, removing direct root SSH access significantly reduces the risk of attackers obtaining full control through a single root credential compromise.

Why this answer

Disabling root login by setting `PermitRootLogin no` in `/etc/ssh/sshd_config` prevents direct SSH access as the root user, forcing administrators to log in as a regular user and then use `sudo` or `su` to escalate privileges. This reduces the attack surface by eliminating a high-value target for brute-force attacks and ensures all actions are auditable via the regular user's session.

Exam trap

Red Hat often tests the misconception that changing the default SSH port (option D) is a legitimate security measure, but in the EX200 exam, security through obscurity is never considered a best practice—only controls that enforce authentication and authorization are accepted.

Practice this question →
37
MCQmedium

An administrator wants to allow user 'alice' to SSH into the server using key-based authentication only. Which configuration change is required?

A.Add alice's public key to ~alice/.ssh/authorized_keys and set PubkeyAuthentication yes in sshd_config.
B.Add alice's private key to /etc/ssh/authorized_keys.
C.Set PasswordAuthentication no in /etc/ssh/sshd_config and restart sshd.
D.Set PermitRootLogin prohibit-password.
AnswerA

Alice's public key is placed in ~alice/.ssh/authorized_keys, and the sshd server verifies that alice possesses the matching private key by sending a challenge that requires a signature. Setting PubkeyAuthentication yes in sshd_config (or confirming it is uncommented, as it defaults to yes) explicitly enables this key-based login mechanism. This is the proper, secure way to allow alice to authenticate without a password.

Why this answer

SSH key-based authentication requires the user's public key to be placed in the user's `~/.ssh/authorized_keys` file, and the SSH daemon must have `PubkeyAuthentication yes` set in `/etc/ssh/sshd_config` to allow public key authentication. This configuration ensures that only users with the corresponding private key can authenticate as 'alice'.

Exam trap

The trap here is that candidates often think disabling password authentication alone is sufficient for key-based access, but they forget that the public key must be placed in the correct location and that `PubkeyAuthentication` must be explicitly enabled if it was previously disabled.

How to eliminate wrong answers

Option B is wrong because private keys must never be stored on the server; only public keys belong in `authorized_keys` files, and the correct location is the user's home directory, not `/etc/ssh/`. Option C is wrong because disabling password authentication (`PasswordAuthentication no`) alone does not enable key-based authentication; it only prevents password logins, but without `PubkeyAuthentication yes` and a valid public key, 'alice' would be locked out entirely. Option D is wrong because `PermitRootLogin prohibit-password` only affects root login, not user 'alice', and it does not configure key-based authentication for non-root users.

Practice this question →
38
MCQhard

A company requires that SSH access from the external network (10.0.1.0/24) only be allowed to port 2222, and all other incoming traffic on the firewall should be dropped. Which firewalld rule should be applied to the external zone?

A.firewall-cmd --zone=external --add-service=ssh --permanent
B.firewall-cmd --zone=external --add-port=2222/tcp --permanent
C.firewall-cmd --zone=external --add-rich-rule='rule family="ipv4" source address="10.0.1.0/24" service name="ssh" accept' --permanent
D.firewall-cmd --zone=external --add-rich-rule='rule family="ipv4" source address="10.0.1.0/24" port port="2222" protocol="tcp" accept' --permanent
AnswerD

This rich rule combines a source address restriction (10.0.1.0/24) with an explicit port and protocol (2222/tcp), so only that internal subnet can reach the SSH service on the non-standard port. Using port instead of service avoids any ambiguity introduced by default service definitions. With --permanent, the rule survives reloads, and it precisely matches the requirement of limiting external SSH access to the specified source network and port.

Why this answer

It uses a rich rule to explicitly allow incoming TCP traffic on port 2222 from the 10.0.1.0/24 source network, which matches the requirement. The default target for the external zone is 'drop', so only explicitly permitted traffic is allowed; this rule ensures SSH on port 2222 is accepted while all other incoming traffic is dropped.

Exam trap

The trap here is that candidates often confuse the 'service name' with a custom port, selecting Option C which uses the SSH service (port 22) instead of the required port 2222, or they forget to restrict the source address as in Option B.

How to eliminate wrong answers

Option A is wrong because it adds the standard SSH service (port 22/tcp) to the external zone, not port 2222, and does not restrict the source to 10.0.1.0/24. Option B is wrong because it opens port 2222/tcp to all sources, not just the 10.0.1.0/24 network, violating the source restriction requirement. Option C is wrong because it references the SSH service name (port 22/tcp) instead of port 2222, and the source address is specified but the service is incorrect.

Practice this question →

Ready to test yourself?

Try a timed practice session using only Manage Security questions.

Start 20-question session