Cloud Networking and Connectivity

Introduction and Context

Cloud computing has transformed networking from a largely hardware-defined discipline into a programmable, policy-driven capability. In a traditional data centre, network architecture is expressed through physical switches, routers, firewalls, leased circuits, and manually configured operating procedures. In a cloud environment, equivalent functions are implemented through virtual networks, software-defined routing, identity-aware security policies, managed DNS, elastic load balancers, content delivery networks (CDNs), and service-to-service connectivity mechanisms.

Cloud networking is not simply a virtual copy of a physical network. Cloud providers operate shared infrastructure, impose address-space and routing constraints, abstract hardware operations, and expose networking through APIs. Consequently, a cloud network architect must reason simultaneously about topology, security, availability, performance, cost, operations, and provider-specific constraints.

This chapter examines the design of virtual networks and subnets; routing and DNS; load balancing and content delivery; VPN and private connectivity; service meshes; and secure hybrid and multicloud topologies. It also considers governance, observability, failure domains, and contemporary developments such as zero-trust networking and programmable network automation.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. Design a virtual cloud network using address planning, subnet segmentation, routing, and security controls.

2. Distinguish public, private, isolated, regional, and zonal network components.

3. Select appropriate DNS, load-balancing, CDN, VPN, and private-connectivity services.

4. Analyse hybrid and multicloud connectivity patterns and their limitations.

5. Explain the role of service meshes in microservice communication and security.

6. Evaluate designs using availability, latency, throughput, security, operational complexity, and cost.

7. Apply governance and observability practices to cloud networking.

1. The Cloud Network Model

A cloud network is a logical communication domain implemented over provider infrastructure. Although terminology differs among providers, most platforms offer comparable abstractions:

• Virtual network: A tenant-controlled logical network, such as a virtual private cloud or virtual network.
• Address space: A set of private or public IP prefixes assigned to the network.
• Subnet: A subdivision of an address range, usually associated with a region, availability zone, or routing boundary.
• Network interface: A virtual attachment through which a compute or managed service communicates.
• Route table: A collection of destination prefixes and next hops.
• Security group or network security policy: Stateful or stateless traffic-control rules.
• Internet gateway: A provider-managed attachment enabling Internet connectivity for permitted resources.
• NAT gateway: A mechanism allowing private resources to initiate outbound Internet connections without accepting unsolicited inbound connections.
• Peering or transit service: A mechanism for connecting separate virtual networks.

A useful design principle is to separate three planes:

1. Data plane: The path carrying application traffic.

2. Control plane: The APIs and mechanisms that create routes, interfaces, policies, and services.

3. Management plane: Administrative access, configuration, monitoring, and governance.

Compromise of the management plane can be as damaging as compromise of the data plane. Therefore, administrative endpoints, automation identities, and control APIs require strong authentication, least privilege, logging, and separation of duties.

Shared responsibility and abstraction

The provider generally operates physical facilities, underlay networks, hypervisors, and managed service infrastructure. The customer remains responsible for logical address design, routing intent, access policies, workload configuration, identity, data protection, and often operating-system controls. The boundary varies by service. A managed load balancer may remove responsibility for patching the appliance, but it does not remove responsibility for listener rules, certificates, backend authorization, or logging.

2. Addressing and Subnet Design

IPv4 and IPv6

IPv4 uses 32-bit addresses, commonly written in dotted-decimal notation. IPv6 uses 128-bit addresses and provides a much larger address space, hierarchical allocation, and features supporting automatic configuration and traffic engineering. Cloud architectures increasingly use dual-stack designs because many enterprise applications and clients still depend on IPv4 while IPv6 adoption expands.

Private IPv4 address ranges commonly used for internal networks are:

• 10.0.0.0/8
• 172.16.0.0/12
• 192.168.0.0/16

Private addresses are not globally routable on the public Internet. They can nevertheless be routed across private links, VPNs, and cloud provider backbones. Address overlap is a major operational problem: two networks using the same prefix cannot normally be connected through ordinary layer-3 routing without translation or redesign.

CIDR and subnetting

Classless Inter-Domain Routing (CIDR) represents a network as an address and prefix length, such as 10.20.0.0/16. For IPv4, a prefix of length p leaves 32 − p host bits. The total number of addresses is:

N = 2^(32 − p)

where N is the total address count and p is the prefix length. In a conventional subnet, some addresses may be reserved for network, broadcast, gateway, or provider functions. Cloud platforms often reserve several addresses per subnet, so usable capacity must be checked against provider documentation rather than assumed from the theoretical count.

For example, a /24 contains 2^(32−24) = 256 IPv4 addresses. If a platform reserves five addresses, 251 remain usable. This calculation is illustrative; the exact reservation policy is provider-specific.

Subnet design should consider:

• current and forecast workload counts;
• growth in interfaces, containers, and managed services;
• separate failure domains;
• routing and security boundaries;
• future peering or VPN connections;
• shared services and inspection appliances;
• IP requirements of container orchestration systems;
• non-overlap with offices, data centres, partners, and acquisitions.

A common enterprise pattern allocates large, non-overlapping blocks to environments or regions, then divides them into workload, application, data, management, and inspection subnets. Excessive fragmentation creates routing and address-management complexity; insufficient segmentation increases blast radius and weakens policy clarity.

Public and private subnets

A subnet is not inherently public merely because it contains a public IP address. It is usually called public when its route table provides a path to an Internet gateway and its security policy permits appropriate traffic. A private subnet lacks direct inbound Internet routing. It may still provide outbound access through a NAT gateway or reach internal services through private routes.

A strongly controlled architecture places databases, queues, and administrative systems in private or isolated subnets. Public-facing entry points are limited to components such as CDN origins, web load balancers, API gateways, or bastion alternatives based on identity-aware access.

3. Routing and Network Segmentation

A router selects a next hop for a packet based on the most specific matching destination prefix. If multiple routes match, the route with the longest prefix is normally preferred. This principle explains why a route for 10.20.4.0/24 takes precedence over a broader route for 10.20.0.0/16.

Cloud routing commonly includes:

• local routes between subnets in a virtual network;
• default routes such as 0.0.0.0/0 for IPv4;
• routes to VPN tunnels or dedicated circuits;
• routes to peering or transit hubs;
• routes to inspection appliances;
• service-specific private endpoints.

Segmentation approaches

Network segmentation separates systems through subnets, virtual networks, route tables, or transit boundaries. Microsegmentation applies controls closer to workloads, such as workload identity, security groups, host firewalls, or service-mesh authorization. Effective security generally combines both. Network location alone is not a reliable identity signal because workloads move, scale, and share infrastructure.

A three-tier application may use:

• an edge subnet for public load balancers;
• an application subnet for compute or container workloads;
• a data subnet for databases and caches.

The route table and security policy should express only required flows. For example, application instances may connect to databases on a specific database port, while databases should not initiate connections to the public Internet. This is more defensible than permitting broad outbound and east-west access.

Centralized and distributed inspection

In centralized inspection, traffic passes through shared firewalls or network virtual appliances. This supports consistent policy and centralized logging but can introduce latency, bottlenecks, asymmetric routing, and cross-zone data-transfer costs. Distributed controls place security groups, host firewalls, and service policies near workloads, improving scalability but requiring stronger automation and policy governance.

Routing symmetry matters for stateful firewalls. If a request crosses one inspection device and the response returns through another, the second device may lack session state and drop the traffic. Designs must explicitly account for path symmetry, health checks, and failover behavior.

4. DNS in Cloud Architectures

The Domain Name System maps names to records such as A, AAAA, CNAME, MX, NS, and TXT. In cloud systems, DNS is also a traffic-management and service-discovery mechanism.

Important cloud DNS capabilities include:

• public authoritative DNS for Internet users;
• private hosted zones for internal names;
• split-horizon DNS, where internal and external users receive different answers;
• health-checked failover records;
• weighted, latency-based, geographic, or proximity routing;
• service discovery for dynamic workloads;
• DNSSEC signing for authenticity of DNS data where supported.

DNS is not an instant switch. Resolvers cache records according to their time-to-live (TTL), and clients or intermediate systems may cache beyond ideal operational expectations. A short TTL can accelerate changes but increases query load and may not eliminate stale answers. DNS-based failover therefore complements, rather than replaces, health-aware load balancing and application-level resilience.

Private DNS requires careful resolver architecture. Hybrid environments may use forwarding rules between on-premises resolvers and cloud resolvers. Namespaces should be designed to avoid collisions, and forwarding loops must be prevented. DNS logs can reveal service dependencies, data-exfiltration attempts, and misconfiguration, but they also contain sensitive operational information and should be governed accordingly.

5. Load Balancing and Content Delivery

Load balancing distributes requests across healthy backend resources. It improves availability, supports horizontal scaling, and can terminate TLS, apply routing rules, and provide observability.

Types of load balancers

• Layer 4 load balancers: Operate using transport information such as TCP or UDP. They offer high performance and preserve more application transparency but have limited application awareness.
• Layer 7 load balancers: Understand HTTP or HTTPS and can route by host, path, header, cookie, or method. They support application-aware routing, TLS termination, and web-application firewall integration.
• Internal load balancers: Provide private access to services.
• External load balancers: Accept traffic from the Internet or external networks.
• Global load balancers: Direct users among regions or sites, often using DNS, anycast, or provider edge infrastructure.

A load balancer is not automatically highly available. The design must distribute it across failure domains, configure meaningful health checks, avoid a single unhealthy dependency, and determine how existing connections behave during failure. Health checks should test the service’s ability to serve real requests, not merely whether a process is listening on a port.

A simple capacity approximation is:

C_total ≈ n × C_instance × u

where n is the number of healthy instances, C_instance is sustainable capacity per instance, and u is a utilization factor below 1 used to preserve headroom. This is an engineering estimate, not a universal law. Capacity must be validated through workload testing because CPU, memory, connection counts, storage, and downstream services may become bottlenecks first.

Content delivery networks

A CDN caches content at geographically distributed edge locations. It reduces latency for cacheable content, absorbs traffic spikes, and can provide TLS termination, DDoS protection, request filtering, and edge computing. Cache effectiveness depends on cache-control headers, object size, request distribution, invalidation strategy, and whether content is personalized.

Dynamic or sensitive content should not be cached indiscriminately. Authentication tokens, private responses, and user-specific data require explicit cache-key and authorization design. Origin protection is also important: an origin should accept traffic from the CDN or approved private paths rather than remaining broadly exposed.

6. VPNs and Private Connectivity

A virtual private network creates an encrypted tunnel over an untrusted or shared network. Site-to-site IPsec VPNs commonly connect enterprise networks to cloud virtual networks. Client VPNs connect individual users or devices.

VPN design decisions include:

• route-based versus policy-based configuration;
• static routes versus dynamic routing such as BGP;
• tunnel redundancy and endpoint diversity;
• encryption algorithms and key management;
• MTU and fragmentation behavior;
• failure detection and route convergence;
• overlapping address spaces;
• logging and compliance requirements.

VPNs are flexible and comparatively quick to deploy, but Internet paths can have variable latency and packet loss. Encryption adds processing overhead, and tunnel throughput may be limited by gateway capacity. Redundant tunnels should terminate on independent endpoints or zones where possible; two tunnels terminating on the same failure domain do not provide full resilience.

Dedicated private connectivity uses a provider or telecommunications circuit rather than the public Internet. It generally offers more predictable performance and may support higher throughput, but provisioning is slower, costs are higher, and the circuit remains dependent on physical facilities and carrier operations. A common best practice is to use dedicated connectivity for primary traffic and VPN tunnels as backup, provided routing and security policies are carefully coordinated.

Private service endpoints allow a workload to access a managed cloud service without traversing the public Internet. They reduce exposure and can simplify compliance, but they require endpoint policy, DNS integration, route design, and cost analysis.

7. Hybrid and Multicloud Topologies

Hybrid cloud

Hybrid networking connects private data centres, branch offices, and one or more cloud environments. Common topologies include:

1. Point-to-point: Each site connects directly to each cloud. It is simple at small scale but becomes operationally complex as connections multiply.

2. Hub-and-spoke: A central transit hub connects cloud networks and enterprise sites. It centralizes routing and governance but may become a bottleneck or shared failure domain.

3. Full mesh: Each network connects directly to others. It can reduce path length but increases configuration and troubleshooting complexity.

4. SD-WAN integrated: Policy-based overlays choose among Internet, private circuits, and cloud connections according to application needs.

The number of point-to-point links in a full mesh of n sites is:

L = n(n − 1)/2

This assumes one bidirectional logical connection between every pair and ignores redundancy. For five sites, L = 5×4/2 = 10 links. The formula illustrates why hub-and-spoke or managed transit becomes attractive as the number of networks grows.

Multicloud

Multicloud may be adopted for regulatory placement, resilience, acquisition integration, specialist services, or negotiation leverage. However, it does not automatically improve availability. Independent providers may share regional hazards, identity weaknesses, operational dependencies, or common software vulnerabilities.

Multicloud design should standardize portable principles—IPAM, identity, encryption, logging, policy-as-code, naming, and incident processes—while accepting that provider networking models differ. Attempting to force identical implementations can hide important semantic differences. A service available privately in one provider may require a different endpoint or routing pattern in another.

8. Service Meshes and Application Connectivity

A service mesh provides a dedicated infrastructure layer for service-to-service communication, commonly through sidecar proxies or node-level data-plane components and a control plane. It can provide:

• mutual TLS (mTLS);
• service identity and authorization;
• retries, timeouts, and circuit breaking;
• traffic splitting and canary releases;
• telemetry and distributed tracing;
• service discovery and policy enforcement.

The data plane handles application traffic; the control plane distributes configuration and identity material. A mesh does not replace cloud routing, subnet security, or a firewall. It primarily governs application-layer communication among participating services.

Retries require special care. Retrying non-idempotent operations can duplicate effects, while excessive retries can amplify overload. Timeouts should reflect end-to-end service-level objectives, and retry budgets should be bounded. mTLS protects traffic in transit and authenticates workloads, but it does not authorize every business action; application-level authorization remains necessary.

Service meshes introduce CPU and memory overhead, configuration complexity, certificate-management requirements, and new failure modes. They are most valuable when the number of services and communication policies justifies that complexity.

9. Security, Governance, and Observability

A secure cloud network follows defence-in-depth and zero-trust principles. Zero trust does not mean that network controls are irrelevant; it means that trust is not granted solely because a workload is inside a particular network. Access should be authenticated, authorized, continuously evaluated, and limited to required resources.

Core practices include:

• deny-by-default ingress and tightly controlled egress;
• least-privilege security groups and network policies;
• separate production, development, and security accounts or subscriptions;
• centralized but access-controlled flow logs;
• encryption in transit and, where appropriate, at application layers;
• protected management paths and identity-aware administration;
• infrastructure as code with peer review and policy checks;
• IP address management and documented ownership;
• route-change approval and drift detection;
• tested backup connectivity and disaster-recovery runbooks.

Network observability should combine flow logs, DNS logs, load-balancer logs, tunnel status, route tables, application metrics, traces, and synthetic probes. Useful indicators include latency, packet loss, throughput, connection errors, retransmissions, route convergence time, DNS failure rate, load-balancer backend health, and certificate expiry.

Governance must address data residency, lawful access, retention, encryption-key ownership, contractual responsibilities, and auditability. Network logs can contain personal data such as source addresses, hostnames, and query names. Collection and retention should therefore follow privacy law, organizational policy, and proportionality principles.

10. Design Method and Best Practices

A repeatable design method is more reliable than selecting services first.

1. Characterize workloads: Identify users, services, protocols, dependencies, traffic direction, latency sensitivity, and regulatory constraints.

2. Define failure domains: Determine required resilience across zones, regions, circuits, providers, and operational teams.

3. Plan addresses: Reserve non-overlapping ranges and document ownership, growth, and external connectivity.

4. Choose trust boundaries: Separate environments, data classifications, administrative paths, and shared services.

5. Design routes: Specify intended paths, inspection points, failover routes, and symmetry requirements.

6. Select connectivity: Compare Internet VPN, dedicated circuits, transit, peering, private endpoints, and service meshes.

7. Secure the design: Apply identity, encryption, segmentation, egress control, and policy-as-code.

8. Validate performance: Test throughput, latency, MTU, failure recovery, DNS behavior, and load characteristics.

9. Operationalize: Produce diagrams, inventories, alerts, runbooks, ownership records, and change procedures.

10. Review cost and sustainability: Include data transfer, NAT processing, transit, inspection, logging, and idle capacity costs.

A design should be judged not only by whether packets can flow, but also by whether the flow is explainable, observable, authorized, resilient, and economically sustainable.

Applied Case: Illustrative Hybrid E-Commerce Platform

Background

Consider an illustrative retailer, Northstar Commerce, operating a customer-facing web platform in two cloud regions and retaining its inventory system in an enterprise data centre. The platform includes a web front end, order services, payment integration, analytics, and a relational inventory database.

Problem

The retailer experiences seasonal traffic peaks, requires low-latency customer access, must protect payment-related systems, and needs continued operation if one cloud region becomes unavailable. Its initial design uses overlapping private address ranges, a single VPN tunnel, public database endpoints, and manually configured firewall rules.

Analysis

The single tunnel is a connectivity and maintenance risk. Public database exposure increases attack surface. Overlapping addresses prevent straightforward routing to the data centre. Manual rules are difficult to audit, while a single regional load balancer cannot provide global failover. The organization also lacks flow visibility and tested recovery procedures.

Approach and Solution

Northstar first renumbers the cloud networks using non-overlapping regional blocks and records them in a central IP address-management system. Each region contains separate edge, application, and data subnets distributed across multiple availability zones. Public traffic terminates at a CDN and global traffic-management layer, which directs requests to regional application load balancers.

The inventory system is accessed through private connectivity. Two VPN tunnels on independent endpoints provide backup for a dedicated circuit. Dynamic routing advertises only approved prefixes. Private DNS zones resolve internal service names, while public DNS exposes only the CDN and approved APIs. Databases have no public addresses and accept traffic only from the order-service identity or security boundary.

Application services use a service mesh for mTLS, authorization, timeouts, and telemetry. Network policies remain in place as an additional boundary. Infrastructure is deployed through reviewed code, and flow, DNS, load-balancer, and application logs are sent to a protected monitoring platform.

Outcome

The revised architecture reduces public exposure, removes address overlap, supports regional traffic shifting, and provides multiple connectivity paths. During testing, the organization measures DNS-cache effects, circuit failure, zone loss, backend health failure, and database recovery. It discovers that an overly aggressive retry policy could overload the inventory service and adjusts retry budgets and timeouts.

Learning Points

The case demonstrates that cloud networking is an integrated system. Address planning affects hybrid connectivity; DNS affects failover; load balancing affects availability; service meshes affect application behavior; and governance determines whether the architecture remains secure after deployment. Redundancy must be tested rather than inferred from diagrams.

Challenges and Limitations

Cloud networking introduces several persistent difficulties:

• provider abstractions differ, reducing portability;
• data-transfer pricing can make apparently efficient paths expensive;
• dynamic infrastructure complicates inventory and policy review;
• managed services may conceal important failure modes;
• DNS caching limits the speed of some recovery strategies;
• encryption, inspection, and logging can add latency and cost;
• overlapping addresses constrain mergers and hybrid integration;
• centralized security appliances can create bottlenecks;
• service meshes improve control but add operational overhead;
• multicloud can multiply skills, tools, and incident complexity.

Emerging developments include IPv6-only or IPv6-preferred workloads, eBPF-based observability and policy enforcement, confidential and identity-aware networking, edge computing, programmable data planes, and automated intent-based network operations. Artificial intelligence can assist with anomaly detection, dependency mapping, capacity forecasting, and incident correlation. It should not be granted unrestricted authority to modify production routes or security policies without bounded permissions, human review, testing, and audit trails. Incorrect inferred dependencies or automated changes can create widespread outages.

Chapter Summary

Cloud networking provides programmable connectivity through virtual networks, subnets, routes, security policies, DNS, load balancers, CDNs, VPNs, private circuits, transit systems, and service meshes. Effective design begins with non-overlapping address planning and explicit trust and failure boundaries. Routing must account for longest-prefix behavior, inspection symmetry, failover, and operational visibility. DNS supports naming, discovery, traffic management, and hybrid resolution, but caching limits immediate control.

Load balancers distribute traffic and improve availability when deployed across independent failure domains with meaningful health checks. CDNs reduce latency and protect origins but require careful cache and privacy controls. VPNs offer flexible encrypted connectivity, while dedicated links provide more predictable performance at greater cost and provisioning effort. Hybrid and multicloud designs must address routing scale, address overlap, provider differences, and the false assumption that multiple providers automatically eliminate common failures.

Service meshes add workload identity, mTLS, authorization, traffic management, and telemetry, but complement rather than replace network controls. Zero-trust security, least privilege, policy automation, observability, tested recovery, and governance are essential. A professional network architecture balances technical performance with security, resilience, cost, compliance, and operational simplicity.

Key Terms

Virtual network: A tenant-controlled logical cloud network.

CIDR: A notation expressing an IP network and prefix length.

Subnet: A subdivision of an address space used for organization and routing.

Route table: Rules mapping destination prefixes to next hops.

Security group: A workload-associated traffic-control policy, commonly stateful.

NAT gateway: A service allowing private resources to initiate external connections.

Peering: A private connection between separate virtual networks.

Transit hub: A centralized routing service connecting multiple networks.

Private DNS: Name resolution restricted to internal networks or identities.

Split-horizon DNS: DNS providing different answers according to requester context.

Load balancer: A service distributing traffic among backend resources.

CDN: A geographically distributed caching and delivery system.

VPN: An encrypted network tunnel over an untrusted or shared network.

Dedicated connectivity: A private carrier or provider circuit to cloud infrastructure.

Service mesh: An infrastructure layer managing service-to-service communication.

mTLS: Mutual Transport Layer Security, authenticating both communication endpoints.

Zero trust: A security approach that continuously verifies identity and authorization.

Network observability: Collection and analysis of telemetry about network behavior.

Failure domain: A component or boundary whose failure can affect system availability.

Infrastructure as code: Declarative, reviewable management of infrastructure configuration.

Review Questions

Short Answer Questions

1. What is the difference between a public and a private subnet?

2. Why is non-overlapping address space important in hybrid cloud networking?

3. What functions can a cloud load balancer provide besides traffic distribution?

4. What is split-horizon DNS?

5. Why does a service mesh not replace network-layer security controls?

Long Answer Questions

1. Explain a systematic method for designing a secure virtual cloud network.

2. Compare VPN-based connectivity with dedicated private connectivity.

3. Discuss the architectural and operational trade-offs of centralized versus distributed network inspection.

4. Explain how DNS, load balancing, and CDNs can jointly support global application availability.

5. Analyse the benefits and limitations of hub-and-spoke, full-mesh, and multicloud network topologies.

Analytical / Application Questions

1. An organization has six independent networks and proposes a full-mesh design. Calculate the number of bidirectional logical links using L = n(n−1)/2 and recommend whether a transit hub should be evaluated.

2. Design a hybrid topology for an application whose public front end runs in two cloud regions while its database remains on premises. Identify address, routing, DNS, security, resilience, and observability requirements.

3. A microservice platform shows rising latency after enabling retries in its service mesh. Analyse possible causes and propose a method for setting timeouts, retry budgets, circuit breaking, and downstream capacity limits.

Multiple Choice Questions with Answers

Question 1

Which route is normally preferred when both 10.20.0.0/16 and 10.20.4.0/24 match a destination?

A. 10.20.0.0/16 because it is the broader route

B. 10.20.4.0/24 because it is the longest prefix

C. The route with the lower IP address

D. Both routes are always used equally

Correct Answer: B. 10.20.4.0/24 because it is the longest prefix

Question 2

How many total IPv4 addresses are in a /24 subnet before provider-specific reservations?

A. 24

B. 128

C. 256

D. 512

Correct Answer: C. 256

Question 3

What is a principal purpose of a NAT gateway?

A. To provide inbound public access to private databases

B. To allow private resources to initiate outbound connections

C. To replace all internal routing

D. To encrypt every application message end to end

Correct Answer: B. To allow private resources to initiate outbound connections

Question 4

Which technology is primarily intended to cache content near geographically distributed users?

A. CDN

B. BGP

C. IPsec

D. Service mesh

Correct Answer: A. CDN

Question 5

What is a major risk of stateful centralized inspection?

A. It prevents all logging

B. It can suffer from asymmetric routing and bottlenecks

C. It eliminates the need for route tables

D. It cannot inspect any traffic

Correct Answer: B. It can suffer from asymmetric routing and bottlenecks

Question 6

For five sites, how many bidirectional links are required by a full mesh using n(n−1)/2?

A. 5

B. 8

C. 10

D. 25

Correct Answer: C. 10

Question 7

Which capability is most directly associated with a service mesh?

A. Physical fibre installation

B. Workload mTLS and service-level traffic policy

C. Replacement of IP addressing

D. Assignment of public Internet addresses

Correct Answer: B. Workload mTLS and service-level traffic policy

Question 8

Why can DNS-based failover take longer than expected?

A. DNS cannot represent multiple addresses

B. Resolvers and clients cache records according to TTL and local behavior

C. DNS works only inside private subnets

D. Load balancers disable DNS updates

Correct Answer: B. Resolvers and clients cache records according to TTL and local behavior

Question 9

Which approach best reflects zero-trust networking?

A. Trust every workload inside the corporate network

B. Authorize access based only on source subnet

C. Continuously verify identity, context, and authorization

D. Disable encryption for internal traffic

Correct Answer: C. Continuously verify identity, context, and authorization

Question 10

What is a key advantage of dedicated private connectivity over an ordinary Internet VPN?

A. It always costs less

B. It generally offers more predictable network performance

C. It requires no routing configuration

D. It eliminates the need for redundancy

Correct Answer: B. It generally offers more predictable network performance