Name the layer before proposing a product
A cloud application is reached through several decisions that are easy to collapse into a single word: connectivity. A person types a name, a resolver obtains an answer, and the client attempts to reach the resulting address. A route and the relevant access controls must permit the connection. The application then applies its own authentication and authorization. A failure at any one stage can look like an unavailable application to a user. For a business decision, ask what has actually been observed before buying another service. A healthy server and a successful DNS lookup are useful pieces of evidence, but neither establishes the whole user journey.
DNS provides an answer, not a network path
The Domain Name System connects human-readable names with information such as an IP address. A record is not the same object as the destination it names. Cloud DNS can host public or private DNS namespaces. A public answer can be visible beyond a private network, while a private zone is intended for the configured private resolution context. Visibility and reachability are separate questions: a user might obtain an address that the user cannot reach. Cached answers can also continue to describe a previous record until their applicable lifetime has elapsed. Investigate both the authoritative configuration and the resolver actually used by the client.
Private and public addresses express different reachability arrangements
Google Cloud resources can have internal or external IP addresses. An internal address is used within the appropriate private network arrangement; the fact that an authorized user knows it does not establish a route from that user location. An external address can support communication involving the internet, subject to the actual resource configuration and access rules. Static and ephemeral describe address allocation behavior, not a privacy guarantee. A reserved static external address does not become private because it is stable. A private DNS record does not automatically create a VPN, an interconnect, a firewall rule or a database account.
Worked example: test the observation that differs
A fictional distributor moves an application to a new address. A permitted network probe from the office succeeds at that address, but the office resolver still supplies the previous address for the application name. First record exactly what the probe establishes: connectivity for that source, destination and tested protocol. Then compare the name response. Inspect the record and cached answer rather than immediately changing the tested network route. Do not infer that a direct address probe validates browser certificates or the complete application login. Those are separate tests if the user journey still fails after the name-resolution mismatch is corrected.
Keep security and availability claims bounded
Making a name publicly resolvable does not authorize application use. Conversely, configuring a private name alone is not a complete security architecture. Identify the intended sources, destinations, traffic and identity controls, and test the complete authorized workflow. When the business requirement says a database must stay on private addressing, an answer that merely gives it a static public address changes the requirement. When the requirement calls for an encrypted approved connection, a routing preference alone does not demonstrate that the connection has been established. Record assumptions instead of treating a product label as a guarantee.
Transfer check: diagnose without overclaiming
An employee can resolve a private database name but cannot connect from a new office. What remains unproven? The appropriate private connection, routes and access rules from that office, followed by the application-level authorization. Now reverse the evidence: a permitted network probe succeeds, but the name lookup returns the wrong address. Investigate resolution first. Explain why these cases justify different next checks even though both users report that the database is unavailable. Use the linked practice and the request-path article to state what each test establishes and what it leaves unknown.
A business application has moved to a new IP address. A network probe from an authorized office reaches the new address, but employees using the application name still obtain the old address from their resolver. Routing, access policy and the destination service have already passed that probe. Which investigation most directly follows the remaining evidence?
- The observations distinguish resolving a name from reaching its resolved address. The direct network probe establishes a working path for its tested source and destination, while the resolver still supplies an old address for the application name. Inspect the authoritative record and relevant cached answer, including its lifetime, before changing an already tested route or access rule. This is a targeted investigation, not a claim that every application or security layer has been validated.
Compare the other answer choices
Changing a route that already carries the probe does not explain why the name lookup returns a different destination address.
An additional tunnel addresses connectivity design, but the stated connectivity probe succeeded and the mismatch is visible in the name answer.
The tested firewall rule permits the relevant probe. Editing it does not update the DNS answer or invalidate an old cached record.
Try it, then explain it.
Complete a short set without looking at the example. After each answer, explain which evidence or rule supports your decision and why the alternatives do not fit.
Sources & authorship
Original OpenExam explanations and examples. References support the concepts; they are not the source of copied questions. Independent educator review is pending.
Cloud DNS overviewIP addressesGeneral DNS overview