Implementing A VPC

Preparing for Your
Professional
Cloud Network
Engineer Journey
v Module 2: Implementing a VPC
Welcome to Module 2: Implementing a VPC.

Review and
study planning
Now let’s review the diagnostic questions together.

Your study plan:
Designing, planning, and prototyping
a Google Cloud network
2.1 Configuring VPCs
2.2 Configuring routing
2.3 Configuring and maintaining

Google Kubernetes Engine clusters
2.4 Configuring and managing

firewall rules
2.5 Implementing VPC Service

Controls and Access Contexts
We’ll approach this review by looking at the objectives of this exam section and the
questions you just answered about each one. We’ll introduce an objective, briefly
review the answers to the related questions, and then talk about where you can find
out more in the learning resources and/or in Google Cloud documentation. As we go
through each section objective, use the page in your workbook to mark the specific
documentation, courses (and modules!), and quests you’ll want to emphasize in your
study plan.
2.1 Configuring VPCs
Considerations include:
● Google Cloud VPC resources (e.g., networks, subnets, firewall rules)
● VPC Network Peering
● Creating a Shared VPC network and sharing subnets with other projects
● Configuring API access to Google services (e.g., Private Google Access,
public interfaces)
● Expanding VPC subnet ranges after creation
A Professional Cloud Network Engineer should be able to take a high-level design of

networks and distribution of resources within them to create, connect, and configure
the associated networking infrastructure. You’ll need to consider the distribution of
resources across regions and zones and how to satisfy availability, capacity,
performance, and cost requirements. You should be able to define the details of
communication across resources or between resources and external environments.
You explored these considerations in the diagnostic questions. Question 1 covered

subnet configuration, primary and secondary IP ranges, expanding subnets, routing
rules, and firewalls. Question 2 covered Shared VPC and VPC Peering, including
configuration and knowing when to use them.
To answer these questions, you should be comfortable with all of the considerations
listed on the slide.
21
. Diagnostic Question 01 Discussion
Cymbal Bank has a custom VPC network with two subnets A. Create a new subnet in us-central1 with
(in us-central1 and us-east1) each hosting 500 VMs. The primary IP range 10.128.128.0/22; delete
primary ranges for each are 10.128.128.0/23 and the VMs in the existing subnets one at a
10.128.192.0/23. The VPC has default routes and three time and re-create them in the new subnet; delete the old subnets; and update
firewall rules (all at priority 1000): (A) allows ingress on TCP the B and C firewall rules to use the single new subnet primary range.
port 443 from any IP address; (B) allows ingress on TCP
B. Create a new subnet in us-central1 with primary IP range 10.192.128.0/22; delete
port 8443 from the primary ranges of each subnet; and (C)
the VMs in the existing subnets one at a time and re-create them in the new
denies egress to the primary ranges for each subnet for all
subnet; delete the old subnets; and update the B and C firewall rules to use the
ports and protocols except for TCP port 8443. To reduce
single new subnet primary range.
networking costs, Cymbal Bank wants to consolidate the
1000 VMs into a single subnet in us-central1 (and use a C. Expand the subnet in us-central1 to a primary IP range 10.128.128.0/22; delete the
primary IP range for that subnet to support that) and VMs in the us-east1 subnet one at a time and re-create them in the new subnet;
delete the us-east1 subnet. You want to ensure the simplest delete the us-east1 subnet; and update the B and C firewall rules to use the single
possible firewall rules in the new configuration that provide new subnet primary range.
the same traffic control. D. Expand the subnet in us-central1 to a primary IP range 10.192.128.0/22; delete the
VMs in the us-east1 subnet one at a time and re-create them in the new subnet;
Select the sequence of configuration steps that can delete the us-east1 subnet; and update the B and C rules to use the single new
accomplish this with minimal interruption to the workloads. subnet primary range.
Feedback:
A. Incorrect. Creating a new subnet with that range would cause overlap with the old
ranges.
B. Incorrect. This forces all VMs from both subnets to be deleted and recreated, which
does not minimize interruption.
*C. Correct! This option minimizes interruption by only moving VMs from the subnet to
be deleted while expanding the other subnet, which does not require VMs to be
recreated.
D. Incorrect. You can’t change the primary range prefix of an existing subnet because
only expansion is possible.
Where to look:
https://cloud.google.com/vpc/docs/vpc
https://cloud.google.com/vpc/docs/using-vpc
https://cloud.google.com/vpc/docs/firewalls
https://cloud.google.com/vpc/docs/using-firewalls
Content mapping: Networking in Google Cloud

- Instructor-led training
- Networking in Google Cloud
- M1 Google Cloud VPC networking fundamentals
- M2 Controlling access to VPC networks
- OnDemand
- Networking in Google Cloud: Defining and implementing networks
- Skill badges
- Build and Secure Networks in Google Cloud Quest
(https://www.qwiklabs.com/quests/128?locale=en)
Summary:
When configuring VPC networks and their subnetworks, you can expand the primary
range of a subnet (to max /16 size in auto networks or to the size supported by the IP
block in custom networks) as long as the expansion does not introduce overlap to
other existing subnets. When doing such expansion, any firewall rules depending on
the older range should be updated.
Secondary ranges cannot be expanded or changed and must be deleted and

recreated. Secondary ranges are used by an alias IP allowing secondary internal IP
addresses to be assigned to the VM, typically for container or pod networking.
Deleting a subnet first requires deleting all VMs in that subnet.
Many traffic control scenarios can be accomplished leaving the default routes and
adding, removing, or changing only the firewall rules. You can set multiple rules to be
applied in priority order - but remember to account for the implicit deny all ingress and
allow all egress rules at lowest priority.
21
. Diagnostic Question 02 Discussion
You are designing a networking scheme for A. Connect the VMs across the Cymbal
Cymbal Bank with the requirement to use projects and partner organization using
internal IP addresses for communication, VPCs in each project (V1, V2, V3, V4, V5) and
with the lowest possible latency. Cymbal VPC peering (peering V1 to V2, V2 to V3, V3 to V4, and V4 to V5).
Bank has several teams, each with its own B. Connect the VMs across the Cymbal projects (P1-P3) using a Shared
projects: P1, P2, and P3. Cymbal Bank would VPC network (Shared VPC host project P6 with VPC V6, and P1-P3 are
like consolidated network billing, the service projects) and then peer that Shared VPC network to the
administration, and access control for the partner organization VPCs (V6 peered to V4 and V4 to V5).
cloud environment. VMs in these projects
C. Connect the VMs across Cymbal and partner organization projects
need to connect to VMs in a partner
(P1-P5) using a Shared VPC network (Shared VPC host project P6 with
organization in projects P4 and P5.
VPC V6, and P1-P5 are the service projects).
D. Connect the VMs across the Cymbal projects (P1-P3) using a Shared
Select the networking option that best VPC network (Shared VPC host project P6 with VPC V6, and P1-P3 are
satisfies these requirements. the service projects) and then peer that Shared VPC network to the
partner organization VPCs (V6 peered to V4 and V6 to V5).
Feedback:
A. Incorrect. VPC peering is not transitive (“V1 to V2 and V2 to V3” does not provide
connectivity between V1 and V3). Also, this option doesn’t satisfy the requirement to
have centralized/consolidated network billing, administration, and access control for
Cymbal project networking.
B. Incorrect. VPC peering is not transitive (“V6 peered to V4 and V4 peered to V5”
does not provide connectivity between V6 and V5).
C. Incorrect. Shared VPC cannot work across organizations (only for projects within
the same organization).
*D. Correct! This option satisfies the requirements and provides connectivity between
VMs of all the projects.
Where to look:
https://cloud.google.com/vpc/docs/vpc-peering
https://cloud.google.com/vpc/docs/using-vpc-peering
https://cloud.google.com/vpc/docs/shared-vpc
https://cloud.google.com/vpc/docs/provisioning-shared-vpc
Content mapping:
- Partial coverage in Networking in Google Cloud
- M3 Sharing networks across projects
- M7 Network Design and Deployment
- OnDemand
- Networking in Google Cloud: Hybrid connectivity and network
management
- Skill badges
- Security & Identity Fundamentals Quest
Summary:
Shared VPC is a centralized networking model (for billing, administration, and access
control) whereas VPC peering is a decentralized approach. VPC peering can work
across organizations whereas Shared VPC can only work within organizations. VPC
peering does not support transitive peering and requires any two connected VPCs to
be directly peered.
21
. Configuring VPCs
Courses Skill Badges Documentation

Networking in Google Cloud
● M1 Google Cloud VPC networking VPC network overview
fundamentals
Google Cloud Using VPC networks
● M2 Controlling access to VPC networks
● M3 Sharing networks across projects VPC firewall rules overview
● M7 Network design and deployment Security & Identity
Fundamentals Quest Using firewall rules | VPC
Networking in Google Cloud: Defining and

implementing networks
● M1 Google Cloud VPC networking
fundamentals
● M2 Controlling access to VPC networks
● M3 Sharing networks across projects
Networking in Google Cloud: Hybrid

connectivity and network management
● M3 Network design and deployment
Let’s consider resources that can help you build your knowledge and skills in this
area.
The concepts in the diagnostic questions we just reviewed are covered in these
modules and in this documentation. You’ll find this list in your workbook so you can
take a note of what you want to include later when you build your study plan. Based
on your experience with the diagnostic questions, you may want to include some or all
of these.
https://cloud.google.com/vpc/docs/vpc
https://cloud.google.com/vpc/docs/using-vpc
● Static versus dynamic routing
● Global versus regional dynamic routing
● Routing policies using tags and priority
● Internal load balancer as a next hop
● Custom route import/export over VPC Peering
A Professional Cloud Network Engineer should be able to define the necessary

routing infrastructure and configuration to support the communication requirements of
the workloads in the VPCs. Considerations include those shown on the slide,
including type of routing, routing policies, importing and exchanging custom routes
over VPC network peering.
You explored these considerations in the diagnostic questions. Question 3 tested your
knowledge of VPN routing options such as policy- versus route-based and global
versus regional. Question 4 tested your ability to configure routing rules for custom
routing scenarios.
2.2 Diagnostic Question 03 Discussion
Cymbal Bank needs to connect two A. Configure the VPC for regional dynamic routing
on-premises networks to a single VPC mode; create a Cloud Router in each of the two
network in Google Cloud. One on-premises regions; and connect each office to its closest region
network supports BGP routing and is located via an HA VPN gateway with dynamic routing in that region.
near the us-central1 region. The other
B. Configure the VPC for regional dynamic routing mode; create one Cloud Router in
on-premises network does not support BGP
the us-central1 region; connect the office close to us-central1 to the VPC using an
routing and is located near us-east1. The VPC
HA VPN gateway with dynamic routing in us-central1; and connect the other office
network has subnets in each of these
via a Classic VPN gateway using static routing in us-east1.
regions. You will use Cloud VPN to enable
private communication between the C. Configure the VPC for global dynamic routing mode; create Cloud Routers in each of
on-premises networks and the VPC network. the two regions; and connect each office to its closest region via an HA VPN
gateway with dynamic routing in that region.
D. Configure the VPC for global dynamic routing mode; create Cloud Routers in each of
Select the configuration that provides the
the two regions; connect the office close to us-central1 to the VPC using an HA VPN
highest availability and the lowest
gateway with dynamic routing in us-central1; and connect the other office via a
average latency.
Classic VPN gateway using static routing in us-east1.
Feedback:
A. Incorrect. The second office VPN gateway (close to us-east1) does not support
BGP.
B. Incorrect. This option does not provide the highest availability. The Classic VPN
used to connect the second office to the VPC in the us-east1 region has lower
availability. And when it fails, the traffic would not reroute to use the other VPN
connection automatically because the VPC is configured for regional dynamic routing
mode.
C. Incorrect. The second office VPN gateway (close to us-east1) does not support
BGP.
*D. Correct! This option provides the highest availability. Classic VPN used to connect
the second office to the VPC in us-east1 has lower availability, but when it fails the
traffic will automatically reroute to use the other HA VPN connection.
Where to look:
https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview
https://cloud.google.com/network-connectivity/docs/vpn/concepts/best-practices
https://cloud.google.com/network-connectivity/docs/vpn/concepts/topologies
https://cloud.google.com/network-connectivity/docs/vpn/concepts/classic-topologies
https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn
https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn2
https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-static-vpns
https://cloud.google.com/network-connectivity/docs/vpn/concepts/choosing-networks-r
outing
https://cloud.google.com/network-connectivity/docs/router/concepts/overview
Content Mapping:
- M5 Hybrid connectivity
- OnDemand
management
- Skill badges
- Network Performance and Optimization Quest
Summary:
HA VPN only supports dynamic routing with BGP and can’t be used if the peer
on-premises VPN gateway does not support BGP. Classic VPN supports static
routing, either route-based or policy-based. Use Classic VPN when the on-premises
VPN gateway does not support BGP.
HA VPN provides 99.99% availability; Classic VPN only supports 99.9% availability.
HA VPN is the recommended approach whenever the on-premises VPN gateway
supports BGP.
Dynamic routing requires a Cloud Router. Dynamic routing is simpler to configure and
maintain than static routing because route changes in either connected network can
be discovered and advertised automatically. The Dynamic routing mode of the VPC
determines whether Cloud Routers will use regional or global dynamic routing or
dynamic routing. A single VPN connection can provide connectivity across all subnets
and regions within a VPC when the VPC is in global dynamic routing mode. However,
the average latency will not be as low as if there are separate Cloud VPN gateways
and Cloud Routers per region.
You are designing a VPC network with the A. Create a custom route to the destination
requirement that all external traffic 0.0.0.0/0, and specify the next hop as the proxy VM.
destined for the internet is passed B. Delete the system-generated default route, create a custom route to
through a proxy VM. The proxy will have destination 0.0.0.0/0, and specify the next hop as the proxy VM.
software installed to scan, detect, and
drop invalid egress traffic and to help C. Create a custom route to the destination 0.0.0.0/0, specify the next hop
as the proxy VM, and configure the scanning VM to enable IP forwarding.
prevent data exfiltration, outbound
attacks, or access to blocked websites. D. Delete the system-generated default route, and then create a custom
route to destination 0.0.0.0/0. Specify the next hop as the proxy VM,
and configure the proxy VM to enable IP forwarding.
Select the configuration that can
most easily accomplish this.
Feedback:
A. Incorrect. You can’t create a new custom route to the 0.0.0.0/0 destination until
you first delete the system-generated default route (which goes to that same
destination).
B. Incorrect. You must enable IP forwarding in a VM to allow it to proxy egress traffic.
C. Incorrect. You can’t create a new custom route to the 0.0.0.0/0 destination until you
first delete the system-generated default route (which goes to that same destination).
*D. Correct! This is the minimal set of steps to configure this routing scenario.
Where to look:
https://cloud.google.com/vpc/docs/routes
https://cloud.google.com/vpc/docs/using-routes
Content Mapping:
- OnDemand
management
- Skill badges
Summary:
Most standard network routing can be accomplished using the default created routes.
In some scenarios, traffic must be forwarded through a NAT or Proxy instance, or
routed through an intermediary different than the destination IP address. This can be
accomplished by creating custom routes. When creating a custom route, you can
specify a destination IP address or range and the next hop instance, load balancer, IP
address, internet gateway, or VPN gateway. You can limit which VMs would use a
custom route by adding a tag to the custom route that matches a tag on the
appropriate VMs.

Cloud VPN overview
● M1 Google Cloud VPC networking Best practices for Cloud VPN
fundamentals Google Cloud HA VPN topologies
● M3 Sharing networks across
Build and Secure Networks in
projects Classic VPN topologies
Google Cloud Quest
● M5 Hybrid connectivity
Creating an HA VPN gateway to a peer VPN
gateway
Creating an HA VPN between Google Cloud
Networking in Google Cloud: Defining
Google Cloud networks
and implementing networks
● M1 Google Cloud VPC networking Security & Identity Creating a Classic VPN using static routing
fundamentals Fundamentals Quest
● M3 Sharing networks across Networks and tunnel routing | Cloud VPN
projects Cloud Router overview
Networking in Google Cloud: Hybrid Routes overview | VPC

Google Cloud
connectivity and network management Using routes | VPC
● M1 Hybrid connectivity Network Performance and
● M3 Network design and deployment Optimization Quest
area.
of these.
https://cloud.google.com/network-connectivity/docs/vpn/concepts/overview
https://cloud.google.com/network-connectivity/docs/vpn/concepts/best-practices
https://cloud.google.com/network-connectivity/docs/vpn/concepts/topologies
https://cloud.google.com/network-connectivity/docs/vpn/concepts/classic-topologies
https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn
https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn2
https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-static-vpns
https://cloud.google.com/network-connectivity/docs/vpn/concepts/choosing-networks-r
outing
https://cloud.google.com/network-connectivity/docs/router/concepts/overview
https://cloud.google.com/vpc/docs/routes
https://cloud.google.com/vpc/docs/using-routes
Configuring and maintaining
2.3 Google Kubernetes Engine clusters
● VPC-native clusters using alias IP addresses
● Clusters with Shared VPC
● Creating Kubernetes Network Policies
● Private clusters and private control plane endpoints
● Adding authorized networks for cluster control plane endpoints
A Professional Cloud Network Engineer will be responsible for configuring all the
networking related details of Kubernetes Engine clusters. Some considerations are
noted on the slide; for example, VPC-native clusters using alias IPs, clusters with
Shared VPC, and Creating Kubernetes network policies.
knowledge of pod and service IP ranges for GKE networking. Question 6 tested your
ability to work with specialized GKE networking scenarios.
Cymbal Bank has an existing subnet that A. Expand the subnet primary IP address range to 10.128.0.0/16; create a
you want to use for a new VPC-native secondary range in the subnet of size /14 for pods and another of size
GKE cluster. The subnet primary IP /17 for services; and create the GKE VPC-native cluster in the subnet
address range is 10.128.128.0/20. using these secondary ranges.
Currently the 1000 other VMs using that B. Create a secondary range in the subnet of size /13 for pods and another
subnet have taken 1000 of the available of size /16 for services, and create the GKE VPC-native cluster in the
IP addresses. The new GKE cluster subnet using these secondary ranges.
should support 200,000 pods and
C. Create a GKE VPC-native cluster in the subnet, specifying the size of the
30,000 services.
pod range as /14 and the size of the services range as /17.
Select the minimal set of D. Create a GKE VPC-native cluster in the subnet, specifying the size of the
configuration steps and the smallest pod range as /13 and the size of the services range as /17.
possible IP ranges to enable this.
Feedback:
A. Incorrect. Expansion of the subnet is unnecessary because there are enough IP
addresses for sufficient nodes to support 200,000 pods. The secondary ranges can
be specified when creating the cluster. Also, the pod range is not large enough for
200,000 pods (requires /13 size) because each pod requires one IP address.
B. Incorrect. Secondary ranges can be created automatically when the GKE cluster is
created and don’t require manual creation beforehand. Also, the service range is
larger than necessary to support 30,000 service (/17 would suffice) because each pod
requires one IP address.
C. Incorrect. The pod range is not large enough for 200,000 pods (requires /13 size)
because each pod requires one IP address.
*D. Correct! This is the minimal configuration with the smallest possible ranges
because each pod and service requires one IP address..
Where to look:
https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters
https://cloud.google.com/kubernetes-engine/docs/concepts/alias-ips
https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips
https://cloud.google.com/kubernetes-engine/docs/how-to/flexible-pod-cidr
Content mapping: Highly recommend reviewing documentation

- Skill badges
- Minor coverage in Security & Identity Fundamentals Quest
Summary:
For VPC-native clusters, secondary subnet ranges are used for pod and service IP
ranges. You can either pre-create the secondary ranges or simply specify them when
creating the cluster. Each node will support up to 110 pods. The primary IP range
needs to be large enough that when the number of nodes is multiplied by 110, the
supported number of pods will be sufficient. The size of the pod range also needs to
be large enough to provide one IP address per pod for the maximum number of pods.
The service range should be large enough to provide one IP address for the
maximum number of services.
A. Assign the Compute Network User role
You will be deploying a VPC-native GKE
(in the host project) to
cluster into an existing service project of
the service-{serviceProjectNumber}@
a Shared VPC. You will create an Ingress container-engine-robot.iam.gserviceaccount.com
to trigger the automatic creation, service account (where serviceProjectNumber is the
connection, and firewall configuration of project number of the service project).
an HTTP(S) load balancer to a service B. Assign the Host Service Agent User (in the host project) to the
deployed in the cluster for service-{serviceProjectNumber}@container-engine-robot.iam.
container-native load balancing. gserviceaccount.com service account (where serviceProjectNumber is the project
number of the service project) .
Select the option corresponding to C. Assign the Host Service Agent User and the Compute Network User (in the host
the IAM policy binding of least project) to the service-{serviceProjectNumber}@container-engine-robot.iam.
privilege necessary. gserviceaccount.com service account (where serviceProjectNumber is the project
number of the service project).
D. Assign the Host Service Agent User (in the host project) and the Compute Network
User (for the subnet of the GKE cluster in the shared VPC in the host project) to the
service-{serviceProjectNumber}@container-engine-robot.iam.
gserviceaccount.com service account (where serviceProjectNumber is the project
number of the service project).
Feedback:
A. Incorrect. This option is missing a necessary role binding.
B. Incorrect. This option is missing a necessary role binding.
C. Incorrect. This option is not least privileged access (it provides access to the entire
VPC when only the subnet hosting the GKE cluster is necessary).
*D. Correct! This is the least privilege option.
Where to look:
https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-shared-vpc
https://cloud.google.com/kubernetes-engine/docs/concepts/network-overview
https://cloud.google.com/kubernetes-engine/docs/concepts/ingress
https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features
https://cloud.google.com/kubernetes-engine/docs/best-practices/networking
https://cloud.google.com/kubernetes-engine/docs/concepts/container-native-load-bala
ncing
Content mapping: Not in current learning path, please refer to documentation
Summary:
When running GKE clusters in a Shared VPC, some extra IAM role bindings must be
granted to the Kubernetes Engine service agent to let the GKE cluster create the
necessary networking resources. It requires the Compute Network User role for the
Shared VPC subnet of the GKE cluster, as well as the Host Service Agent User for
the Shared VPC host project.
Configuring and maintaining Google
2.3 Kubernetes Engine clusters
Skill Badge Documentation

Types of clusters | Kubernetes Engine Documentation
VPC-native clusters | Kubernetes Engine Documentation
Google Cloud
Creating a VPC-native cluster | Kubernetes Engine Documentation
Security and Identity Optimizing IP address allocation | Kubernetes Engine Documentation
Fundamentals Quest Setting up clusters with Shared VPC | Kubernetes Engine
Documentation
Network overview | Kubernetes Engine Documentation
GKE Ingress for HTTP(S) Load Balancing
Configuring Ingress features | Kubernetes Engine Documentation
Best practices for GKE networking | Kubernetes Engine Documentation
Container-native load balancing | Kubernetes Engine Documentation
area.
The concepts in the diagnostic questions we just reviewed are covered in this Skill
Badge and in this documentation. Reviewing the documentation is highly
recommended! You’ll find this list in your workbook so you can take a note of what
you want to include later when you build your study plan. Based on your experience
with the diagnostic questions, you may want to include some or all of these.
https://cloud.google.com/kubernetes-engine/docs/concepts/types-of-clusters
https://cloud.google.com/kubernetes-engine/docs/concepts/alias-ips
https://cloud.google.com/kubernetes-engine/docs/how-to/alias-ips
https://cloud.google.com/kubernetes-engine/docs/how-to/flexible-pod-cidr
https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-shared-vpc
https://cloud.google.com/kubernetes-engine/docs/concepts/network-overview
https://cloud.google.com/kubernetes-engine/docs/concepts/ingress
https://cloud.google.com/kubernetes-engine/docs/how-to/ingress-features
https://cloud.google.com/kubernetes-engine/docs/best-practices/networking
https://cloud.google.com/kubernetes-engine/docs/concepts/container-native-load-bala
ncing
2.4 Configuring and managing firewall rules
● Target network tags and service accounts
● Rule priority
● Network protocols
● Ingress and egress rules
● Firewall rule logging
● Firewall Insights
● Hierarchical firewalls
The Professional Cloud Network Engineer uses firewall rules as the primary
mechanism of traffic control with the VPCs and should be able to configure them to
support all common workload communication scenarios. Considerations include
target network tags and service accounts, rule priority, and network protocols.
ability to configure firewall rules. Question 8 tested your ability to troubleshoot
connectivity issues using firewall logging and insights.
A. Create service accounts (S1, S2, S3) for the microservices,
You are configuring firewall rules for
and assign those service accounts to the instance template
securing a set of microservices (MS1, for the MIG used by each microservice. Create three ingress allow
MS2, MS3) running in separate managed firewall rules: for TCP 8443 from source S1 to target S2; for TCP 8663 from source S2 to target S3, and
instance groups (MIGs) of VMs in a single for TCP 8883 from source S3 to target S1.
subnet of a VPC network. The primary B. Create network tags (T1, T2. T3) for the microservices, and assign those network tags to the instance
range of the VPC network is template for the MIG used by each microservice. Create three ingress allow firewall rules: for TCP
10.128.128.0/20. MS1 will send requests to 8443 from source T1 to target T2; for TCP 8663 from source T2 to target T3; and for TCP 8883 from
MS2 on TCP port 8443; MS2 will send source T3 to target T4.
requests to MS3 on TCP port 8663; and C. Create service accounts (S1, S2, S3) for the microservices, and assign those service accounts to the
MS3 will need to send requests to MS1 on instance template for the MIG used by each microservice. Create three ingress allow firewall rules:
TCP port 8883. There will be no other for TCP 8443 from source 10.128.128.0/20 to target S2; for TCP 8663 from source 10.128.128.0/20 to
communication to or between these target S3; for TCP and 8883 from source 10.128.128.0/20 to target S1’.
microservices. D. Create network tags (T1, T2, T3) for the microservices, and assign those network tags to the instance
template for the MIG used by each microservice. Create three ingress allow firewall rules: for TCP
Select a simple and secure firewall 8443 from source 10.128.128.0/20 to target T2; for TCP 8663 from source 10.128.128.0/20 to target T3;
and for TCP 8883 from source 10.128.128.0/20 to target T1.
configuration to support this traffic
requirement.
Feedback:
*A. Correct! This option is as simple as the others but provides better security: service
accounts have tighter access control than network tags.
B. Incorrect. This option is slightly less secure than option A: service accounts have
tighter access control than network tags.
C. Incorrect. This option is significantly less secure than option A. It would allow
requests into the microservices from any other workloads deployed in the same
subnet, using the same ports as the intended microservices.
D. Incorrect. This is significantly less secure than option A because it would allow
requests into the microservices from any other workloads deployed in the same
subnet using the same ports as the intended microservices.
Where to look:
Content mapping:
- Networking in Google Cloud
- M4 Load balancing
- M8 Network Monitoring and Troubleshooting
- OnDemand
- M4 Load balancing
management
- Skill badges
Summary:
Firewall rules can be assigned to operate on all instances in a VPC. You can also
assign them to specific VMs using source or destination IP addresses or IP ranges.
You can also assign firewall rules using source and target service accounts or tags. In
general using source and target service accounts is the recommended approach and
provides the best security.
You are trying to determine which firewall A. On the Firewall Insights page of the Google Cloud Console,
rules are incorrectly blocking requests find the names of the deny firewall rules with hits to identify
between two VMs running within a VPC rules that are blocking requests. On the Legacy Logs Viewer
or Logs Explorer page, view the firewall logs and filter for logs
network: VM1 and VM2. Firewall logging is
that match those rules by name, using jsonPayload.rule_details.reference field, matching the names
enabled for all firewall rules, including
of the deny firewall rules with hits.
metadata. The Firewall Insights and
B. On the Logs Explorer or Legacy Logs Viewer page, view the firewall logs, and filter for logs that
Recommendations API are also enabled.
match the source and destination VMs VM1 and VM2, using the jsonPayload.instance.project_id,
All insights are enabled, and observation
jsonPayload.instance.vm_name, jsonPayload.instance.region, and jsonPayload.instance.zone,
period set over a period capturing the jsonPayload.remote_instance.vm_name, jsonPayload.remote_instance.region, and
blocked requests. jsonPayload.remote_instance.zone.
C. On the Logs Explorer or Legacy Logs Viewer page, view the firewall logs, and filter for logs that
match the destination VM2 in the VPC, using the jsonPayload.instance.project_id,
jsonPayload.instance.vm_name, jsonPayload.instance.region, and jsonPayload.instance.zone fields.
Select a valid troubleshooting D. On the Firewall Insights landing page of the Google Cloud Console, find the names of the allow
approach to find the incorrectly firewall rules with no hits to identify rules that are not allowing requests. On the Logs Viewer or
Explorer page, view the firewall logs and filter for logs matching those rules by name, using
configured firewall rule.
jsonPayload.rule_details.reference field (matching the names of the allow firewall rules with no hits).
Feedback:
A. Incorrect. This approach will not work if the traffic is being blocked by the implicit
deny all ingress rule (i.e., there is no appropriate allow rule that is allowing the
requests to ingress VM2).
*B. Correct! This is the only approach among the options that will detect the
incorrectly configured rule whether it is a missing or incorrect ingress allow or a
incorrect egress deny rule.
C. Incorrect. This approach will not work if the traffic is being blocked by some deny
egress rule at VM1.
D. Incorrect. This approach will not work if the traffic is being blocked by some deny
egress rule at VM1.
Where to look:
https://cloud.google.com/vpc/docs/firewall-rules-logging
https://cloud.google.com/vpc/docs/using-firewall-rules-logging
https://cloud.google.com/network-intelligence-center/docs/firewall-insights/how-to/usin
g-firewall-insights
https://cloud.google.com/network-intelligence-center/docs/firewall-insights/concepts/o
verview
Content Mapping:
- OnDemand
management
Summary:
Firewall Logging and Firewall Insights can be useful tools for troubleshooting firewall
configuration problems. They must be enabled and properly configured before usage.
Firewall Insights provides high-level details for quick analysis and detection of
problems, such as shadowed rules, overly permissive rules, and active deny rules. It
doesn’t directly provide detailed information about the firewall rule activity.
Firewall Insights can be combined with filtering on matching firewall logs to get more
of the details. Firewall logs capture all of the detailed information about firewall activity
but can produce large logs. These logs may require filtering to effectively find activity
related to the traffic flows of interest.
When troubleshooting, it’s also important to remember that logs and insights are not
captured for the implicit deny all ingress and allow all egress firewall rules.
Configuring and managing
2.4 firewall rules

VPC firewall rules overview
fundamentals Using firewall rules | VPC
● M2 Controlling access to VPC networks Google Cloud
● M3 Sharing networks across projects Firewall Rules Logging overview | VPC
● M4 Load balancing Build and Secure Networks in
● M7 Network design and deployment Google Cloud Quest Using Firewall Rules Logging | VPC
● M8 Network monitoring and
troubleshooting Using Firewall Insights
Firewall Insights overview
Networking in Google Cloud: Defining and
implementing networks Google Cloud
fundamentals Security & Identity
● M2 Controlling access to VPC networks Fundamentals Quest
● M3 Sharing networks across projects
● M4 Load balancing
Networking in Google Cloud: Hybrid

connectivity and network management Google Cloud
● M4 Network monitoring and Network Performance and
troubleshooting Optimization Quest
area.
of these.
https://cloud.google.com/vpc/docs/firewall-rules-logging
https://cloud.google.com/vpc/docs/using-firewall-rules-logging
https://cloud.google.com/network-intelligence-center/docs/firewall-insights/how-to/usin
g-firewall-insights
https://cloud.google.com/network-intelligence-center/docs/firewall-insights/concepts/o
verview
Implementing VPC Service Controls and
2.5 Access Contexts
● VPC Service Control Perimeters
● Creating and configuring Access Contexts and
attaching to a Perimeter
● VPC accessible services
● Perimeter Bridges
● Audit logging
● Dry run mode
The Professional Cloud Network Engineer should also consider data security and
protecting data against unauthorized movement across the network; for example,
using VPC service controls, attaching access controls to a service perimeter, and
VPC accessible services.
You explored these considerations in the diagnostic questions. Diagnostic question 9

tested your knowledge of VPC service control concepts and configuration. Diagnostic
question 10 tested your knowledge of VPC service control perimeter bridges, access
levels, and configuration.
Cymbal Bank requires that access to the
A. Create a VPC service controls service perimeter
Cloud Storage buckets in a project is
that includes the project and restricts access to
restricted to ensure that the only way the
Cloud Storage APIs, and enable VPC accessible
buckets or objects within can be accessed
services configuring Cloud Storage APIs as accessible.
is via users (who also have the necessary
IAM role or ACL access to the bucket or B. Create a VPC service controls service perimeter that includes the project and restricts
object) first connecting to a VM running in a access to Cloud Storage APIs.
VPC in the project via SSH. You also want to C. Create a VPC service controls service perimeter that includes an ingress rule for all
ensure that users and service accounts are users ingressFrom.identityType: ANY_USER_ACCOUNT; ingressFrom.sources.resource
blocked from access to other Google Cloud set to the project full path; ingressTo.operations.serviceName set to
APIs in the same project from VMs in the storage.googleapis.com; ingressTo.operations.methodSelectors.permission set to
project VPCs, regardless of whether they google.storage.buckets.get; and ingressTo.resources set to \"*\"
have access via Identity and Access
D. Update the IAM role bindings for all users with access to the buckets to add an IAM
Management (IAM) roles.
condition of the access level attribute type.
Select the approach that can
accomplish this with minimal
configuration effort and complexity.
Feedback:
*A. Correct! This is the minimal configuration that can satisfy the requirements
B. Incorrect. This would not be sufficient to ensure that access to other Google Cloud
APIs is blocked
C. Incorrect. This would require more configuration, would not provide access for all
operations to Cloud Storage bucket and objects, and would not ensure that access
was restricted for service accounts or other Google Cloud APIs
D. Incorrect. This would require much more configuration and would not ensure that
access to other Google Cloud APIs was blocked
Where to look:
https://cloud.google.com/vpc-service-controls/docs/overview
https://cloud.google.com/vpc-service-controls/docs/service-perimeters
https://cloud.google.com/vpc-service-controls/docs/ingress-egress-rules
https://cloud.google.com/vpc-service-controls/docs/share-across-perimeters
https://cloud.google.com/vpc-service-controls/docs/create-service-perimeters
https://cloud.google.com/vpc-service-controls/docs/dry-run-mode
Content Mapping: Not in current course, please refer to documentation
Summary:
VPC Service controls provide another option for access control and restriction along
with Cloud IAM and Firewall rules. They allow for the creation of service perimeters
around one or more projects that can allow or restrict access to Google Cloud APIs in
those projects from inside (VPCs within the project) and outside those projects (VPCs
in other projects or the internet). Service perimeter access control can be tailored
with access levels, ingress and egress rules, and service perimeter bridges allowing
for flexibility in how access is enabled or disabled.
Cymbal Bank has a set of VPC service A. Create a service perimeter bridge connecting
control service perimeters around the service perimeters of all the projects.
several projects with BigQuery B. Create a service perimeter bridge connecting the service perimeters of all
datasets, and each project is in a the projects, and update all the service perimeters to add an access level
separate service perimeter. You want providing the external access for the specified users.
to restrict access to these projects’
C. Update the service perimeter configurations for all the projects to add an
BigQuery datasets to VMs in the VPCs
ingress rule with an access level to provide the external access for the
of one of these projects (project P1,)
specified users.
and a small set of users should have
external access from a combination of D. Update the service perimeter configurations for all the projects to add an
a specific IP range, geo-location, and ingress rule to provide external access for the specified users and add
device type. another ingress rule to provide access from the VPCs of the specified
project P1.
Select the configuration that
satisfies these requirements with
minimal configuration.
Feedback:
A. Incorrect. This would not satisfy the requirement or provide access to external
users, and it would not limit access to VMs in VPCs of only project P1.
B. Incorrect. This would not satisfy the requirement of providing access only to VMs in
VPCs of project P1.
C. Incorrect. This would not satisfy the requirement of providing access only to VMs in
VPCs of project P1.
*D. Correct! This is the correct minimal configuration to satisfy the requirements.
Where to look:
https://cloud.google.com/vpc-service-controls/docs/create-perimeter-bridges
https://cloud.google.com/vpc-service-controls/docs/secure-data-exchange
https://cloud.google.com/vpc-service-controls/docs/context-aware-access
https://cloud.google.com/access-context-manager/docs/access-level-attributes
https://cloud.google.com/access-context-manager/docs/custom-access-level-spec
Content mapping: Not in current course, please refer to documentation
Summary:
Access Levels, Service perimeter bridges, and Ingress and Egress rules can all be
used to adjust the access control provided by VPC service control service perimeters.
Access levels allow external access across service perimeters based on the attributes
of the request (such as IP address, identity, geolocation, and device type). Service
perimeter bridges provide bi-directional access to all the projects of both service
perimeters on either side of the service perimeter bridge. Ingress and Egress rules
allow for more granular control of access across service perimeter boundaries as
compared to service perimeter bridges. Ingress and Egress rules can also include
and adjust the access provided by access levels.
Implementing VPC Service Controls and
2.5 Access Contexts
Documentation
Overview of VPC Service Controls Ingress and egress rules | VPC Service Controls
Service perimeter details and configuration | VPC Service Sharing across perimeters with bridges | VPC Service
Controls Controls
Ingress and egress rules | VPC Service Controls Creating a perimeter bridge | VPC Service Controls
Sharing across perimeters with bridges | VPC Service Secure data exchange with ingress and egress rules
Controls
Context-aware access with ingress rules | VPC Service
Creating a service perimeter | VPC Service Controls Controls
Dry run mode for Service Perimeters | VPC Service Access level attributes | Access Context Manager
Controls
Custom access level specification | Access Context
Manager
area.
The concepts in the diagnostic questions we just reviewed are covered in this
documentation. You’ll find this list in your workbook so you can take a note of what
you want to include later when you build your study plan. Based on your experience
with the diagnostic questions, you may want to include some or all of these.
https://cloud.google.com/vpc-service-controls/docs/overview
https://cloud.google.com/vpc-service-controls/docs/service-perimeters
https://cloud.google.com/vpc-service-controls/docs/create-service-perimeters
https://cloud.google.com/vpc-service-controls/docs/dry-run-mode
https://cloud.google.com/vpc-service-controls/docs/create-perimeter-bridges
https://cloud.google.com/vpc-service-controls/docs/secure-data-exchange
https://cloud.google.com/vpc-service-controls/docs/context-aware-access
https://cloud.google.com/access-context-manager/docs/access-level-attributes
https://cloud.google.com/access-context-manager/docs/custom-access-level-spec

Implementing A VPC

Uploaded by

Copyright:

Available Formats

Implementing A VPC

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Implementing A VPC

Uploaded by

Copyright:

Available Formats

Preparing for Your

Welcome to Module 2: Implementing a VPC.

Now let’s review the diagnostic questions together.

2.2 Configuring routing

2.3 Configuring and maintaining

2.4 Configuring and managing

2.5 Implementing VPC Service

A Professional Cloud Network Engineer should be able to take a high-level design of

You explored these considerations in the diagnostic questions. Question 1 covered

Content mapping: Networking in Google Cloud

Secondary ranges cannot be expanded or changed and must be deleted and

Courses Skill Badges Documentation

Networking in Google Cloud: Defining and

Networking in Google Cloud: Hybrid

A Professional Cloud Network Engineer should be able to define the necessary

Courses Skill Badges Documentation

Networking in Google Cloud: Hybrid Routes overview | VPC

Content mapping: Highly recommend reviewing documentation

Content mapping: Not in current learning path, please refer to documentation

Skill Badge Documentation

Courses Skill Badges Documentation

Networking in Google Cloud: Hybrid

You explored these considerations in the diagnostic questions. Diagnostic question 9

Content Mapping: Not in current course, please refer to documentation

Content mapping: Not in current course, please refer to documentation

You might also like