4. Cloud Network and Connectivity Security

Introduction and Context

Cloud security is often described in terms of identity, data protection, and workload hardening, but these controls operate within a network that determines how systems communicate. A poorly designed cloud network can expose management interfaces, permit unrestricted east–west movement, route sensitive traffic through untrusted paths, or make security monitoring ineffective. Network and connectivity security therefore provides the architectural foundation on which other cloud controls depend.

Cloud networks differ from traditional enterprise networks in several important ways. They are software-defined, API-driven, elastic, geographically distributed, and shared across many applications and accounts. Virtual machines, containers, serverless functions, managed databases, and third-party services may communicate through a combination of private networks, public endpoints, service endpoints, internet gateways, VPNs, and dedicated connections. In hybrid and multi-cloud environments, the challenge is not merely to connect networks but to connect them without weakening policy enforcement, visibility, resilience, or trust boundaries.

This chapter examines the security of virtual networks, subnets, routing, peering, private endpoints, VPNs, software-defined networking, DNS, firewalls, proxies, web application firewalls, distributed denial-of-service controls, and service meshes. It develops a Zero Trust perspective in which connectivity is granted according to verified identity, device or workload context, policy, and business necessity rather than network location alone.

Learning Objectives

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

1. Explain the architecture and security implications of cloud virtual networks, subnets, routing, and connectivity services.

2. Distinguish between internet-facing, private, hybrid, and multi-cloud communication patterns.

3. Design network segmentation and traffic-control policies consistent with Zero Trust principles.

4. Evaluate VPNs, private endpoints, peering, transit architectures, proxies, firewalls, WAFs, and service meshes.

5. Analyze DNS, routing, monitoring, and availability risks in cloud environments.

6. Apply these concepts to a secure hybrid-cloud design and identify common implementation failures.

7. Assess governance, compliance, automation, and emerging developments in cloud network security.

The Cloud Network as a Security Boundary

A cloud virtual network is a logically isolated network defined through software. It normally contains address ranges, subnets, route tables, network interfaces, security policies, and gateways. Isolation is logical rather than physical: the provider operates the underlying infrastructure, while the customer controls selected configuration layers. This shared-responsibility arrangement means that the provider secures the underlying networking fabric, but the customer remains responsible for addressing, routes, access rules, exposed services, and monitoring.

A subnet is a division of a virtual network address space. Subnets are commonly associated with availability zones or fault domains and may be classified as public, private, or isolated. These labels are design conventions rather than universal security guarantees. A subnet is not automatically public merely because it has an internet route, and a subnet is not automatically private merely because it lacks a public IP. Effective exposure depends on routing, address translation, interface policy, load balancer configuration, firewall rules, identity controls, and application behavior.

Security architecture should begin with trust and communication requirements rather than with arbitrary subnet labels. Typical trust zones include internet-facing services, application services, data services, administration, security tooling, backup systems, and shared infrastructure. Each zone should have a defined purpose, allowed communication paths, ownership, and monitoring requirements. A database subnet that accepts traffic from every application subnet is segmented geographically but not meaningfully isolated.

Addressing and Route Control

Address planning is a security and operational concern. Overlapping address ranges complicate hybrid connectivity, hinder incident investigation, and may force unsafe network address translation. Organizations should reserve non-overlapping ranges for cloud environments, on-premises networks, acquisitions, laboratories, and future expansion. IPv6 planning also deserves attention because dual-stack deployments can create an overlooked path around IPv4-only controls.

Routing determines where packets may travel. A route table typically contains destination prefixes and next-hop targets such as an internet gateway, NAT gateway, VPN tunnel, transit gateway, virtual appliance, or private service endpoint. A secure design follows least privilege in routing: a workload should receive only the routes necessary for its function. Default routes should not be distributed indiscriminately, and route propagation from VPN or transit systems should be reviewed as carefully as firewall rules.

A route is not an authorization decision by itself. Routing determines reachability; security groups, network ACLs, firewalls, application policies, and identity controls determine whether communication is permitted. Security failures often arise when engineers verify only one of these layers. A blocked route can prevent a connection even when a firewall permits it, while a valid route can expose a service if filtering is absent.

Segmentation and Zero Trust Connectivity

Traditional segmentation relied heavily on a trusted internal network and an untrusted external network. Cloud environments weaken this distinction because users, administrators, workloads, and services may operate from many locations. Zero Trust replaces implicit network trust with continuous verification. Its central question is not “Is the request inside the network?” but “Should this authenticated subject, workload, or service perform this action on this resource under these conditions?”

In practical terms, Zero Trust networking combines identity, device posture, workload identity, network context, application policy, and telemetry. Segmentation remains valuable, but it is one layer in a broader control system. A private IP address is not proof of trust, and a public endpoint is not necessarily unacceptable if it is strongly authenticated, monitored, and appropriately protected.

Microsegmentation applies fine-grained rules between workloads, applications, or processes. For example, an application service may be allowed to call a database only on a specific port using a service identity, while administrative access must pass through a controlled bastion or privileged access system. Rules should be explicit about source, destination, protocol, port, identity, environment, and purpose. Broad rules such as “allow the entire virtual network” are convenient but create excessive blast radius.

Segmentation must also account for management paths, backup traffic, observability agents, software updates, and emergency access. A design that blocks ordinary traffic but leaves unrestricted administrative access is not secure. Separate production, development, and testing environments should use distinct accounts or subscriptions, address spaces, credentials, and policy boundaries where practical.

Connectivity Patterns in Hybrid and Multi-Cloud Architectures

Cloud connectivity can be classified according to the exposure and trust relationship involved. Public connectivity uses internet-routable endpoints and requires strong edge protection. Private connectivity uses provider-managed private links or dedicated circuits. Encrypted overlay connectivity uses tunnels, commonly IPsec VPNs, across public or private transport. Service-to-service connectivity may use private endpoints, peering, transit hubs, or service meshes.

Peering and Transit Architectures

Virtual network peering creates a private connection between two virtual networks. It can provide low-latency communication but may introduce management complexity as the number of networks grows. A full mesh of many peerings becomes difficult to document, audit, and modify. Peering may also have restrictions concerning transitive routing, inspection, address overlap, and cross-region traffic.

A transit gateway or hub-and-spoke architecture centralizes connectivity between many networks. The hub can provide route control, firewall inspection, logging, and shared services. However, centralization creates concentration risk: a misconfigured route or unavailable hub can affect multiple environments. A mature design uses separate route domains, explicit attachments, resilient appliances, and change controls.

In multi-cloud environments, direct connectivity may be supplemented by an interconnection provider, software-defined wide-area networking, or encrypted tunnels. Architects must compare latency, bandwidth, provider dependency, encryption, routing control, operational ownership, and failure behavior. Multi-cloud does not automatically reduce risk. It may increase policy inconsistency, visibility gaps, and dependence on engineers who understand several provider-specific networking models.

VPNs and Dedicated Connectivity

Site-to-site VPNs create encrypted tunnels between a cloud network and an enterprise or partner network. They are flexible and relatively quick to deploy, but their performance depends on internet transport, tunnel capacity, encryption processing, and endpoint availability. Redundant tunnels, diverse termination points, health monitoring, and tested failover are essential for production use.

Client VPNs provide remote users with access to selected resources. They should not be treated as a substitute for application-level access control. Full network access through a client VPN can enlarge the attack surface, especially when endpoints are unmanaged or compromised. Identity-based access, device posture checks, short-lived credentials, privileged access workflows, and granular authorization are preferable.

Dedicated private connections can offer predictable performance and reduce exposure to the public internet, but they are not inherently trusted or encrypted. Physical or provider-managed private transport may still require encryption for sensitive information. Dedicated circuits also introduce provisioning delays, geographic dependencies, and possible single points of failure.

Private Endpoints and Service Exposure

Private endpoints allow a consumer network to reach a managed cloud service through a private interface or provider-controlled private connection. They reduce the need for public exposure and can support data-exfiltration controls. Nevertheless, private access must be governed by endpoint policies, resource policies, identity permissions, DNS resolution, and logging. A private endpoint that is reachable from an overly broad set of networks can become a hidden path to sensitive services.

Endpoint placement should reflect data classification and administrative boundaries. Organizations should maintain an inventory of private endpoints, owners, destinations, approved consumers, and associated policies. Unused endpoints should be removed, and access should be tested from both authorized and unauthorized network contexts.

DNS, Name Resolution, and Traffic Direction

DNS is a critical but frequently underestimated security control. It determines which service a user or workload reaches and can influence routing between public and private endpoints. Split-horizon DNS provides different answers depending on the requester’s network context; this is useful for directing internal users to private services while external users receive public addresses.

DNS security requires controlled zones, authenticated administration, logging, protected resolvers, and clear ownership. Common threats include unauthorized record changes, cache poisoning, domain takeover, malicious resolution, and data exfiltration through DNS queries. DNS filtering can block known malicious domains and enforce acceptable-use policies, but it should not be considered a complete malware control.

Cloud environments frequently use provider resolvers, centralized forwarding, private hosted zones, and on-premises DNS integration. Design teams must document query flow: where a workload sends a query, which resolver answers it, whether the answer is logged, and how failures affect application availability. DNS security controls should be tested during disaster recovery exercises because resolver failure can make healthy applications unreachable.

Firewalls, Security Groups, Proxies, and WAFs

Cloud firewalls may exist as distributed controls attached to interfaces, stateful network firewalls, centralized inspection appliances, or host-based firewalls. Distributed security groups are often close to workloads and can scale automatically, while centralized firewalls are useful for consistent inspection, egress control, and inter-network policy. A layered model is generally stronger than reliance on a single control.

Stateful controls track connection state and can allow return traffic automatically. Stateless network ACLs require explicit rules for both directions and may be useful for coarse subnet-level restrictions. The choice should reflect provider behavior, scale, operational skill, and inspection requirements. Rules should be ordered, documented, reviewed, and associated with owners and expiration dates where appropriate.

Proxies mediate communication between clients and destinations. Forward proxies can control outbound web access, inspect requests according to policy, and provide logging. Reverse proxies conceal origin services, terminate TLS, apply rate limits, and route requests to backend applications. Egress proxies are particularly valuable in Zero Trust architectures because they prevent workloads from making arbitrary outbound connections. Their design must account for certificate validation, privacy, performance, and bypass attempts.

A web application firewall protects HTTP-based applications against attacks such as injection, malicious input, protocol abuse, and some automated threats. A WAF is not a replacement for secure coding, authentication, authorization, patching, or API security. Rules must be tuned to application behavior; excessively permissive rules create gaps, while excessively aggressive rules can block legitimate users. WAF logs should be correlated with application, identity, and threat-intelligence data.

DDoS Protection and Availability Engineering

Distributed denial-of-service attacks attempt to exhaust bandwidth, connection capacity, application resources, or expensive backend operations. Cloud providers commonly offer network-level absorption, traffic scrubbing, rate limiting, and integration with edge delivery services. These controls reduce risk but do not eliminate application-layer attacks, in which apparently valid requests consume disproportionate resources.

A resilient design uses caching, autoscaling with safeguards, request throttling, queueing, circuit breakers, origin protection, and economical failure modes. Public endpoints should expose as little backend information as possible. Administrative services should not share the same unrestricted edge path as public application traffic. DDoS response plans should define thresholds, provider escalation procedures, communications, evidence collection, and post-incident review.

Availability and security must be balanced. Automatic scaling can absorb a traffic surge but may generate uncontrolled cost or amplify attacks against downstream systems. Rate limits should therefore be based on identities, clients, endpoints, and business functions rather than only source IP addresses, which attackers can distribute across many sources.

Service Meshes and Workload-to-Workload Security

A service mesh provides a dedicated communication layer for distributed services, commonly through sidecar proxies or node-level data-plane components controlled by a management plane. It can provide mutual TLS, service identity, traffic authorization, retries, timeouts, telemetry, and controlled traffic shifting.

Mutual TLS authenticates both communicating services and encrypts traffic in transit. When combined with workload identities and authorization policies, it supports stronger east–west security than IP-based rules alone. A policy may specify that a payment service can call an account service for a defined operation, while a logging service may receive events but cannot invoke business APIs.

Service meshes introduce complexity. Misconfigured policies can interrupt applications; an exposed management plane can affect many services; sidecar resource consumption can be significant; and teams may mistakenly assume that mesh controls secure user-to-edge traffic or non-mesh workloads. Mesh policy should complement, not replace, network segmentation, secure application design, and identity governance.

A Practical Design Method

A disciplined design process begins with an inventory of applications, data flows, identities, dependencies, and regulatory requirements. The design team then classifies communications as north–south traffic, which crosses an organizational or internet boundary, and east–west traffic, which occurs among internal workloads. Both directions require explicit policy.

The following sequence is useful:

1. Define trust zones, business ownership, data classifications, and availability requirements.

2. Create a non-overlapping address and naming plan.

3. Map required flows, including administration, monitoring, backup, updates, and third-party dependencies.

4. Select private, encrypted, or public connectivity according to risk and operational need.

5. Establish route domains and ensure that transitive paths are intentional.

6. Apply identity-aware firewall, endpoint, proxy, WAF, and service-mesh policies.

7. Control egress and document approved destinations.

8. Centralize logs for DNS, flow records, firewall decisions, VPNs, WAFs, and gateways.

9. Test failure, bypass, unauthorized access, and recovery scenarios.

10. Automate policy validation and continuously review unused or overly broad rules.

Infrastructure as Code supports repeatability and peer review, but automation can also reproduce an insecure configuration at scale. Policy-as-code tools can detect open administrative ports, unrestricted routes, public storage dependencies, overlapping ranges, and missing logging before deployment. Continuous compliance should evaluate actual deployed state rather than relying only on source templates.

Illustrative Case Study: A Hybrid Retail Platform

Background

A fictional retailer, Northstar Commerce, operates an online store in a public cloud while its inventory and financial systems remain in two corporate data centres. The company plans to place customer-facing services, order processing, and analytics in the cloud. Customer information and payment-related records require strong access controls and auditable data flows.

Situation and Problem

The initial design uses one virtual network with broad peering to the data centres. Application servers have public IP addresses for convenience, and security rules allow traffic from the entire virtual network. Developers use a client VPN that provides broad access to production. DNS records are managed separately by cloud and corporate teams, and no central flow-log or firewall analysis exists.

An assessment identifies several risks: compromised public servers could move laterally to databases; the VPN creates excessive administrative reach; overlapping address ranges complicate routing; DNS inconsistencies may direct internal traffic to public endpoints; and the absence of centralized logs would delay incident response.

Analysis

The principal problem is not a single missing firewall rule but an architecture based on network location as a proxy for trust. Public exposure, broad routes, permissive security groups, and uncontrolled administrative access combine to create a large blast radius. The hybrid connection also lacks clear route domains and resilient inspection points.

Approach and Solution

Northstar redesigns the environment using separate production, development, security, and shared-services accounts. Public traffic terminates at a resilient edge layer containing a load balancer, DDoS controls, and WAF. Application services reside in private subnets, while databases are placed in isolated subnets with no direct internet route.

A transit hub connects cloud segments and corporate sites through redundant encrypted VPNs. Route tables restrict each environment to required prefixes, and a centralized firewall inspects selected inter-zone and outbound flows. Private endpoints are used for approved managed services. Egress is routed through controlled proxies, with allowlists for update repositories and business APIs.

Corporate and cloud DNS are integrated through controlled forwarding and split-horizon zones. Administrative access uses identity-aware privileged access and short-lived credentials rather than broad VPN reach. Service-to-service communication uses workload identities and mutual TLS for sensitive application flows. Flow logs, DNS logs, firewall decisions, VPN events, WAF events, and identity records are sent to a central analytics platform.

Infrastructure as Code defines networks and policies, while automated checks reject public management interfaces, unrestricted administrative ports, missing flow logs, and unauthorized route propagation. The security team performs attack-path reviews and tests tunnel failure, DNS failure, firewall failure, and unauthorized east–west access.

Outcome

The redesigned architecture reduces direct exposure, limits lateral movement, makes administrative actions attributable, and improves visibility across hybrid paths. It also reveals operational costs: the central firewall requires capacity planning, DNS integration needs clear ownership, and application teams must maintain service identities and policy definitions.

Learning Points

The case demonstrates that secure connectivity is an architectural discipline rather than a collection of isolated products. Private networking is valuable but does not establish trust. Segmentation must be combined with identity, least-privilege routes, controlled egress, resilient inspection, centralized telemetry, and tested recovery procedures.

Challenges, Risks, and Common Mistakes

Cloud network security is difficult because providers implement similar concepts with different names, defaults, and limitations. Engineers may assume that a rule is stateful when it is not, that peering supports transitive routing when it does not, or that a private endpoint is reachable from all intended locations. Provider documentation and controlled testing are essential.

Common mistakes include using one large network for every environment, allowing unrestricted east–west traffic, publishing management interfaces, ignoring IPv6, permitting unrestricted outbound traffic, failing to monitor DNS, and creating ad hoc peerings. Other failures arise from stale rules, undocumented exceptions, unused public IP addresses, untested VPN failover, and overreliance on IP allowlists.

Centralized security can become a bottleneck or single point of failure. Distributed controls can become inconsistent. Encryption can create inspection challenges, while inspection can create privacy and performance concerns. Organizations must make these trade-offs explicit and use resilient, documented architectures rather than assuming that a product automatically resolves them.

Governance, Ethics, and Professional Responsibility

Network telemetry may contain personal data, employee identifiers, URLs, or sensitive business information. Logging must follow applicable privacy obligations, retention policies, access restrictions, and data-minimization principles. TLS inspection requires particular care because it may expose confidential communications and create obligations to notify, justify, and protect the inspection process.

Security policies should be proportionate and risk-based. Excessive monitoring, permanent administrative access, or broad content interception can undermine privacy and organizational trust. Change approval should not prevent emergency action, but emergency changes require retrospective review. Network configurations should have accountable owners, documented purpose, review dates, and evidence of testing.

Compliance frameworks may require network segmentation, encryption in transit, vulnerability management, logging, access control, and incident response. Compliance does not replace threat modelling. A technically compliant network may still permit excessive lateral movement or fail under realistic attack conditions.

Emerging Developments

Cloud networking is increasingly influenced by secure access service edge architectures, zero-trust network access, cloud-native firewalls, confidential workloads, and identity-based network policy. Network detection and response systems use flow data, DNS behavior, and workload telemetry to identify unusual paths or exfiltration patterns. Machine learning can assist anomaly detection, but it requires quality data, explainable investigation workflows, and safeguards against alert overload.

eBPF-based observability and enforcement can provide detailed visibility into workload communication, although deployment requires careful kernel, privilege, and performance management. Kubernetes networking is also moving toward richer identity-aware policies and encrypted service communication. As organizations adopt AI workloads, they must protect model endpoints, vector databases, inference APIs, and high-bandwidth data pipelines from unauthorized access and resource exhaustion.

The durable principle behind these developments is not adoption of a particular product. It is the continuous verification of communication, explicit authorization, observable enforcement, resilient design, and rapid correction of unintended exposure.

Best Practices

• Use non-overlapping address spaces and maintain an authoritative network inventory.
• Separate environments and trust zones through accounts, subscriptions, projects, route domains, and policy boundaries.
• Treat routing as a security decision and review propagated routes.
• Prefer private connectivity for sensitive services, but apply identity and authorization controls to private paths.
• Use layered controls: workload policies, network firewalls, proxies, WAFs, endpoint policies, and service identities.
• Restrict and monitor egress as carefully as ingress.
• Protect DNS administration, integrate resolution deliberately, and log important queries.
• Design VPNs, transit hubs, firewalls, and DNS with redundancy and tested failover.
• Centralize and correlate network, identity, application, and security telemetry.
• Automate deployment and policy validation, while reviewing actual runtime state.
• Remove unused rules, routes, endpoints, interfaces, and public addresses.
• Test segmentation, bypass paths, disaster recovery, DDoS response, and unauthorized east–west movement.

Chapter Summary

Cloud network security establishes the communication boundaries within which cloud workloads operate. Virtual networks, subnets, routes, gateways, peerings, VPNs, private endpoints, firewalls, proxies, WAFs, DNS, DDoS controls, and service meshes each address different aspects of reachability, authorization, confidentiality, availability, and visibility. Secure architecture combines these mechanisms rather than treating any one as sufficient.

Zero Trust requires explicit, continuously evaluated authorization based on identity, workload context, device posture, policy, and telemetry. Segmentation reduces blast radius, while least-privilege routing and controlled egress reduce unintended paths. Hybrid and multi-cloud designs demand careful attention to address planning, route propagation, resilience, provider differences, and operational ownership. Automation, centralized monitoring, policy-as-code, and regular testing make security controls more consistent, auditable, and adaptable.

Key Terms

Virtual network: A logically isolated, software-defined cloud network.

Subnet: A division of a network address range used to organize workloads and routing.

Route table: A set of rules determining the next hop for network destinations.

Security group: A usually stateful, interface- or workload-associated traffic control.

Network ACL: A subnet-level traffic filter that may operate statelessly.

Peering: A private connection between two virtual networks.

Transit gateway: A hub that connects multiple networks and controls inter-network routing.

VPN: An encrypted tunnel across a public or shared network.

Private endpoint: A private interface or connection to a managed service.

Zero Trust: A security approach that requires explicit, continuous verification rather than implicit network trust.

Microsegmentation: Fine-grained separation and authorization among workloads or services.

DNS: The naming system that maps domain names to network destinations.

Forward proxy: An intermediary controlling client outbound requests.

Reverse proxy: An intermediary receiving client requests before forwarding them to backend services.

WAF: A web application firewall that filters and protects HTTP-based applications.

DDoS: A distributed denial-of-service attack intended to exhaust network or application resources.

Service mesh: A communication layer providing service identity, encryption, policy, and telemetry.

Egress filtering: Control and monitoring of traffic leaving a network or workload.

North–south traffic: Traffic crossing an external, organizational, or internet boundary.

East–west traffic: Traffic exchanged among internal workloads or services.

Review Questions

Short Answer Questions

1. Why is a private subnet not automatically a trusted security zone?

2. What is the difference between routing and authorization?

3. State two security benefits and one limitation of private endpoints.

4. What role does DNS play in cloud network security?

5. Why should egress traffic be controlled in a Zero Trust architecture?

Long Answer Questions

1. Explain how Zero Trust changes the design of cloud network segmentation.

2. Compare peering, transit gateways, VPNs, and dedicated private connectivity for hybrid environments.

3. Discuss the complementary roles of security groups, network firewalls, proxies, and WAFs.

4. Explain how service meshes support workload-to-workload security and identify their limitations.

5. Describe a complete method for designing a secure multi-cloud connectivity architecture.

Analytical / Application Questions

1. An organization allows all traffic within one virtual network and gives developers broad production VPN access. Analyze the risks and propose a redesigned access and segmentation model.

2. A cloud application remains available during a DDoS event, but costs increase sharply and backend databases become overloaded. What controls should be introduced, and why?

3. Two cloud networks have overlapping address ranges and must exchange sensitive data. Evaluate possible architectural responses and explain the security and operational trade-offs.

22. Multiple Choice Questions with Answers

Question 1

Which statement best describes the relationship between routing and authorization in a cloud network?

A. Routing alone determines whether a connection is permitted.

B. Authorization is unnecessary when traffic uses private addresses.

C. Routing determines reachability, while additional controls determine whether communication is allowed.

D. Firewalls determine routes but do not affect authorization.

Correct Answer: C. Routing determines reachability, while additional controls determine whether communication is allowed.

Question 2

A company wants to prevent a compromised application server from making arbitrary outbound connections. Which control most directly addresses this risk?

A. Unrestricted internet gateway access

B. Controlled egress through a proxy or firewall

C. Additional public IP addresses

D. A larger subnet

Correct Answer: B. Controlled egress through a proxy or firewall

Question 3

What is a major architectural risk of creating a full mesh of virtual-network peerings?

A. Peering always encrypts application data automatically.

B. The number of relationships becomes difficult to manage and audit.

C. Peering prevents all private communication.

D. Peering eliminates the need for route tables.

Correct Answer: B. The number of relationships becomes difficult to manage and audit.

Question 4

Which design most closely follows Zero Trust principles?

A. Allow all traffic originating inside the corporate network.

B. Trust workloads solely because they use private IP addresses.

C. Authorize service requests using identity, context, and least-privilege policy.

D. Permit broad VPN access to simplify administration.

Correct Answer: C. Authorize service requests using identity, context, and least-privilege policy.

Question 5

What is the primary purpose of a web application firewall?

A. To replace secure application coding practices

B. To filter and inspect HTTP-based application traffic

C. To allocate private IP addresses

D. To establish physical data-centre connectivity

Correct Answer: B. To filter and inspect HTTP-based application traffic

Question 6

A private endpoint is reachable from every environment in an organization. What is the most important security concern?

A. Private endpoints cannot support logging.

B. Private connectivity automatically disables encryption.

C. An overly broad network path may expose a sensitive service to unauthorized consumers.

D. Private endpoints always increase public internet exposure.

Correct Answer: C. An overly broad network path may expose a sensitive service to unauthorized consumers.

Question 7

Which service-mesh capability most directly supports mutual service authentication?

A. Workload identity combined with mutual TLS

B. A larger CIDR block

C. A public DNS record

D. An internet gateway

Correct Answer: A. Workload identity combined with mutual TLS

Question 8

Why can unrestricted automatic scaling worsen the consequences of an application-layer DDoS attack?

A. Scaling prevents all requests from reaching the application.

B. Scaling may consume significant resources and cost while the attack continues.

C. Scaling disables WAF inspection.

D. Scaling removes all route tables.

Correct Answer: B. Scaling may consume significant resources and cost while the attack continues.

Question 9

Which practice best reduces the risk of hybrid-cloud route misconfiguration?

A. Allowing all route propagation by default

B. Using overlapping address ranges for flexibility

C. Defining explicit route domains and reviewing propagated prefixes

D. Replacing all private links with public endpoints

Correct Answer: C. Defining explicit route domains and reviewing propagated prefixes

Question 10

Why is centralized network security inspection potentially a risk as well as a benefit?

A. It cannot provide logging.

B. It may become a bottleneck or single point of failure if not made resilient.

C. It always prevents segmentation.

D. It eliminates the need for application policies.

Correct Answer: B. It may become a bottleneck or single point of failure if not made resilient.