EX200 Manage security Practice Question
Which three actions enhance security for user accounts on a Red Hat Enterprise Linux system? (Choose three.)
⚠ Common exam trap
Test-takers frequently 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.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Enforcing password complexity via pam_pwquality.
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.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Enforcing password complexity via pam_pwquality.
Why this is correct
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.
- ✓
Disabling SSH root login by setting PermitRootLogin no.
Why this is correct
Setting PermitRootLogin no in /etc/ssh/sshd_config prevents direct SSH sessions as root, which is a prime target for brute-force attacks because the username is always known. Administrators must first authenticate with an ordinary user account and then escalate via su or sudo, adding an auditable step. This setting does not hinder console logins or sudo; it simply removes direct root access from the network, limiting the attack surface without breaking administrative workflows.
- ✗
Granting all users sudo access to run all commands.
Why it's wrong here
Granting all users blanket sudo rights to run any command means that compromising any single account instantly yields root control of the host, violating the principle of least privilege. Such a wide-open sudo policy also strips the audit trail of its value, because there is no meaningful distinction between users. A proper sudo configuration limits each user to the specific commands or groups needed for their role, clearly reducing both the blast radius of an attack and the ability to trace privileged actions to a specific administrator.
- ✗
Setting the password expiration to 0 days.
Why it's wrong here
With chage -M 0 (or field 5 of /etc/shadow set to 0), password aging is disabled and the password never expires, so a credential that has been leaked, guessed, or reused remains valid indefinitely. That indefinite window greatly increases the chance that an attacker can use a stolen hash or password before it is changed. Security requires a finite maximum age, such as 90 or 180 days, so that even a compromised password is only a temporary exposure and users are forced to rotate it regularly.
- ✓
Using SSH key-based authentication instead of passwords.
Why this is correct
SSH key-based authentication leverages a public/private key pair: the server stores the public key, and the client proves possession of the private key, so knowledge of a password alone cannot impersonate a user. Because the private key is never transmitted over the network, keys are inherently resistant to password guessing, credential phishing, and other interception attacks. When the private key is protected by a strong passphrase and used through ssh-agent, key-based authentication provides a significantly stronger factor than a reusable password.
Quick reference
Symmetric Encryption Algorithm Comparison
| Algorithm | Key Size | Block Size | Status | Notes |
|---|---|---|---|---|
| AES-128 | 128-bit | 128-bit | Current standard | NIST approved; WPA3, TLS |
| AES-256 | 256-bit | 128-bit | Current standard | Preferred for sensitive / govt data |
| 3DES | 112-bit effective | 64-bit | Deprecated (2023) | Replaced by AES |
| DES | 56-bit | 64-bit | Broken | Cracked in < 24 h; never deploy |
| ChaCha20 | 256-bit | Stream cipher | Current | TLS 1.3, WireGuard |
Go deeper
Related to this question
About these practice questions
One of 427 original EX200 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX200 practice question is part of Courseiva's free Red Hat certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the EX200 exam.