Firewalld Permanent Rule Not Taking Effect: Why Clients Can't Connect
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?
Quick Answer
The answer is that the rule was added with --permanent but firewall-cmd --reload was not run. When you use the --permanent flag in firewalld, the rule is written only to the persistent configuration files on disk, not to the active runtime firewall. Until you execute firewall-cmd --reload, the runtime configuration remains unchanged, so the new HTTPS rule is invisible to the kernel’s netfilter and clients are still blocked. On the Red Hat Certified System Administrator EX200 exam, this is a classic trap: candidates often assume --permanent makes a rule active immediately, but it only ensures survival across reboots. The exam tests your understanding that firewalld has two separate configuration layers—runtime and permanent—and that reloading is required to merge them. Remember the mnemonic: “Permanent is for persistence, reload is for presence.”
⚠ Common exam trap
It's easy for candidates to assume adding a rule with `--permanent` immediately takes effect, forgetting that firewalld requires a reload or the `--runtime-to-permanent` approach to synchronize changes.
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
✓
The rule was added with --permanent but firewall-cmd --reload was not run.
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.
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 rule was added with --permanent but firewall-cmd --reload was not run.
Why this is correct
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.
- ✗
The rule must be added as a rich rule, not a simple service.
Why it's wrong here
Adding HTTPS as a service is valid; firewalld ships predefined services including https, so a rich rule is unnecessary and would not resolve the connectivity failure. It is tempting because rich rules do allow granular source and port control, and would be correct when permitting non-standard ports or specific source addresses.
- ✗
The default zone is not set to public.
Why it's wrong here
The rule was explicitly added to the public zone, so the default zone assignment does not affect whether that rule applies to the interface. It is tempting because a mismatched default zone genuinely blocks traffic when rules are added without specifying a zone; here the zone was named, so this is not the cause.
- ✗
firewalld is just a wrapper for iptables, so iptables rules must be cleared.
Why it's wrong here
firewalld manages its own nftables or iptables rules directly; flushing iptables would remove firewalld's rules and break filtering rather than restore HTTPS access. It is tempting because firewalld does sit atop the packet-filtering layer, and manual iptables edits can conflict, but the actual cause is that the runtime configuration was not reloaded.
Go deeper
Related to this question
About these practice questions
This EX200 question is part of Courseiva's 427-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on EX200
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Order the steps to configure firewall rules to allow HTTP and HTTPS traffic using firewalld.
medium- ✓ A.1. Add HTTP service: firewall-cmd --permanent --add-service=http 2. Add HTTPS service: firewall-cmd --permanent --add-service=https 3. Reload firewall: firewall-cmd --reload 4. Verify: firewall-cmd --list-services
- B.1. Reload firewall: firewall-cmd --reload 2. Add HTTP service: firewall-cmd --permanent --add-service=http 3. Add HTTPS service: firewall-cmd --permanent --add-service=https 4. Verify: firewall-cmd --list-services
- C.1. Add HTTP service: firewall-cmd --add-service=http (without --permanent) 2. Add HTTPS service: firewall-cmd --add-service=https (without --permanent) 3. Reload firewall: firewall-cmd --reload 4. Verify: firewall-cmd --list-services
- D.1. Add HTTP service: firewall-cmd --permanent --add-service=http 2. Reload firewall: firewall-cmd --reload 3. Add HTTPS service: firewall-cmd --permanent --add-service=https 4. Verify: firewall-cmd --list-services
Why A: Firewalld rules are added with --permanent flag and then reloaded to take effect.
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.