EX294 Practice Question: Create content collections and execution environments
Network Topology
The build fails with a DNS resolution error for `registry.redhat.io`. Which troubleshooting step is most likely to resolve the issue?
⚠ Common exam trap
Many candidates confuse DNS resolution errors with authentication or cache issues, leading them to choose `podman login` or `--no-cache` instead of recognizing that DNS must work before any network communication can occur.
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
✓
Verify DNS settings in `/etc/resolv.conf` or configure a custom DNS server for the container runtime.
A DNS resolution error for `registry.redhat.io` indicates that the container runtime (e.g., Podman) cannot resolve the registry's hostname to an IP address. This is a network/DNS issue, not an authentication or caching problem. Verifying or correcting DNS settings in `/etc/resolv.conf` or configuring a custom DNS server for the container runtime directly addresses the root cause by ensuring the host or container runtime can resolve the registry's FQDN.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Run `podman login registry.redhat.io` to authenticate.
Why it's wrong here
Authentication happens after the hostname resolves, so credentials cannot fix a failed lookup of registry.redhat.io. It is tempting because login errors are common with Red Hat registries, and authenticating is correct when the failure is an authorisation or token error rather than DNS.
- ✗
Restart the container runtime service.
Why it's wrong here
Restarting the runtime does not correct a misconfigured or unreachable resolver, so the lookup still fails. It is tempting after a daemon crash or hung socket, where a restart genuinely restores container operations, but DNS configuration persists across restarts.
- ✓
Verify DNS settings in `/etc/resolv.conf` or configure a custom DNS server for the container runtime.
Why this is correct
The DNS resolution failure means the container runtime cannot resolve registry.redhat.io, so checking /etc/resolv.conf or configuring a custom DNS server for the runtime restores name resolution. This addresses the constraint directly, unlike authentication or firewall changes.
- ✗
Use the `--no-cache` flag to force a fresh build.
Why it's wrong here
Bypassing the layer cache does not alter name resolution, so the DNS failure recurs. It is tempting when stale cached layers mask a changed Dockerfile, which is a genuine build problem, but here the resolver itself is failing before any layer is fetched.
Visual reference
Go deeper
Related to this question
About these practice questions
Courseiva writes every EX294 question from scratch — 392 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This EX294 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 EX294 exam.