TTechclick ⚡ XP 0% All lessons
F5 · BIG-IP DNS / GTM · Interview PrepInteractive · L1 / L2 / L3

F5 BIG-IP DNS / GTM Interview Questions — GSLB, Wide IPs & Cheat-Sheet

The complete F5 BIG-IP DNS (GTM) interview guide — Global Server Load Balancing for freshers and experienced engineers. Real questions with answers across GTM vs LTM, GSLB and the DNS resolution chain, the Wide IP / Data Center / Server / Pool object hierarchy, load-balancing methods (Topology, Global Availability, Round Robin, Ratio, QoS), iQuery/big3d health, sync groups, DNSSEC and troubleshooting. Scenario-led, interactive, with a printable cheat-sheet.

📅 2026-06-11 · ⏱ 18 min · 1 live demo · 5 infographics · real console form · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

F5 BIG-IP DNS / GTM interview questions and answers (2026) — GSLB across data centers, GTM vs LTM, the Wide IP / Data Center / Server / Pool object hierarchy, load-balancing methods (Topology, Global Availability, Round Robin, Ratio, QoS), iQuery/big3d health, sync groups, DNSSEC and troubleshooting wrong/down-DC answers, with scenarios and a printable cheat-sheet.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

GTM role & GSLB

DNS-based GSLB across DCs; GTM vs LTM.

 2

Components & hierarchy

Data Centers, Servers, Wide IPs, Pools, Listeners.

 3

LB methods & topology

Global Availability, Topology, RR, Ratio, QoS, persistence.

 4

Health, sync & ops

iQuery/big3d, sync group, DNSSEC, troubleshooting.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. What does GTM actually load-balance?

Answered in GTM role & GSLB.

2. How does GTM learn a data center is healthy?

Answered in LB methods & topology.

3. Slow failover during an outage usually means…

Answered in Components & hierarchy.

Most engineers think…

Most candidates say "GTM? It's the same as LTM — it load-balances servers." — and the interview quietly ends there.

That single sentence fails you. GTM is the opposite of a proxy: it makes an intelligent DNS decision — which data-center IP to hand back, using DC health learned via iQuery — and never carries the traffic. LTM is the full proxy that load-balances the actual connection among real servers inside the chosen data center. Lead with "GTM = DNS-based GSLB across data centers; LTM = in-DC connection load balancing." This lesson trains the framing that gets you hired.

① GTM's role & GSLB — DNS-based load balancing across data centers

Every F5 GTM interview opens here, and one wrong sentence ends it. BIG-IP DNS / GTM performs GSLB — it spreads traffic across multiple data centers by controlling DNS answers. The killer distinction: GTM does not proxy traffic. It makes an intelligent DNS decision — which data-center IP to hand back — and LTM then load-balances the actual connection inside that DC.

Figure 1 — One Wide IP, many data centers — GTM decides which DC answers
One Wide IP, many data centers — GTM decides which DC answersBIG-IP DNS (GTM) sits above two data centers. Each DC runs an LTM with virtual servers. GTM does not carry traffic — it answers the DNS query with the IP of the healthiest/closest DC; LTM then load-balances the connection inside that DC.Client query → GTM picks a DC → LTM load-balances inside that DCClient (browser)LDNS resolverDelegation / CNAMEiQuery health feedBIG-IP DNS (GTM)answers DNS onlyDC1 — Mumbai LTM + VSDC2 — Chennai LTM + VSWide IP www.example.comA-record = best DC IP
GTM is an intelligent DNS decision engine, not a proxy. It hands back ONE A-record — the IP of the best data center — using DC health learned over iQuery. LTM then balances the actual TCP connection across servers inside that DC.

The F5 GTM vocabulary every interview opens with

Know these four cold before anything else. Tap each card.

🌍
BIG-IP DNS / GTM
tap to flip

Global Traffic Manager — intelligent DNS that performs GSLB across data centers by answering name queries with the best DC's IP. It never proxies the traffic.

🏷️
Wide IP
tap to flip

The FQDN (e.g. www.example.com) that GTM is authoritative for. It maps the name to one or more pools and a load-balancing method.

📡
iQuery / big3d
tap to flip

The health protocol (TCP 4353): gtmd talks iQuery to the big3d agents, which probe data centers and share health across the sync group.

🧱
Pool member
tap to flip

A pool member is an LTM virtual server (a data-center VIP) — not a real server. GTM picks a member; LTM then balances inside that DC.

GTM sits in the DNS resolution chain by delegation or CNAME: the parent zone delegates the name (or CNAMEs to it) so GTM becomes authoritative for the Wide IP. The crisp interview line: GTM = DNS-based GSLB across data centers; LTM = in-DC connection load balancing.

Quick check · Q1 of 10 · Remember

An interviewer asks the one-line difference between GTM and LTM. Best answer?

Correct: b. GTM (BIG-IP DNS) does GSLB by answering DNS — it picks which data center's IP to return. LTM is a full proxy that distributes the actual connection across servers within a single data center. GTM never carries the user's traffic.
👉 So far: GTM = DNS-based GSLB across data centers; it answers an A-record, never proxies. LTM = full-proxy load balancing inside one DC. The parent zone delegates/CNAMEs the name to GTM, which is authoritative for the Wide IP.
The 'GTM load-balances servers' trap

Answer firmly: it does not. GTM load-balances data centers by choosing which one's IP to return in DNS. The pool members it chooses between are LTM virtual servers, not real servers — and once the client has the IP, GTM is out of the path entirely. LTM does the connection-level balancing inside the chosen DC.

② Components & object hierarchy — Data Centers, Servers, Wide IPs, Pools, Listeners

GTM has a strict object hierarchy and interviewers love walking you up it. A Data Center groups your Server objects; each Server holds its virtual server entries (which are the LTM VIPs). A Wide IP (the FQDN) maps to one or more Pool, and pool Pool Member reference those virtual servers.

▶ Watch a Wide IP resolution choose a data center

How GTM answers a name query with the IP of the best data center — and what happens when that DC fails. Press Play for the healthy path, then Break it to see the failure.

① Query reaches GTM listenerThe LDNS query for www.example.com is delegated to the GTM listener on port 53.
▼
② Wide IP + LB methodGTM matches the Wide IP and runs its load-balancing method (here, Topology) over the pools.
▼
③ Health check via iQueryGTM checks each pool member's state from iQuery/big3d — only UP DCs are eligible.
▼
④ A-record returnedGTM returns the chosen DC's IP as an A-record; the client connects and LTM balances inside that DC.
Press Play to step through the healthy path. Then press Break it.
Figure 2 — How a Wide IP gets resolved — the GSLB DNS path
How a Wide IP gets resolved — the GSLB DNS pathThe end-to-end path a name resolution takes: the client asks its LDNS, the parent zone delegates the subdomain to the GTM listener, GTM matches the Wide IP, runs the load-balancing method over the pools, and returns one A-record.① Client asks LDNS for www.example.comrecursive resolver does the work▼② Parent zone delegates / CNAMEs to GTMNS or CNAME points the name at GTM▼③ GTM Listener (UDP/TCP 53) receives querya listener is a virtual server for DNS▼④ Wide IP matched → pool list selectedFQDN maps to one or more pools▼⑤ Pool LB method picks a pool memberTopology / Global Availability / RR etc.▼⑥ Member = an LTM virtual server (a DC VIP)health learned via iQuery / monitors▼⑦ A-record returned → client connects to that DCLTM then balances inside the DC
Two facts interviewers love: the parent zone must DELEGATE (or CNAME) the name to GTM — GTM is authoritative for the Wide IP — and the answer is just an A-record, so DNS TTL controls how long clients keep hitting the old DC.
COLOUR KEYdown / wrong DCGTM / DNS decisiontopology / TTL pointhealthy / chosen DC

A Listener is what actually catches DNS traffic on port 53 — without a listener, GTM is configured but deaf. The full stack: Data Center → Server → (its) Virtual Servers → Wide IP → Pool → Pool Members, with a Listener catching the query.

Quick check · Q2 of 10 · Apply

You created a Wide IP, pools and pool members, but GTM answers no queries at all. What is the most likely missing object?

Correct: b. A Listener is a specialized virtual server that catches DNS packets on UDP/TCP 53. Without a Listener bound to the right IP, GTM never receives the query — so the Wide IP, pools and members are all correct but unused.

Pause & Predict

In a GTM pool, what exactly is a 'pool member' — a real backend server or something else? Type your guess.

Answer: Something else. A GTM pool member references a virtual server, which maps to an LTM virtual server (a data-center VIP). GTM chooses among data-center VIPs, not real servers. The real servers are LTM's pool members inside that DC. Confusing the two is the classic hierarchy mistake.

Priya at Infosys faces this

A newly built Wide IP for www.example.com returns nothing — clients get SERVFAIL, though pools and members look fine.

Likely cause

No Listener is catching DNS on port 53 (or it's bound to the wrong self-IP/VLAN), so the query never reaches the Wide IP logic.

Diagnosis

From an LDNS, dig @ www.example.com — no answer means the listener isn't there; check DNS ▸ Delivery ▸ Listeners.

DNS ▸ Delivery ▸ Listeners + Wide IP state
Fix

Create a Listener on the external self-IP (UDP/TCP 53), confirm the Wide IP is enabled and that the parent zone delegates the name to this GTM.

Verify

dig @ www.example.com now returns the DC's A-record; the Wide IP shows green.

👉 So far: Hierarchy: Data Center → Server → its Virtual Servers → Wide IP (FQDN) → Pool → Pool Members. A pool member is an LTM virtual server, not a real server. A Listener on port 53 is what makes GTM answer at all.

③ Load-balancing methods & topology — how GTM picks the data center

A Wide IP/pool has three method slots: a preferred method, an alternate method, and a fallback method. Static methods include Round Robin and Ratio; Global Availability gives strict ordered failover.

🖥️ This is where you build a GSLB record — DNS ▸ GSLB ▸ Wide IPs ▸ Create in the BIG-IP DNS (GTM) config utility. Fields ①②③ decide which data center a client is sent to.

bigip.example.com · DNS ▸ GSLB ▸ Wide IPs ▸ Create
Name *
www.example.com
Type
A
Pool List
Order: Pool / Ratio
Load Balancing Method
Topology
Pools
dc1_pool, dc2_pool
Last Resort Pool
dc2_pool
Persistence
Enabled (TTL 3600)
State
Enabled
Finished   Cancel

① Load Balancing Method is the brain — Topology sends users to the nearest DC by their LDNS region; switch to Global Availability for strict primary/secondary failover. ② Pools list the data centers in order; each pool member is an LTM virtual server. ③ Last Resort Pool is answered even when every preferred pool is down, so users get some IP instead of NXDOMAIN.

The smart methods use live data: Topology sends users to the nearest DC by the region of their LDNS; QoS picks the best weighted score; Completion Rate and VS Capacity round out the dynamic set. Persistence pins an LDNS to the same DC for a window.

Pause & Predict

A bank wants Mumbai users on the Mumbai DC and Chennai users on the Chennai DC — which LB method? Type your guess.

Answer: Topology. It matches the source region of the client's LDNS against Topology records and returns the nearest data center. Global Availability would just send everyone to the first UP pool; Round Robin would split users randomly across both DCs regardless of where they are.
Quick check · Q3 of 10 · Apply

An Indian retailer wants a strict primary/secondary setup: ALL traffic to the Mumbai DC, and only fail to Chennai when Mumbai is fully down. Which method?

Correct: c. Global Availability always returns the first UP pool/member in the ordered list, only moving to the next when the first goes down — exactly the ordered primary/secondary failover the retailer wants. Topology routes by region; Round Robin/Ratio spread load across both.

Karthik at TCS faces this

After switching a Wide IP to Topology, users in Bengaluru keep landing on the far Chennai DC instead of the nearer Mumbai DC.

Likely cause

The Topology records (or the region/continent definitions) are wrong, or the LDNS subnet for those users isn't mapped — GTM can only see the LDNS source, not the actual client.

Diagnosis

Check DNS ▸ GSLB ▸ Topology records and the longest-match score; confirm which LDNS subnet those users resolve through.

DNS ▸ GSLB ▸ Topology Records + LDNS subnet
Fix

Add/repair the Topology record mapping the Bengaluru LDNS subnet/region to the Mumbai pool, and verify record order (longest, highest-weight match wins).

Verify

Resolutions from that LDNS now return the Mumbai DC IP; Topology statistics show the correct region match.

Topology routes on the LDNS, not the user

GTM never sees the end client's IP — only the client's LDNS source. If users sit behind a central or public resolver in another region, Topology sends them where the resolver is. For accuracy, keep resolvers regional or enable EDNS Client Subnet so the real client subnet is visible.

④ Health, sync & ops + troubleshooting

GTM learns data-center health it doesn't host directly through iQuery: the gtmd process opens iQuery connections to the big3d agents over TCP 4353. Those agents probe the DCs and broadcast results across the sync group. Prober pools decide which systems do the probing; DNSSEC can sign the answers.

Figure 4 — GTM is sending users to the wrong or down data center — why?
GTM is sending users to the wrong or down data center — why?A ladder to isolate a bad GSLB answer — start at the iQuery/big3d health feed, then the monitor state, then the topology records, then DNS caching/TTL.GTM is sending users to the wrong or down data center — why?check iQuery / big3d (gtmd)is the DC's health feed green on port 4353?FAILiQuery down / version mismatchGTM is blind to that DC — fix big3d / port 4353PASS ↓check the VS / server monitoris the DC's virtual server marked UP?FAILMonitor marks VS downfix the monitor or the LTM VIP it probesPASS ↓check the Topology recordsdoes the region map point to the right DC?FAILWrong / missing region recordfix the Topology record + LDNS subnetPASS ↓check DNS TTL / LDNS cacheis the client still on a cached old answer?FAILStale answer cached at LDNSlower the Wide IP TTL; wait out the cacheAll pass → the layer is healthy; look one level up.
iQuery on TCP 4353 is the first thing to check — if big3d can't reach a data center, GTM has no health data and will still send users to a dead DC, or refuse to send to a healthy one.

Pause & Predict

A Wide IP shows a data center as DOWN even though the application is clearly up. Where do you look first? Type your guess.

Answer: The iQuery/big3d health feed on TCP 4353. If gtmd can't reach that DC's big3d (firewall, version mismatch, or big3d not running), GTM has no health data and marks the DC down — or stale. Check port 4353 reachability and that all sync-group members run the same big3d version, then the VS monitor.

Rahul at Wipro faces this

GTM keeps answering with the Chennai DC even though Chennai's app is down — users hit a dead site.

Likely cause

GTM has no fresh health for Chennai: iQuery/big3d is unreachable on 4353 (so the VS still looks UP), or the monitor on that virtual server isn't actually testing the app.

Diagnosis

From the GTM, check iQuery connection state to Chennai's big3d (port 4353); check the VS monitor result; confirm sync-group big3d versions match.

DNS ▸ GSLB ▸ Servers (iQuery state) + VS monitor
Fix

Open TCP 4353 between the BIG-IPs (or restart/reinstall big3d), align big3d versions across the sync group, and attach a real application monitor to the Chennai VS so a dead app marks it down.

Verify

GTM now sees Chennai as down and fails the Wide IP over to Mumbai; the next resolution returns the Mumbai IP.

Confirm the GSLB answer + iQuery health from the box
dig @172.16.10.53 www.example.com A +short   # which DC IP is GTM handing back?
tmsh show gtm wideip www.example.com           # Wide IP + pool member availability
tmsh show /gtm server dc1_bigip iquery-state    # is iQuery to that DC up on 4353?
Expected output
203.0.113.20                                  ( = Mumbai DC VIP )
Wideip www.example.com  availability-state available
dc1_bigip  iquery-state connected  big3d-version 15.1.0
Quick check · Q4 of 10 · Analyze

Mumbai is fully down, GTM correctly fails the Wide IP over to Chennai — yet many users still hit the dead Mumbai IP for several minutes. Most likely cause?

Correct: c. GTM only controls the answer it gives at resolution time. Once an LDNS has cached the old A-record, clients keep using it until the TTL expires. A high Wide IP TTL means slow failover. Lower the TTL (e.g. 30–60s) so caches refresh quickly during an outage.

Sneha at HCL faces this

Failover works in testing, but during a real Mumbai outage customers complained for 5–10 minutes before traffic moved to Chennai.

Likely cause

The Wide IP TTL was set high (e.g. 3600s), so LDNS resolvers kept serving the cached Mumbai IP long after GTM started answering Chennai.

Diagnosis

Check the Wide IP / pool TTL and the persistence TTL; dig the name from several public resolvers to see the cached value.

DNS ▸ GSLB ▸ Wide IP TTL + persistence
Fix

Lower the Wide IP TTL to ~30–60s (balancing query load), and review persistence TTL so a failed DC isn't pinned; document the trade-off with the app team.

Verify

Re-test: after a forced down, public resolvers move to the Chennai IP within ~1 minute instead of 5–10.

Figure 5 — F5 BIG-IP DNS / GTM interview cheat-sheet
F5 BIG-IP DNS / GTM interview cheat-sheetOne card: GTM vs LTM, the object hierarchy, the LB methods, how health is learned, and the troubleshooting first-checks.🖨 Print this before your F5 GTM interview🌍GTM ≠ LTMGTM = DNS-based GSLB acrossDCs (answers an A-record). LTM= full-proxy load balancinginside one DC.🧱Object hierarchyData Center → Server (holdsLTM virtual servers) → Wide IP(FQDN) → Pool → Pool Members(VS). Listener catches DNS on⚖LB methodsPreferred → Alternate →Fallback. Round Robin · Ratio· Global Availability ·Topology · QoS · Completion📡Health = iQuerygtmd talks iQuery to big3d onTCP 4353; big3d probes DCs andshares results across the syncgroup. Prober pools do the🧭Topology vs GATopology = pick DC byregion/geolocation of theLDNS. Global Availability =always the first UP pool🔧TroubleshootiQuery/4353 up? → monitormarks VS up? → topology recordright? → DNS TTL still cached?Lower TTL for fast failover.Train hands-on. Pass with proof. — Techclick
Tap the Preview button at the top to save this one-page card before your interview.
Prove the GSLB answer, don't assume

Don't close a GTM ticket on 'DNS looks fine'. dig @<listener> name A proves which DC GTM is returning; show gtm server <name> iquery-state proves health is flowing on 4353; checking the Wide IP TTL proves how fast failover will actually reach users. Those three answer most GSLB tickets.

👉 So far: Health is learned via iQuery (gtmd → big3d on TCP 4353), shared across the sync group; prober pools do the probing; DNSSEC signs answers. When GTM sends users to a down/wrong DC: check iQuery/4353 → VS monitor → topology records → DNS TTL caching.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from F5 docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Apply

You built a Wide IP, pools and pool members, but GTM answers no DNS queries at all. Which object are you most likely missing?

Correct: b. A Listener is the specialized virtual server that catches DNS packets on UDP/TCP 53. Without it on the correct self-IP, GTM never receives the query — so the Wide IP, pools and members are all valid but never used.
Q6 · Analyze

An Indian bank with DCs in Mumbai and Chennai wants users sent to their nearest data center based on where their resolver sits — yet users behind a single central resolver all land on one DC. Which method is in use and what is the catch?

Correct: d. Topology matches the source region of the client's LDNS, not the end client. If users share one central/public resolver in another region, Topology sends them where the resolver sits. Keep resolvers regional or enable EDNS Client Subnet so the real client subnet is visible.
Q7 · Analyze

A retailer wants ALL traffic on the Mumbai DC and only fail to Chennai when Mumbai is fully down. Which method gives that strict primary/secondary behaviour, and why not the others?

Correct: d. Global Availability always returns the first UP pool/member in the ordered list and moves on only when the first is down — exactly ordered primary/secondary failover. Round Robin spreads evenly, Topology geo-routes, and QoS picks by score, none of which is strict primary/secondary.
Q8 · Analyze

GTM keeps answering with a data center whose application is actually down, sending users to a dead site. Most likely root cause?

Correct: c. GTM learns DC health over iQuery (gtmd → big3d on TCP 4353). If that feed is broken or the virtual server has no real application monitor, GTM still believes the DC is UP and keeps returning its IP. Fix 4353 reachability/big3d and attach a real monitor.
Q9 · Evaluate

Mumbai goes down, GTM correctly fails the Wide IP to Chennai, but users keep hitting the dead Mumbai IP for several minutes. The best explanation an interviewer wants is…

Correct: b. GTM only controls the answer it hands out at resolution time. A high Wide IP TTL means LDNS resolvers cache the old Mumbai IP and keep using it until the TTL expires. Lower the TTL (e.g. 30–60s) so failover reaches users quickly, accepting more DNS query load.
Q10 · Evaluate

An interviewer says 'GTM is basically the same as LTM, it just load-balances servers.' The crispest correct rebuttal is…

Correct: a. GTM (BIG-IP DNS) does GSLB by answering DNS — it picks which data center's IP to return using health learned over iQuery, and never carries the connection. LTM is the full proxy that balances the actual session across real servers within a single data center. Saying they're 'the same' fails the interview.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why is GTM not the same as LTM? Then compare to the expert version.

Expert version: Because GTM only answers DNS — it never proxies traffic. GTM does GSLB: it decides which data center's IP to return for a Wide IP (FQDN), using data-center health learned over iQuery from the big3d agents. Once the client has that IP, GTM is out of the path. LTM is a full proxy: it terminates the connection and load-balances it across real servers inside a single data center. So GTM balances ACROSS data centers via DNS; LTM balances WITHIN one data center via proxying — and a GTM pool member is an LTM virtual server, not a real server.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

BIG-IP DNS / GTM
Global Traffic Manager — intelligent DNS that performs GSLB across data centers by answering name queries with the best DC’s IP (renamed BIG-IP DNS from v12).
LTM
Local Traffic Manager — F5’s full-proxy load balancer that distributes connections across real servers inside one data center.
GSLB
Global Server Load Balancing — spreading traffic across multiple, geographically separate data centers by controlling DNS answers.
Wide IP
The FQDN GTM is authoritative for; it maps the name to pools of virtual servers plus a load-balancing method.
Data Center / Server
A Data Center groups Server objects; each Server (a BIG-IP or third-party device) owns the virtual servers that become pool members.
Pool / Pool Member
A pool is an ordered set of virtual servers; a pool member references a GTM virtual server — i.e. an LTM VIP in a data center.
Listener
A specialized virtual server that catches DNS packets on UDP/TCP 53 — without it, GTM never answers.
iQuery / big3d
F5’s health protocol (TCP 4353): gtmd talks iQuery to big3d agents, which probe DCs and share health across the sync group.
Topology vs Global Availability
Topology = pick the DC nearest the client’s LDNS by region; Global Availability = always the first UP pool (ordered failover).
DNS TTL / Persistence
TTL controls how long LDNS resolvers cache a GSLB answer (failover speed); persistence pins an LDNS to one DC for a window.

📚 Sources

  1. F5 techdocs — About Global Server Load Balancing (BIG-IP DNS Concepts). techdocs.f5.com
  2. F5 techdocs — Communications Between BIG-IP GTM and Other Systems (iQuery, big3d, port 4353). techdocs.f5.com
  3. F5 techdocs — BIG-IP Global Traffic Manager: Load Balancing (methods, Topology, Global Availability, QoS). techdocs.f5.com
  4. F5 techdocs — BIG-IP DNS Configuration: Listeners, Wide IPs, Pools & object hierarchy. techdocs.f5.com
  5. F5 DNS Automation Demo — Creating a BIG-IP DNS Sync Group (iQuery mesh). f5-dns-automation-demo.readthedocs.io
  6. WorldTech IT — GTM vs LTM: Difference between F5 Global & Local Traffic Manager; NW Kings — F5 Interview Questions 2026.

What's next?

Cleared the F5 GTM round? Keep going — the interview-prep library covers F5 LTM, Palo Alto, Fortinet, Zscaler, Checkpoint and more, all in the same hands-on style.

Next · All interview lessons → Practice on exam.techclick.in →