CCNA Manage security Questions

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 →

Multi-Selecteasy

A systems administrator needs to list all currently defined firewall rules in firewalld, including rules for all zones. Which TWO commands can be used to accomplish this? (Choose exactly two.)

Select 1 answer

A.firewall-cmd --list-all-zones

B.iptables -L

C.systemctl status firewalld

D.firewall-cmd --get-default-zone

E.firewall-cmd --list-all

AnswersA

Correct. This command displays the full configuration for all zones, including rules for each zone.

Why this answer

`firewall-cmd --list-all-zones` displays the firewall rules for every zone in firewalld, including all default and custom zones, satisfying the requirement to list rules for all zones. Option E is incorrect because `firewall-cmd --list-all` only shows rules for the default zone, not all zones. The other options are incorrect: `iptables -L` shows raw kernel rules that may not reflect firewalld's configuration, `systemctl status firewalld` checks the service status, and `firewall-cmd --get-default-zone` shows only the default zone name, not rules.

Exam trap

Candidates might assume that `firewall-cmd --list-all` lists all zones, but it only lists the default zone. The key distinction is the `--list-all-zones` option specifically for all zones, versus `--list-all` for the default zone only.

Practice this question →

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 →

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

Permanent rules do not affect runtime until reload.

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 →

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 →

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 →