CCNA Pcne Designing Network Questions

It uses two VPN tunnels to separate on-premises peer gateways with Cloud Router and BGP. BGP automatically handles failover by withdrawing routes from the failed tunnel and advertising routes via the healthy tunnel, ensuring traffic fails over without manual intervention. This meets the high availability and dynamic routing requirements specified in the question.

Global External HTTP(S) Load Balancers use Google's frontend (proxying) IP ranges to send health checks to backends. The backend must allow inbound traffic from these specific health check IP ranges (e.g., 35.191.0.0/16 and 130.211.0.0/22) to receive health probes; otherwise, the load balancer will mark the backend as unhealthy and stop forwarding traffic.

Cloud DNS inbound server policy enables on-premises DNS resolvers to forward queries to Cloud DNS for resolution of private zones. This is the appropriate feature for on-premises to GCP DNS resolution.

A global external HTTP(S) load balancer requires a single backend service that can span multiple regions. By adding one instance group from us-east1 and another from europe-west1 to the same backend service, the load balancer automatically routes traffic to the closest healthy backend based on the client's geographic location and the load balancer's anycast IP. This configuration leverages Google's global network infrastructure for optimal latency and failover.

Private managed zones are associated with one or more VPC networks and are used for internal DNS resolution. Public managed zones are for internet-facing DNS.

VPC Network Peering is designed to connect VPCs within the same organization (or across different organizations) without requiring a VPN or gateway. It allows private RFC 1918 IP communication between VPCs, and when both VPCs belong to the same organization, the peering setup is straightforward and does not involve cross-organization trust policies. This is a fundamental use case for peering in Google Cloud.

The Compute Network User role (roles/compute.networkUser) grants permissions to use existing networks and subnets (create VMs, attach disks, etc.) but not to delete or modify network resources.

Correct matches: Cloud Load Balancing distributes traffic, Cloud CDN caches content, Cloud DNS resolves domain names. Common confusions: Cloud NAT is for internet access without external IPs, Virtual Private Cloud provides isolated networks, and Cloud Interconnect connects on-premises to Google Cloud.

Dedicated Interconnect with two 10 Gbps circuits to different edge locations meets the 10 Gbps bandwidth requirement and provides high availability through diverse physical paths. Cloud VPN maxes out at 3 Gbps per tunnel, Direct Peering does not offer SLA-backed bandwidth or support for 10 Gbps single connections, and Partner Interconnect typically caps at 1 Gbps per VLAN attachment.

DNS peering allows a private zone in one project to be shared with other projects for DNS resolution.

Custom learned routes allow you to specify which prefixes are advertised to GCP via BGP.

Auto mode VPCs automatically create subnets in each region with predetermined IP ranges, simplifying initial setup. Custom mode VPCs require manual subnet creation.

Auto mode VPCs automatically create subnets in each region and manage IP ranges, reducing management overhead. Custom mode requires manual subnet creation.

It provides true high availability by using two Cloud VPN gateways in different regions, each with a tunnel to a different on-premises appliance. This design ensures that if one region or gateway fails, traffic can still flow through the other region, meeting the requirement for high availability. Using separate Cloud Routers allows for dynamic routing with BGP, enabling automatic failover and load balancing across the two tunnels.

Shared VPC allows a host project to share subnets with service projects. IAM on shared subnets can be delegated to service project administrators, and VMs in service projects can use internal IPs from the shared subnets.

Best practices: Use RFC 1918 private ranges, avoid overlapping with on-premises, plan secondary ranges for GKE (pods and services), and use non-overlapping ranges for future expansion.

Cloud Router can advertise custom routes, and BGP allows setting MED values to influence route priority.

For 99.99% SLA with Dedicated Interconnect, you need two links in different edge availability domains, two VLAN attachments, and BGP sessions with Cloud Router.

Auto mode VPCs automatically create a subnet in each region with predefined IP ranges, reducing manual effort. Custom mode requires manual subnet creation.

Auto mode VPCs create subnets in all regions automatically and expand to new regions as they become available.

To use a shared subnet, the host project must grant the service project's Compute Engine service account the necessary IAM role on the subnet. The service project team must also have permissions to use the subnet.

VPC Network Peering allows direct connectivity between two VPCs with non-transitive peering. It supports dynamic routes via custom route exchange and does not use the internet.

A private managed zone can be associated with one or more VPCs in the same project. By associating the zone with all VPCs that need resolution, instances in those VPCs can resolve the zone without additional peering.

VPC Network Peering requires that the subnets in the two VPCs do not overlap. Since both VPCs use the same CIDR block (10.0.0.0/16), peering will fail due to subnet overlap.

The `gcloud compute nat-gateways list-mappings` command only displays NAT mappings for instances that currently have active outbound connections traversing the Cloud NAT gateway. Cloud NAT uses dynamic port address translation (PAT) and only creates a mapping entry when an instance sends traffic that requires source NAT. Instances without active sessions will not appear in the listing, even though they are configured to use the NAT gateway.

Google Cloud encrypts all traffic between VMs at the hypervisor level, regardless of region, using application-layer encryption (e.g., TLS) and network-layer encryption (e.g., IPSec) by default. This encryption is transparent, always-on, and does not require any configuration, making option B the correct answer. The encryption covers all VM-to-VM traffic within the same VPC or across VPCs, including inter-region communication.

To achieve a 99.99% SLA with HA VPN, you need at least two tunnels, each with a separate external IP on the GCP side, and the on-premises gateway must have two distinct public IP addresses. Unique pre-shared keys per tunnel are recommended for security but are not a requirement for the SLA.

Shared VPC allows IAM permissions on individual subnets. You can grant the compute.subnetUser role on a specific subnet to a service project.

GKE uses secondary IP ranges for pods and services. You specify these ranges when creating the subnet.

When creating a subnet with secondary IP ranges, the '--secondary-range' flag is used to specify the name and range for pods (or services). The CLI command allows multiple secondary ranges.

Inbound DNS forwarding requires a Cloud DNS inbound server policy that specifies the VPC and the IP addresses of the on-premises DNS resolvers.

VPC-native clusters assign alias IP ranges to pods directly from the VPC subnet's secondary CIDR ranges. To enable on-premises routing to these pods, the pod IP ranges must be advertised over the Cloud Router BGP session to the on-premises router. This ensures the on-premises network learns the routes to the pod CIDRs and can forward traffic back through the Cloud VPN tunnel.

Dedicated Interconnect provides direct, private connections between your on-premises network and Google Cloud, supporting up to 10 Gbps per circuit. By using two 10 Gbps connections in an active-active or active-passive configuration, you can achieve the required 20 Gbps aggregate bandwidth and meet the 99.99% SLA, as Google guarantees this SLA when you have at least two redundant connections.

The on-premises firewall is likely configured with an idle timeout that terminates TCP sessions when no traffic is exchanged for a certain period. After the instances reboot, they initiate new connections that work briefly, but once the session becomes idle (e.g., no keepalives or application traffic), the firewall drops the stateful session, causing connectivity loss. The Cloud VPN and BGP session remain up, indicating the issue is at the application or firewall layer, not the tunnel or routing.

Network Connectivity Center (NCC) provides a hub-and-spoke model for connecting on-premises networks and VPCs, reducing configuration complexity.

Cloud Router requires a unique ASN (typically a private ASN from 64512-65534) that does not conflict with the on-premises ASN. The default ASN for Cloud Router is 64512, but it must be changed if the on-premises ASN is the same. The engineer should use a different private ASN, such as 64513.

Network Connectivity Center (NCC) is designed for hub-and-spoke topologies, connecting on-premises networks and VPCs through a hub.

Cloud Router must advertise all subnets visible to it to ensure that the on-premises router learns the IP prefixes for Google Cloud services (e.g., Google APIs, GKE control planes) that are reachable via Private Google Access or Private Service Connect. By default, Cloud Router only advertises VPC subnet routes; enabling 'Advertise all subnets visible by the Cloud Router' includes custom IP ranges and service producer ranges, allowing the on-premises network to route traffic to those services using the advertiser's IP addresses.

IP addresses must be unique across connected networks; using RFC 1918 private ranges is standard; avoiding overlapping with on-premises and peered VPC ranges is critical.

VPC peering is non-transitive and directly connects two VPCs. Shared VPC is transitive; VPN and Interconnect are for hybrid connectivity.

HA VPN uses two external IP addresses on a single gateway, one in each zone. One gateway supports two IPs and four tunnels, meeting the requirement with 99.99% SLA.

VPC peering allows two VPCs to communicate using internal IPs without a VPN or internet gateway, as long as there is no IP overlap.

Dedicated Interconnect provides a direct, private physical connection between an on-premises data center and Google Cloud, supporting speeds of 10 Gbps or 100 Gbps per link. It offers a 99.99% SLA when configured with redundant links (two circuits) and can scale beyond 10 Gbps by adding additional 10 Gbps or 100 Gbps connections, meeting the requirement for high bandwidth and high availability.

DNS peering allows Cloud DNS private zones from one project (the host project) to be resolved by VPCs in other projects (service projects) without requiring Shared VPC or network connectivity. By setting up a DNS peering zone in each service project that targets the host project's private zone, DNS queries for example.internal are forwarded to the host project's authoritative DNS servers. This is the correct approach because it directly enables cross-project DNS resolution for private zones while keeping the zones managed centrally.

To avoid overlap, use unique private IP ranges per VPC, plan for future growth, and document all ranges. Using RFC 1918 addresses and avoiding overlapping CIDRs ensures successful peering and VPN connectivity.

BGP route selection prefers the lowest MED value among routes received from the same neighboring AS. Since the on-premises router receives 10.0.0.0/8 from two paths, and the other path has a lower MED, that route will be preferred. The Cloud Router's advertisement with a higher MED will be less preferred, making option D correct.

In a Shared VPC architecture, the host project owns the VPC network and its resources, including internal load balancers (ILBs). By creating the ILB in the host project and sharing its backend (e.g., instance groups from service projects), the ILB becomes accessible from all projects in the organization without additional connectivity. This approach centralizes network control and ensures the ILB's IP address is routable within the shared VPC, meeting the requirement for cross-project access.

Custom mode VPCs do not create subnets automatically, giving full control over IP ranges.

PCI DSS requires strict network segmentation between environments handling cardholder data. Separate VPCs provide complete isolation at the network layer, preventing any accidental cross-environment traffic. VPC Network Peering allows controlled, encrypted communication between these isolated VPCs without reducing the security boundary, as peering does not merge routing domains or security policies.

Shared VPC allows a host project to share subnets with service projects, providing central network administration while allowing teams to deploy resources independently.

VPC Network Peering allows private IP connectivity between two VPC networks across different organizations without requiring public IPs, VPNs, or gateways. It uses the Google Cloud internal infrastructure to route traffic directly between instances, leveraging RFC 1918 addresses and supporting global peering.

A Cloud NAT gateway per zone provides highly available outbound connectivity for instances without external IPs. By placing a gateway in each zone, traffic from instances in that zone uses the local gateway, avoiding cross-zone hops and ensuring automatic failover if a zone fails. This meets the cost-effective and no-manual-failover requirements without needing instance-level external IPs.

When VPC Network Peering is active but traffic fails, the most common cause is that custom routes are not being exchanged. By default, only subnet routes are exchanged; custom routes (e.g., static routes or routes from VPNs) are not shared unless explicitly configured using the 'export custom routes' option in the peering settings. Without this, the instance in VPC-A has no route to the internal IP of the instance in VPC-B, even if firewall rules allow the traffic.

VPC Network Peering directly connects two VPCs and is non-transitive by default.

DNS peering allows DNS resolution between projects without creating separate managed zones. DNS forwarding is for forwarding queries to an external DNS server.

Custom mode VPC with regional subnets (D) is correct because it allows you to explicitly define subnets in specific regions, ensuring that instances within the same region communicate over low-latency paths without cross-region traffic. This design avoids the automatic creation of subnets in every region (as in auto mode) and prevents the use of deprecated legacy networks, giving you full control over regional placement for latency-sensitive applications.

Cloud Interconnect provides a dedicated, low-latency connection from an on-premises data center to Google Cloud, bypassing the public internet. It offers two options: Dedicated Interconnect (a direct physical connection via a colocation facility) and Partner Interconnect (via a supported service provider). This ensures consistent bandwidth and lower latency compared to VPN-based solutions.

The purpose field determines the subnet's usage; for GKE pods, you set purpose to 'PRIVATE_RFC_1918' or use a secondary range with specific purpose.

The peer ASN is required to configure the BGP session; the Cloud Router ASN is set at the router level.

Cloud DNS with inbound and outbound DNS forwarding enables bidirectional DNS resolution between on-premises and GCP.

Auto mode VPCs automatically create subnets in each region as they become available, reducing operational overhead. Custom mode requires manual subnet creation.

IAM roles on a subnet resource allow you to grant the `compute.subnetUser` role to specific service projects, which controls which projects can create VM instances in that subnet. This is a direct method to restrict subnet usage within a Shared VPC environment, as the role grants permission to use the subnet without granting broader network access.

NCC supports both VPC spokes and hybrid spokes (VPN/Interconnect). It does not support direct VPC-to-VPC peering; that's VPC peering. Route propagation is automatic within NCC.