coderj001 / google-cloud-associate-cloud-engineer-prep

Google Cloud Associate Cloud Engineer Prepation Notes

Google Cloud Platform - Associate Exam Prep

• Introduction
  • Meet Your Instructor
  • Understanding Course Resources
  • Google Cloud Certifications and Exams
  • Scenario Bowtie
  • Preview of Practice Exam
• Cloud Computing Fundamentals
  • What Is Cloud Computing?
  • Cloud Deployment Models
  • Cloud Service Models
• Google Cloud Fundamentals
  • Google Cloud Global Infrastructure
  • Compute Service Options
  • Storage and Database Options
  • Networking Services
• Account Setup
  • Resource Hierarchy
  • Create Free Tier Account
  • Securing Your Account
  • GCP Console Overview
  • Cloud Billing
  • Controlling Costs and Budget Alerts
  • Controlling Costs and Budget Alerts Follow Along
  • Billing Export
  • Cloud APIs
  • Adding an Admin User
  • Cloud SDK and CLI
  • Cloud SDK and CLI Follow Along
  • Managing Cloud SDK
  • Cloud Shell and Editor
  • Creating and managing projects
  • Limits and Quotas
• Identity and Access Management
  • Cloud IAM
  • Policies and Conditions
  • Cloud IAM
  • Service Accounts
  • Service Accounts
  • Cloud Identity
  • Cloud IAM Best Practices
• Networking Services
  • Networking Refresher PART 1
  • Networking Refresher PART 2
  • Virtual Private Cloud
  • VPC Network Subnets
  • Routing and Private Google Access
  • IP Addressing
  • Creating Internal and External Static IP Addresses PART 1
  • Creating Internal and External Static IP Addresses PART 2
  • Firewall and Firewall Rules
  • Custom VPC Part 1
  • Custom VPC Part 2
  • VPC Network Peering
  • VPC Network Peering
  • Shared VPC
  • VPC Flow Logs
  • DNS Fundamentals
  • DNS Record Types
  • Network Address Translation PART 1
  • Network Address Translation PART 2
  • Cloud DNS
• Compute Engine
  • Virtualization Fundamentals
  • Compute Engine Overview
  • Creating a VM Instance
  • Compute Engine Machine Types
  • Managing Instances
  • Connecting to Your Instances PART 1
  • Connecting To Your Instances PART 2
  • Metadata and Startup Scripts
  • Compute Engine Billing
  • Storage Fundamentals
  • Persistent Disk and Local SSDs PART 1
  • Persistent Disk and Local SSDs PART 2
  • Managing disks on Compute Engine PART 1
  • Managing disks on Compute Engine PART 2
  • Snapshots
  • Creating Snapshots and Snaphot Schedules
  • Deployment Manager
  • Deployment Manager
• High Availability and Autoscaling
  • Cloud Load Balancers PART 1
  • Cloud Load Balancers PART 2
• Kubernetes Engineer and Containers
  • Introduction to Containers
  • GKE and Kubernetes Concepts
  • Cluster and Node Management
  • Pods and Object Management
  • Kubernetes Services PART 1
  • Kubernetes Services PART 2
  • Ingress for GKE
  • GKE Storage Options
  • Creating a GKE Cluster Part 1
  • Creating a GKE Cluster Part 2
  • Creating and deploying an app in GKE Part 3
  • Managing workloads on GKE Part 4
• Hybrid Connectivity
  • Cloud VPN
  • Cloud Interconnect
• Serverless Services
  • App Engine Overview
  • Deploying Serverless Bowties to App Engine
  • Introduction to Cloud Functions
  • Deploying a Cloud Function
• Storage Services
  • Cloud Storage Storage Types
  • Object Lifecycle Management and Versioning
  • Managing Cloud Storage Access PART 1
  • Managing Cloud Storage Access PART 2
  • Object Lifecycle Management and Versioning
  • Cloud SQL
  • Cloud Spanner
  • NoSQL Databases
• Big Data and Machine Learning
  • Big Data Services
  • Machine Learning Services
• Operations Suite
  • Operations Suite

Watching Youtube Video,

Google Cloud Associate Cloud Engineer Course - Pass the Exam!

Notes

5 characteristics that define cloud computing

1. On-demand self-service: Cloud users can provision computing resources, such as compute, storage, and networking, on demand. This means that users can scale up or down their resources as needed, without having to worry about provisioning and managing the underlying infrastructure.
2. Broad network access: Cloud resources are accessible over the internet, which means that users can access them from anywhere. This makes cloud computing ideal for businesses that have a global workforce or that need to be able to access their data from anywhere.
3. Resource pooling: Cloud providers pool their resources and share them among multiple users. This allows cloud providers to achieve economies of scale and offer their services at a lower cost than traditional on-premises IT.
4. Rapid elasticity: Cloud resources can be scaled up or down rapidly, in response to changes in demand. This allows businesses to save money by only provisioning the resources they need, when they need them.
5. Measured service: Cloud providers charge their users based on the amount of resources they consume. This allows businesses to track their costs and optimize their usage.

These are just some of the characteristics that define cloud computing. Cloud computing is a rapidly evolving field, and new characteristics are being developed all the time.

Cloud Deployment Model

A cloud deployment model is a way of organizing and delivering cloud computing services. There are three main cloud deployment models:

• Public cloud: Public clouds are owned and operated by a cloud service provider (CSP). Users access public clouds over the internet. Public clouds are the most popular cloud deployment model.
• Private cloud: Private clouds are owned and operated by an organization. Users access private clouds over a private network. Private clouds are often used by organizations that need to comply with specific security or regulatory requirements.
• Hybrid cloud: Hybrid clouds combine public and private clouds. Users can access resources from both public and private clouds. Hybrid clouds are often used by organizations that want to take advantage of the benefits of both public and private clouds.

Here is a table that summarizes the different cloud deployment models:

Cloud Deployment Model	Ownership	Access	Benefits	Drawbacks
Public cloud	CSP	Internet	Scalability, cost-effectiveness, ease of use	Security, compliance, control
Private cloud	Organization	Private network	Security, compliance, control	Cost, complexity
Hybrid cloud	Organization, CSP	Both public and private networks	Best of both worlds	Complexity, cost

The best cloud deployment model for an organization will depend on its specific needs and requirements.

Here are some of the factors that organizations should consider when choosing a cloud deployment model:

• Security: The security of the cloud deployment model is a critical factor. Organizations need to make sure that their data is secure in the cloud.
• Compliance: Organizations that need to comply with specific security or regulatory requirements may need to use a private cloud.
• Cost: The cost of the cloud deployment model is also a factor. Public clouds are typically more cost-effective than private clouds.
• Scalability: The scalability of the cloud deployment model is important for organizations that need to be able to scale their cloud resources up or down as needed.
• Control: The level of control that an organization has over the cloud deployment model is also a factor. Private clouds offer more control than public clouds.

Cloud Service Model Consepts

• Infrastructure as a Service (IaaS): IaaS is like ordering a frozen pizza. The pizza company provides all of the ingredients, but you have to do the cooking yourself. This means that you have to provision and manage the underlying infrastructure, such as compute, storage, and networking.
• Platform as a Service (PaaS): PaaS is like ordering a pizza from a restaurant. The restaurant provides the dough, sauce, cheese, and toppings, but you don't have to do any cooking. This means that you don't have to worry about provisioning and managing the underlying infrastructure. Instead, you can focus on developing and deploying your applications.
• Software as a Service (SaaS): SaaS is like ordering a pizza from a delivery service. The delivery service provides the pizza, and you don't have to do anything. This means that you don't have to worry about provisioning, managing, or developing anything. You can simply use the service as-is.

Here is a table that summarizes the different cloud service models and their pizza analogies:

Cloud Service Model	Pizza Analogy
Infrastructure as a Service (IaaS)	Frozen pizza
Platform as a Service (PaaS)	Restaurant-made pizza
Software as a Service (SaaS)	Delivery-service pizza

Google Cloud Fundamentals

Google Cloud Global Infrastructure

• Google Cloud has a global infrastructure of data centers and regions.
• There are currently 24 regions and 73 zones in Google Cloud.
• Each region is a geographic area with multiple zones.
• Zones are isolated from each other, so if one zone goes down, the others will still be up.
• Google Cloud uses a variety of technologies to ensure the reliability and performance of its global infrastructure.
• These technologies include:
  • Load balancing
  • Redundant storage
  • High-speed networking
  • Disaster recovery

Here are some additional details about Google Cloud Global Infrastructure:

• The regions are spread across the globe, so you can choose the region that is best for your application.
• The zones are located within each region, and they are designed to be as close to each other as possible.
• This helps to ensure that your application will have low latency, even if it is accessed from anywhere in the world.
• Google Cloud Global Infrastructure is designed to be highly reliable.
• If one zone goes down, your application will continue to run in the other zones.
• This helps to ensure that your application is always available.

Compute Service Option

• Compute Engine is a service that provides virtual machines (VMs) that can be used to run applications. VMs are customizable and can be scaled up or down as needed.
• Google Kubernetes Engine (GKE) is a service that manages Kubernetes clusters. Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications.
• Cloud Run is a serverless compute platform that allows you to run stateless containers that are invocable via HTTP requests. Cloud Run is a good choice for applications that do not require persistent storage or state management.
• App Engine is a fully managed platform that allows you to run web applications and mobile backends. App Engine is a good choice for applications that require high availability and scalability.

Service	Description	Use Case	Category
Compute Engine	Provides virtual machines (VMs) that can be used to run applications.	Customizable, scalable, and reliable VMs for a wide range of workloads.	IaaS
Google Kubernetes Engine (GKE)	A service that manages Kubernetes clusters.	Managed Kubernetes cluster for deploying, scaling, and managing containerized applications.	PaaS
App Engine	A fully managed platform that allows you to run web applications and mobile backends.	Run web applications and mobile backends without having to worry about managing servers or infrastructure.	PaaS
Cloud Functions	A serverless function platform that allows you to run code in response to events.	Run code in response to events, such as HTTP requests, database changes, or file uploads.	FaaS
Cloud Run	A serverless compute platform that allows you to run stateless containers that are invocable via HTTP requests.	Run stateless containers that do not require persistent storage or state management.	FaaS

Storage and Database Options

Storage Options:

Service	Description	Use Case
Cloud Storage	Object storage service for storing large amounts of data.	Storing static content, such as images, videos, and documents.
Cloud Firestore	Document database service for storing data as JSON documents.	Running mobile applications that require real-time data synchronization.
Persistent Disks	Durable, high-performance block storage devices that are attached to Compute Engine virtual machines (VMs).	Storing data that needs to be persistent, such as the operating system, applications, and user data.

• Cloud Storage is a good choice for storing static content, such as images, videos, and documents. It is also a good choice for storing backup data and logs.
  • Standard storage class is a good choice for frequently accessed data. It offers high performance and availability.
  • Nearline storage class is a good choice for data that is accessed less frequently. It offers lower costs than Standard storage class, but it has a longer retrieval time.
  • Coldline storage class is a good choice for data that is accessed even less frequently. It offers the lowest costs of all the storage classes, but it has the longest retrieval time.
  • Archive storage class is a good choice for data that is accessed rarely or not at all. It offers the lowest costs of all the storage classes, but it has the longest retrieval time and the lowest performance.
• Cloud Firestore is a good choice for running mobile applications that require real-time data synchronization. It is a document database, so it is well-suited for storing data as JSON documents.
• Persistent Disks are durable, high-performance block storage devices that are attached to Compute Engine virtual machines (VMs).

Database Options:

Service	Description	Use Case
Cloud SQL	Managed database service for MySQL, PostgreSQL, and SQL Server.	Running relational databases.
Cloud Spanner	Globally consistent and scalable relational database service.	Running mission-critical applications that require strong consistency and high availability.
Cloud Bigtable	Wide column store database service for storing large amounts of unstructured data.	Running big data applications, such as analytics and machine learning.
Cloud Datastore	NoSQL database service for storing structured data.	Running web applications and mobile backends that require high performance and scalability.
Cloud Firestore	Document database service for storing data as JSON documents.	Running mobile applications that require real-time data synchronization.
Cloud Memorystore	In-memory data store for Redis and Memcached.	Running high-performance applications that require low latency.

Here are some additional details about the different Database Options in Google Cloud:

• Cloud SQL is a good choice for running relational databases. It is a managed service, so you do not have to worry about managing the underlying infrastructure.
• Cloud Spanner is a good choice for running mission-critical applications that require strong consistency and high availability. It is a globally consistent database, so your data will be available from anywhere in the world.
• Cloud Datastore is a good choice for running web applications and mobile backends that require high performance and scalability. It is a NoSQL database, so it is well-suited for storing large amounts of unstructured data.
• Cloud Bigtable is a good choice for running big data applications, such as analytics and machine learning. It is a wide column store database, so it is well-suited for storing large amounts of semi-structured data.
• Cloud Firestore is a good choice for running mobile applications that require real-time data synchronization. It is a document database, so it is well-suited for storing data as JSON documents.
• Cloud Memorystore is a good choice for running high-performance applications that require low latency.

Networking Services

Networks, Firewalls and Routes

the instructor discusses the different networking services that are available on Google Cloud. He starts by talking about VPC networks, which are isolated virtual networks that you can create in Google Cloud. He then discusses subnets, which are subnetworks within a VPC network. Subnets allow you to further divide your network and control access to specific resources.

The instructor then talks about firewall rules, which control the traffic that is allowed to flow in and out of your VPC networks and subnets. He also discusses load balancing, which distributes traffic across multiple instances of your applications. This can help to improve performance and availability.

Finally, the instructor talks about VPN tunnels and Cloud Interconnect. VPN tunnels allow you to connect your Google Cloud resources to your on-premises network. Cloud Interconnect provides a high-speed, dedicated connection between your Google Cloud resources and your on-premises network.

Here are some additional points to note from this section:

• Google Cloud offers a wide range of networking services, so you can choose the ones that are right for your needs.
• The Networking Services section of the course covers the basics of networking in Google Cloud, so you will be well-prepared to create and manage your own networks.
• The course also includes hands-on exercises, so you can practice what you have learned.

I hope this summary is helpful. Please let me know if you have any other questions.

Here are some specific points that the instructor made in this section:

• VPC networks are a great way to isolate your resources and control your network traffic.
• Subnets allow you to further divide your network and control access to specific resources.
• Firewall rules are essential for controlling the traffic that is allowed to flow in and out of your networks.
• Load balancing can help to improve the performance and availability of your applications.
• VPN tunnels and Cloud Interconnect allow you to connect your Google Cloud resources to your on-premises network.

Resource Hierarchy

• Resources are the basic building blocks of Google Cloud. They can be anything from virtual machines to databases to storage buckets.
• Projects are a way to organize your resources. You can create multiple projects and assign different resources to each project.
• Organizations are a way to group projects together. This can be useful for managing large numbers of projects or for enforcing security policies across multiple projects.
• Folders are a way to organize projects and organizations. You can create folders to group related projects and organizations together.

The resource hierarchy in Google Cloud is as follows:

• Resource
  • Project
    • Folder
      • Organization

The instructor in the video also mentions that you can use the Cloud Console to view the resource hierarchy for your account.

Here are some additional points to note about resource hierarchy:

• The resource hierarchy is a way to organize your resources for better management and control.
• You can use the resource hierarchy to enforce security policies across your projects and organizations.
• The resource hierarchy is a hierarchical structure, meaning that each resource can only be a child of one parent resource

1. Organization: Represents the entire company or domain, in this case, "bowtieinc.co". All resources and entities within Google Cloud belong to and are organized under an organization. Policies set at the organization level are inherited by every resource beneath it.
2. Folders: You can think of folders as containers or categories to further segment and organize projects or other resources. They can represent departments, teams, or any other divisional structure. In our example, Tony Bowtie is a member of "Department B", which is represented by a folder.
3. Projects: Within GCP, projects are core organizational units, and they contain all the service-level resources. In our example, "Department B" has two projects: Project X and Project Y.
4. Resource: This represents any service-level entity created within Google Cloud, such as VM instances, storage buckets, databases, etc.

In the example:

• Tony Bowtie's Permissions: Tony's manager, Lark, set a policy on the "Department B" folder (which could represent a department or a team) that grants Tony the "Project Owner" role. Because this permission was set at the folder level, and folders can contain multiple projects, Tony inherits this "Project Owner" role for both Project X and Project Y. This demonstrates how permissions set at a higher level in the hierarchy cascade downwards.
• Laura's Permissions: At the same time, Lark gave Laura the "Cloud Storage Admin" role, but only on Project X. This means Laura has permission to manage cloud storage buckets only within Project X, and this role does not affect Project Y. This is an example of more granular, project-level permission.

The key takeaway here is understanding how the GCP resource hierarchy functions. IAM policies set at a higher level (like the organization or folder level) will cascade and be inherited by resources below. However, if you set permissions at a specific project or resource level, it applies only to that particular entity.

This approach provides a lot of flexibility. It allows you to set broad permissions where needed, while still maintaining the ability to finely tune access at lower levels when necessary. It also underscores the importance of being careful when setting permissions, especially at higher hierarchy levels, as they will impact a wide range of resources.

Cloud Billing

Identity and Access Management

policies

Google IAM Best Practices

Certainly! Here's a list of best practices for Cloud Identity and Access Management (IAM):

1. Principle of Least Privilege (PoLP): Assign only the minimum permissions necessary for a user or service account to perform their tasks. This helps limit potential security risks.
2. Use Predefined Roles: Prefer predefined roles provided by the cloud platform over custom roles. These roles are well-defined and have least privilege principles built in.
3. Granularity: Assign roles at the smallest scope necessary. Avoid assigning broad roles like "Owner" or "Editor" unless absolutely needed. Use more specific roles whenever possible.
4. Resource Hierarchy: Organize your cloud resources in a way that mirrors your organizational structure. This makes it easier to manage and apply IAM policies consistently.
5. Use Projects to Group Resources: Group resources with the same trust boundaries into projects. This simplifies management and access control.
6. Organizational-Level Policies: Set IAM policies at the organization level when appropriate. This ensures consistent access control across all projects.
7. Folder-Level Permissions: When granting access across multiple projects, consider assigning permissions at the folder level. This provides a structured way to manage access.
8. Service Account Isolation: Create separate service accounts for different applications or components. This limits the scope of access and enhances security.
9. Service Account Key Rotation: Regularly rotate service account keys to minimize the risk of compromise. Ensure a smooth transition from old keys to new ones.
10. Name Service Accounts and Keys Meaningfully: Use descriptive names for service accounts and keys to understand their purpose and permissions at a glance.
11. Audit Logs: Regularly review cloud audit logs to monitor changes to IAM policies and identify unauthorized access or changes.
12. Access Restrictions to Audit Logs: Restrict access to audit logs to only those who need it. Ensure that unauthorized users cannot view these logs.
13. Google Groups for Role Assignments: Assign roles to Google Groups rather than individual users. It simplifies user management, especially when adding or removing members.
14. Regular Review of Permissions: Periodically review and update IAM policies to align with changing organizational needs and security requirements.
15. Export Audit Logs for Long-Term Retention: Export audit logs to cloud storage for long-term retention and compliance purposes.
16. Avoid Storing Keys in Code or Public Locations: Never store service account keys in source code or public directories, as this can lead to security vulnerabilities.
17. Restrict Permissions for Service Account Key Access: Limit access to service account keys to only authorized personnel.
18. Regularly Audit Service Account Key Access: Audit who is accessing service account keys to detect misuse or unauthorized access.
19. Educate and Train Personnel: Provide training and education to your team members to ensure they understand and follow IAM best practices.
20. Follow Cloud Platform's Documentation: Stay updated with the cloud platform's official documentation for best practices and security recommendations.

Network Refresher

1. Introduction to Networking:
   • Computers were initially standalone and couldn't communicate.
   • Networking allowed computers to share data and resources.
   • IP addresses are used to identify computers on a network, similar to street addresses for homes.
2. The OSI Model:
   • The OSI (Open Systems Interconnection) model consists of seven layers.
   • Layer 3 (Network Layer) and Layer 4 (Transport Layer) are discussed in detail.
   • Layer 7 (Application Layer) includes various networking protocols like HTTP, HTTPS, DNS, and SSH.
3. IPv4:
   • IPv4 addresses are represented in dotted decimal notation (e.g., 192.168.1.1).
   • There are classes (A, B, C) of IP addresses with different ranges.
   • Classless Inter-Domain Routing (CIDR) is a more efficient way to allocate IP addresses.
4. IPv6:
   • IPv6 addresses are 128-bit hexadecimal values.
   • Zero compression (::) is used to abbreviate long sequences of zeros.
   • IPv6 addresses are typically written as network addresses with a prefix (e.g., 2001:de3::/64).
5. Transport Layer Protocols:
   • TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are discussed.
   • Packets contain source and destination IP addresses, protocol, port numbers, and data.
6. Application Layer Protocols:
   • Layer 7 includes various protocols like HTTP, HTTPS, DNS, and SSH.
   • These protocols enable networked applications to perform user activities.
7. Subnetting:
   • Subnetting is dividing a network into smaller subnetworks.
   • Subnet masks (CIDR notation) define network boundaries.
8. Private IP Address Ranges:
   • Certain IP address ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are reserved for private networks.
   • Network Address Translation (NAT) is used for private networks to communicate over the public internet.
9. IPv6 Abbreviations:
   • IPv6 addresses can be abbreviated to remove redundant zeros and use double colons (::).
10. OSI Layer Summary:
    • Layer 3 (Network Layer) handles routing and IP addressing.
    • Layer 4 (Transport Layer) manages data transfer with protocols like TCP and UDP.
    • Layer 7 (Application Layer) encompasses various networking protocols for applications.

Virtual Private Cloud (VPC)

A Virtual Private Cloud (VPC) on Google Cloud Platform (GCP) is a logically isolated section of the GCP network. It allows you to create your own private cloud environment within the GCP public cloud. VPCs provide you with control over your network traffic, including the ability to define your own IP address ranges, subnets, and routing tables. You can also use VPCs to create firewalls and other security measures to protect your resources.

Here are some of the key benefits of using a VPC on GCP:

• Security: VPCs provide a layer of security between your GCP resources and the public internet. This can help to protect your resources from unauthorized access and attack.
• Isolation: VPCs allow you to isolate your GCP resources from other GCP customers. This can help to improve the performance and reliability of your resources.
• Predictability: VPCs provide a predictable network environment for your GCP resources. This can help to reduce the risk of outages and performance problems.
• Flexibility: VPCs are very flexible and can be customized to meet your specific needs. For example, you can create multiple subnets within your VPC, each with its own IP address range and routing table.

VPC Network Subnets

Routes

IP Address

Ephemeral IP address: An ephemeral IP address is an IP address that is assigned to a resource for a limited period of time. Ephemeral IP addresses are typically used for resources that are not publicly accessible, such as internal compute engines or load balancers.

Internal IP address: An internal IP address is an IP address that is used to communicate within a VPC network. Internal IP addresses are not accessible from the public internet.

External IP address: An external IP address is an IP address that is used to communicate with the public internet. External IP addresses are typically assigned to resources that need to be accessible from the public internet, such as web servers or load balancers.

Alias IP address: An alias IP address is an additional IP address that can be assigned to a resource. Alias IP addresses are typically used to provide multiple IP addresses for a single resource, such as a web server with multiple domains.

Real-life example:

A company has a VPC network with two compute engines: a web server and a database server. The web server needs to be accessible from the public internet, so it is assigned an external IP address. The database server does not need to be accessible from the public internet, so it is assigned an ephemeral IP address.

The company also has a load balancer that is used to distribute traffic between the web server and the database server. The load balancer is assigned an alias IP address. This allows the company to use a single IP address for the load balancer, even though it is distributing traffic to two different compute engines.

Another example:

A company has a web server that is used to host multiple websites. The company wants to use a different IP address for each website. To do this, the company assigns an alias IP address to the web server for each website.

Alias IP addresses can also be used to provide redundancy. For example, a company can assign two alias IP addresses to a web server. If one IP address becomes unavailable, the company can switch to the other IP address.

Overall, ephemeral IP addresses, internal IP addresses, external IP addresses, and alias IP addresses are all important concepts in GCP networking. Understanding these concepts can help you to design and manage your GCP networks more effectively.

The diagram you provided appears to be using the Mermaid syntax, which is often used to create flowcharts and diagrams in text form. This particular diagram seems to be illustrating different types of IP addresses and concepts related to IP addressing within Google Cloud Platform (GCP). Let's break down each part of the diagram with explanations and real-life examples:

1. Internal (Private) IP Address (A):

• This represents an internal, private IP address. In GCP, this would typically be an IP address assigned to a resource that is used for communication within a Virtual Private Cloud (VPC) network.
• Example: An internal IP address assigned to a virtual machine (VM) inside a GCP VPC. This IP address can be used for communication between VMs within the same VPC.

2. External (Public) IP Address (B):

• This represents an external, public IP address. In GCP, this is typically used for resources that need to be accessible from the internet.
• Example: An external IP address assigned to a Load Balancer in GCP. This IP address allows users from the internet to access a web application running on a group of VMs behind the Load Balancer.

3. OPTIONAL (C):

• This node seems to represent options or configurations related to the external (public) IP address (B).
• It branches out into several options: Alias IP, Auto, Custom, Ephemeral, and Static.

4. Alias IP (D):

• Alias IP is a concept used in GCP for assigning multiple IP addresses to a network interface of a VM.
• Example: You might assign multiple Alias IP addresses to a VM in a VPC to enable it to serve different services on different IP addresses.

5. Auto (E):

• Auto might refer to automatic IP addressing, where GCP automatically assigns an IP address to a resource.
• Example: When you create a VM in GCP, it can be configured to automatically receive an internal and/or external IP address.

6. Custom (F):

• Custom likely represents the ability to manually configure IP addresses according to your specific requirements.
• Example: You might manually assign a specific IP address to a VM in GCP to ensure it always uses the same IP for consistent communication.

7. Ephemeral (G):

• Ephemeral IP addresses are temporary public IP addresses that are automatically assigned to resources but may change if the resource is stopped or restarted.
• Example: When you start a GCP VM without specifying a static external IP, it is assigned an ephemeral IP address that may change if the VM is stopped and started again.

8. Static (H):

• Static IP addresses are permanent public IP addresses that you can reserve and assign to resources to ensure they always have the same IP, even after stopping and starting.
• Example: You might reserve a static external IP address in GCP and assign it to a critical service to ensure that it always has the same public IP for external access.

9. PROMOTE TO STATIC (I):

• This option might represent the ability to convert an ephemeral IP address to a static IP address.
• Example: If you initially use an ephemeral IP address for a service and later decide it needs a static IP, you can promote the ephemeral IP to a static IP in GCP.

In summary, this diagram represents various IP addressing concepts within Google Cloud Platform, including internal and external IP addresses, options for configuring IP addresses, and the distinction between static and ephemeral IP addresses. These concepts are crucial for designing and managing network resources in GCP.

Scenario: You are a Cloud Engineer tasked with setting up a highly available web application in GCP. The application consists of multiple virtual machines (VMs) behind a load balancer, and you need to configure the IP addresses for these VMs and the load balancer.

Step 1: Internal (Private) IP Addresses (A):

• First, you create a Virtual Private Cloud (VPC) network in GCP.
• You assign internal (private) IP addresses to each of the VMs within the VPC. These IP addresses are used for communication between the VMs and are not accessible from the internet.
• Example: VM1 has an internal IP address of 10.0.0.2, and VM2 has an internal IP address of 10.0.0.3.

Step 2: External (Public) IP Addresses (B):

• You set up a load balancer in GCP to distribute incoming internet traffic across your VMs.
• The load balancer needs a public IP address (external IP) so that users can access your web application from the internet.
• Example: The load balancer is assigned an external IP address of 203.0.113.1.

Step 3: Alias IP (D):

• To optimize your architecture, you decide to run multiple services on each VM, each requiring its own IP address.
• You use the Alias IP feature to assign multiple IP addresses to each VM's network interface. This allows each service to have a dedicated IP.
• Example: VM1 has an alias IP of 10.0.0.4, which is used for the web server, and an alias IP of 10.0.0.5, which is used for a database service.

Step 4: Static (H) and PROMOTE TO STATIC (I):

• You want the load balancer's external IP address to remain constant to ensure uninterrupted service even if the load balancer is stopped and started.
• You reserve a static external IP address (203.0.113.1) and assign it to the load balancer. This ensures the IP address remains the same.
• Later, you decide to promote an ephemeral external IP address assigned to one of the VMs to a static IP because it's hosting a critical component of your application that should always have the same IP address.
• Example: The load balancer uses the reserved static external IP (203.0.113.1), and VM2's ephemeral IP (198.51.100.2) is promoted to a static IP (198.51.100.3) for consistency.

Step 5: Custom (F) and Ephemeral (G):

• For certain VMs in your environment, you may need to customize their IP addresses. For example, a specialized analytics VM requires a specific internal IP for data processing.
• Other VMs, like development instances, can use ephemeral internal IPs because they don't need consistent IP addresses.
• Example: The analytics VM is assigned a custom internal IP of 10.0.0.6, while development VMs use ephemeral IPs.

In this scenario, you've applied various IP addressing concepts within GCP to create a resilient and scalable architecture for your web application. You've used internal and external IP addresses, configured alias IPs for service separation, reserved static IPs for critical components, and customized IPs as needed. This demonstrates how these IP concepts are interconnected and can be leveraged to design a robust cloud infrastructure in GCP

Creating Internal and External Static IP Addresses

Key Points:

1. Static IP Addresses: The demo focuses on creating and managing both internal and external static IP addresses in Google Cloud Platform (GCP).
2. Project and Default VPC: The demo assumes the use of a GCP project (in this case, "bowtieinc dev") with a default Virtual Private Cloud (VPC) created.
3. Creating a Static Internal IP Address:
   • Use the GCP Console.
   • Navigate to Compute Engine.
   • Create a new VM instance.
   • Select "Reserve Static Internal IP Address" and provide the necessary details (e.g., name).
   • The IP address persists even after the VM is deleted.
4. Viewing IP Addresses:
   • IP addresses can be viewed in the GCP Console under VPC networks or queried through the command line using gcloud compute addresses list.
5. Promoting an Ephemeral Internal IP Address:
   • Convert an ephemeral internal IP address to a static one by editing the network interface of a VM instance.
6. Creating a Static External IP Address:
   • Use the GCP Console under VPC networks to create a static external IP address.
   • Assign it to a VM instance during creation.
7. Promoting an Ephemeral External IP Address:
   • Promote an ephemeral external IP address to a static one using the gcloud compute addresses create command.
8. Cleanup: It's essential to delete instances and IP addresses that are no longer needed to avoid unnecessary charges.

Real-Life Example Scenario for the Demo:

Imagine you're a cloud infrastructure administrator responsible for managing a set of virtual machines (VMs) and IP addresses in a GCP project for a web application. Here's how the key points apply to this scenario:

1. Static IP Addresses: You need static IP addresses to ensure consistent access to your VMs and services.
2. Project and Default VPC: Your GCP project is named "WebAppProj," and you've set up a default VPC for networking.
3. Creating a Static Internal IP Address: You create a static internal IP address named "webapp-internal-ip" to ensure that a critical backend service always has the same IP address, even if you delete and recreate VM instances.
4. Viewing IP Addresses: You regularly check IP addresses through the GCP Console and use gcloud compute addresses list to verify IP address assignments.
5. Promoting an Ephemeral Internal IP Address: You realize that one of your VM instances, "webapp-backend," needs a static IP address. You promote its ephemeral internal IP to a static one to ensure stability.
6. Creating a Static External IP Address: You create a static external IP address named "webapp-external-ip" to associate it with a load balancer for your web application. This ensures that your application always has a consistent external IP for traffic.
7. Promoting an Ephemeral External IP Address: A new instance, "webapp-api-server," initially has an ephemeral external IP address. You promote it to a static external IP address to ensure reliability for external API consumers.
8. Cleanup: After a project phase is complete, you diligently clean up unused resources, such as deleting instances and releasing IP addresses that are no longer needed.

In this scenario, the ability to manage static IP addresses effectively is crucial for maintaining the stability and reliability of your web application on GCP.

VPC Firewall Rules

1. Network: This refers to the Virtual Private Cloud (VPC) network to which the firewall rule is applied. It specifies the network context in which the rule operates.
2. Priority: Priority is a numerical value that determines the order in which rules are applied. Lower numbers indicate higher priority, meaning rules with lower numbers take precedence.
3. Direction of Traffic: This component specifies whether the rule is for incoming connections (ingress) or outgoing connections (egress). Ingress rules control incoming traffic, while egress rules control outgoing traffic.
4. Action on Match: This determines the action taken when the rule matches traffic. It can be set to "allow" to permit the connection or "deny" to block it.
5. Target: The target specifies which instances the rule applies to. It can target all instances in the network, instances with specific network tags, or instances with specific service accounts.
6. Source Filter: This is applicable to ingress rules and specifies the source of incoming traffic. It can be based on source IP ranges, source network tags, or source service accounts.
7. Protocols and Ports: This component allows you to specify the protocols (e.g., TCP, UDP) and port numbers associated with the traffic that the rule applies to. Omitting both protocols and ports makes the rule applicable to all traffic.
8. Enforcement Status: You can enable or disable the enforcement of the firewall rule using this setting. Disabling a rule temporarily stops it from taking effect, which can be useful for troubleshooting or granting temporary access.

Custom VPC

What we will be building,

The image you sent shows a diagram of a simple GCP network architecture. The network consists of a VPC network with a public subnet and a private subnet. The public subnet is accessible from the public internet, while the private subnet is not.

The VPC network also has a Cloud Load Balancing (CLB) instance, which is used to distribute traffic to the web servers in the private subnet. The CLB instance has a public IP address, which is used by clients to access the web servers.

The web servers in the private subnet are protected by a firewall, which only allows traffic from the CLB instance to reach them.

The diagram also shows a bastion host, which is a server in the public subnet that is used to access the servers in the private subnet. The bastion host is protected by a firewall, which only allows traffic from trusted IP addresses to reach it.

This network architecture is secure because it isolates the web servers in the private subnet from the public internet. The only way to access the web servers is through the CLB instance, which is protected by a firewall. The bastion host can be used to access the servers in the private subnet, but it is also protected by a firewall.

Here is a more detailed explanation of each component in the diagram:

• VPC network: A VPC network is a virtual private network that is isolated from the public internet. VPC networks allow you to create a private network for your resources, such as virtual machines, load balancers, and databases. This gives you more control over your network environment and helps to protect your data from unauthorized access.
• Public subnet: A public subnet is a subnet in a VPC network that is accessible from the public internet. Public subnets are typically used for resources that need to be accessible from the public internet, such as web servers and load balancers.
• Private subnet: A private subnet is a subnet in a VPC network that is not accessible from the public internet. Private subnets are typically used for resources that do not need to be accessible from the public internet, such as databases and application servers.
• Cloud Load Balancing (CLB) instance: A CLB instance is a load balancer that distributes traffic across multiple servers. CLB instances are typically used to improve the performance and reliability of applications.
• Firewall: A firewall is a security device that filters traffic between two networks. Firewalls can be used to block unauthorized traffic and protect your resources from attack.
• Bastion host: A bastion host is a server in the public subnet that is used to access resources in a private network from the public internet. Bastion hosts are typically protected by a firewall, which only allows traffic from trusted IP addresses to reach them.

Here are some of the benefits of using this network architecture:

• Security: This network architecture is secure because it isolates the web servers in the private subnet from the public internet. The only way to access the web servers is through the CLB instance, which is protected by a firewall.
• Performance: This network architecture can improve the performance of your applications by using a CLB instance to distribute traffic across multiple web servers.
• Control: This network architecture gives you more control over your network environment. You can use firewalls to control which traffic is allowed to flow between the different subnets.
• Cost: This network architecture can help you to reduce your cloud costs by optimizing your network resources. For example, you can use private subnets for resources that do not need to be accessible from the public internet.

Create Custom VPC and Subnets:

1. Create Custom VPC Network:

   gcloud compute networks create [NETWORK_NAME] --subnet-mode custom
   

2. Create Public Subnet:

   gcloud compute networks subnets create [PUBLIC_SUBNET_NAME] --network [NETWORK_NAME] --range [PUBLIC_IP_RANGE]
   

3. Create Private Subnet:

   gcloud compute networks subnets create [PRIVATE_SUBNET_NAME] --network [NETWORK_NAME] --range [PRIVATE_IP_RANGE]
   

Create and Configure Firewall Rules:

1. Create Firewall Rule for Public Access:

   gcloud compute firewall-rules create public-access --network [NETWORK_NAME] --action allow --direction ingress --rules tcp:22,icmp --source-ranges 0.0.0.0/0 --target-tags public
   

2. Create Firewall Rule for Private Access:

   gcloud compute firewall-rules create private-access --network [NETWORK_NAME] --action allow --direction ingress --rules tcp:22,icmp --source-ranges [PRIVATE_IP_RANGE] --target-tags private
   

Test the Configuration:

1. SSH into Public Instance:

   gcloud compute ssh [PUBLIC_INSTANCE_NAME]
   

2. Check Access to Cloud Storage:

   gsutil ls -p [PROJECT_NAME] -b gs://[BUCKET_NAME]
   

3. Ping Private Instance from Public Instance:

   ping [PRIVATE_INSTANCE_IP]
   

4. SSH into Private Instance from Public Instance:

   gcloud compute ssh [PRIVATE_INSTANCE_NAME] --internal-ip
   

5. Enable Private Google Access on Private Subnet:

• Go to GCP Console > VPC Network > Select Private Subnet > Edit > Enable "Private Google Access"

1. Re-check Access to Cloud Storage on Private Instance:

gsutil ls -p [PROJECT_NAME] -b gs://[BUCKET_NAME]

Cleanup:

1. Delete All Resources:
   • Delete the VPC, subnets, instances, and firewall rules to clean up the environment.

VPC Peering

VPC Peering Overview:

• VPC peering enables private communication between workloads in different VPC networks.
• Traffic stays within Google's network and does not traverse the public internet.
• Peering can occur between VPCs in the same or different projects and even across different organizations.
• Benefits of VPC peering include reduced network latency, improved network security, and cost savings on egress traffic.

Characteristics of Peered VPCs:

• Peered VPCs remain administratively separate, with independent routing, firewalls, and other traffic management.
• Each side of a peering association is set up independently.
• Peering becomes active only when the configuration from both sides matches.
• Each VPC can delete the peering association independently.

Routing and Routes:

• VPC peers exchange all subnet routes.
• Custom routes, subnet routes, and static routes can be exchanged.
• A VPC network can peer with multiple VPC networks (with limits).
• Subnet CIDR ranges in peered VPCs cannot overlap with static routes in other peered networks.
• Overlapping subnet IP ranges across VPC networks with a common peer network are not allowed.

Routing Controls:

• VPC peering does not provide granular route controls; route filtering is handled by firewall rules.
• Ingress traffic to VM instances in a peer network requires creating ingress allow firewall rules.

Transitive Peering:

• Transitive peering is not supported; only directly peered networks can communicate.
• To communicate from Network A to Network C, Network A must be directly peered with Network C.

Tags and Service Accounts:

• Tags or service accounts from one peered network cannot be used in the other; each network operates independently.

Internal DNS:

• Internal DNS is not accessible for Compute Engine instances in peered networks; IP addresses must be used for communication.

DEMO

Demo Process: Creating VPC Peering Connection

1. Network Setup
   • Create two separate VPC networks in different projects:
     • Project Tony: bowtie_inc-a
     • Project Bowtie Inc: bowtie_inc-b
   • Define subnets within each network with non-overlapping IP ranges.
2. Firewall Rules
   • In each project, create firewall rules to allow traffic between instances:
     • Project Tony: project-tony-a
     • Project Bowtie Inc: bowtie-inc-b
3. Instance Creation
   • Create instances in both networks:
     • Project Tony: instance-a
     • Project Bowtie Inc: instance-b
   • Set the network interface of each instance to the corresponding VPC network.
4. VPC Peering Configuration
   • Go to Project Tony:
     • Navigate to VPC Network > VPC Network Peering.
     • Click "Create Connection."
     • Fill in the peering connection details:
       • Name: peering-a-b
       • VPC Network: bowtie_inc-a
       • Peered VPC Network: bowtie_inc-b
     • Leave other options as default and create the connection.
   • Go to Project Bowtie Inc:
     • Create a peering connection following the same steps:
       • Name: peering-b-a
       • VPC Network: bowtie_inc-b
       • Peered VPC Network: bowtie_inc-a
5. Verification
   • Obtain the internal IP of one instance in either network.
   • SSH into an instance in the other network and perform a ping test using the internal IP of the first instance.
     • Example: ping <internal_IP>
   • Ensure successful communication between the instances, confirming that the VPC peering connection is working.
6. Resource Cleanup
   • Delete instances, firewall rules, and VPC networks in both projects to clean up resources.

Shared VPC

Shared VPC Concepts and Terminology:

• Shared VPCs allow resources from multiple projects to connect to a common VPC network.
• A host project designates the VPC networks to be shared, and service projects are attached to the host project.
• A project can be either a host project or a service project, not both simultaneously.
• Shared VPC admin roles have permissions to enable host projects, attach service projects, and delegate access.
• Service project admins can have project-level or subnet-level permissions within the shared VPC.

Use Case: Simple Shared VPC Scenario:

• Service projects are attached to a host project.
• Service project admins configure access to specific subnets within the shared VPC.
• Instances in service projects can communicate using internal IPs.

Use Case: Multiple Host Projects:

• An organization can have multiple host projects, each with its service projects.

• Subnets in different host projects can use the same IP ranges.

• Resource management remains separate within each host project.

  

Use Case: Hybrid Environment:

• A single host project is connected via Cloud VPN to an on-premises network.

• Some services are in GCP, and others remain on premises.

• Service project admins are granted permissions for communication and billing.

  

Use Case: Two-Tier Web Service:

• Two tiers of a web service are managed by different teams.
• Shared VPC allows both tiers to use a common VPC network.
• Resources are shared while enabling separate management for each tier.

VPC Flow Logs

DNS Fundamental