EX200 Manage security Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  The subnet 192.168.1.0/24 is not a valid source for rich rules.

  Why it's wrong here

  This is incorrect because firewalld rich rules support standard CIDR notation for source addresses. A rule like `rule family=ipv4 source address=192.168.1.0/24 service name=ssh accept` is syntactically valid inside the `internal` zone. The failure is not due to the subnet format but rather because the rule is never evaluated: the network interface carrying that subnet's traffic is still bound to the default `drop` zone, so the rich rule does not apply.

• ✓

  The network interface is not assigned to the 'internal' zone.

  Why this is correct

  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.

• ✗

  The rich rule was not made permanent.

  Why it's wrong here

  This is wrong because permanence affects only whether a rule survives a reload or reboot, not whether it is active in the current runtime configuration. Even a non-permanent rich rule is immediately applied to its zone, so if the interface were correctly bound to `internal`, SSH would already work. Making the rule permanent does not fix the fact that the interface is in the wrong zone; it would simply preserve the same ineffective rule configuration after a reboot.

• ✗

  The SSH service is not enabled in the default zone.

  Why it's wrong here

  This is irrelevant because the rich rule is defined in the `internal` zone, not in the default zone. The default zone is `drop`, and enabling the SSH service there would allow SSH only for traffic assigned to that default zone, which is exactly the behavior we do not want (it would bypass the intended restriction). The real problem is that the interface belongs to the default zone instead of `internal`, so adding SSH to the default zone would either not affect the rule or create a conflicting rule; the correct fix is to move the interface to `internal`.

Go deeper

Related to this question