After a cutover, citizens cannot resolve the municipal portal hostname even though the application servers respond when reached by IP. What should the operations team investigate first?
Select an answer to reveal the explanation.
Short Explanation
If you can hit the portal by typing an IP but names bounce, the app is probably fine—DNS is the map that went missing. Check the hostname records and whether the new zone has actually spread yet.
Full Explanation
After a cutover, when citizens cannot resolve the municipal portal hostname even though application servers respond when reached by IP, the operations team should investigate DNS records, zone configuration, and propagation for the portal hostname first. Name resolution failures present as "the site is down" while origins remain healthy. Guest OS patch levels on the application VMs matter for hygiene but do not explain IP success with name failure. Object lifecycle rules on an evidence archive bucket are unrelated to portal DNS. Block volume IOPS limits on database disks would degrade data paths, not hostname resolution. Exam caveat: check both public authoritative records and any private/civic split-horizon zones; propagation delay and cached TTLs can confuse cutovers. Operational check: dig/nslookup the portal name from citizen-like resolvers, compare answers to the intended load balancer or CDN, fix records or delegation, flush caches if needed, and verify browsing by name before closing the cutover window. In municipal cloud operations, record the chosen control and the rejected alternatives in the change or incident ticket so future on-call staff understand which failure modes were avoided for city services. Re-validate after the next maintenance window that the same decision still holds under current provider limits, identity bindings, and application versions used by the civic platform team.