Creating an Cloud Storage Bucket

1.In the Google Cloud console, in the Navigation menu (Navigation menu icon), click Cloud Storage > Buckets.

Note :A bucket must have a globally unique name.

2.Create

3.Specify the following, and leave the remaining settings as their defaults:

- Name : Enter a globally unique name

- Location type : Region

- Region : Select Region

- Enforce public access prevention on this bucket : unchecked

- Access control : Fine-grained

4.Make a note of the bucket name. It will be used later in this lab and referred to as [BUCKET_NAME].

5.Click Create.

## Download a sample file using CURL and make two copies

1.In the Cloud console, click Activate Cloud Shell

2.If prompted, click Continue.

3.Store [BUCKET_NAME] in an environment variable:

export BUCKET_NAME=<enter bucket name here>

4.Verify it with echo:

echo $BUCKET_NAME

5.Run the following command to download a sample file (this sample file is a publicly available Hadoop documentation HTML file):

curl \

https://hadoop.apache.org/docs/current/\

hadoop-project-dist/hadoop-common/\

ClusterSetup.html > setup.html

6.To make copies of the file, run the following commands:

cp setup.html setup2.html

cp setup.html setup3.html

Access control lists

**Task 2: Access control lists (ACLs)**

You set access control lists to restrict access to the file that you copy to the Cloud Storage bucket.

Copy the file to the bucket and configure the access control list

1.Run the following command to copy the first file to the bucket:

gcloud storage cp setup.html gs://$BUCKET_NAME/

2.To get the default access list that’s been assigned to setup.html, run the following command:

gsutil acl get gs://$BUCKET_NAME_1/setup.html > acl.txt

cat acl.txt

3.To set the access list to private and verify the results, run the following commands:

gsutil acl set private gs://$BUCKET_NAME_1/setup.html

gsutil acl get gs://$BUCKET_NAME_1/setup.html > acl2.txt

4.To update the access list to make the file publicly readable, run the following commands:

gsutil acl ch -u AllUsers:R gs://$BUCKET_NAME_1/setup.html

gsutil acl get gs://$BUCKET_NAME_1/setup.html > acl3.txt

cat acl3.txt

Enable lifecycle management

Task 3: Enable lifecycle management

In this task, you enable lifecycle management for a Cloud Storage bucket to automate the deletion of objects after a specified period.

View the current lifecycle policy for the bucket

- Run the following command to view the current lifecycle policy:

gsutil lifecycle get gs://$BUCKET_NAME

Note: There is no lifecycle configuration. You create one in the next steps.

### Create a JSON lifecycle policy file

1.To create a file named life.json, run the following command:

`nano life.json`

2.Paste the following value into the life.json file:

{

“rule”:

[

{

“action”: {”type”: “Delete”},

“condition”: {”age”: 31}

}

]

}

Note: These instructions tell Cloud Storage to delete the object after 31 days.

3.Press Ctrl+O, ENTER to save the file, and then press Ctrl+X to exit nano.

### Set the policy and verify

1.To set the policy, run the following command:

gsutil lifecycle set life.json gs://$BUCKET_NAME

2.To verify the policy, run the following command:

gsutil lifecycle get gs://$BUCKET_NAME

Enable versioning

Task 4 : Enable Versioning

In this task, you enable versioning for a Cloud Storage bucket to protect data from accidental deletion or modification.

View the versioning status for the bucket and enable versioning

1.Run the following command to view the current versioning status for the bucket:

gsutil versioning get gs://$BUCKET_NAME

2.To enable versioning, run the following command:

gsutil versioning set on gs://$BUCKET_NAME

3.To verify that versioning was enabled, run the following command:

gsutil versioning get gs://$BUCKET_NAME

💬 If you enjoyed reading this blog post and found it informative, please take a moment to share your thoughts by leaving a review and liking it 😀 and follow me in [dev.to](https://dev.to/srinivasuluparanduru) , [linkedin](https://linkedin.com/in/srinivasuluparanduru), [github](https://github.com/srinivasuluparanduru)

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "7.31.0"
    }
  }
}

provider "google" {
  # Configuration options
  project = "Replace-with-project-id"
}

#############################################################

resource "google_compute_instance" "instance-20260507-161631" {
  boot_disk {
    auto_delete = true
    device_name = "instance-20260507-161631"

    initialize_params {
      image = "projects/debian-cloud/global/images/debian-12-bookworm-v20260505"
      size  = 10
      type  = "pd-balanced"
    }

    mode = "READ_WRITE"
  }

  can_ip_forward      = false
  deletion_protection = false
  enable_display      = false

  labels = {
    goog-ec-src           = "vm_add-tf"
    goog-ops-agent-policy = "v2-template-1-7-0"
  }

  machine_type = "e2-medium"

  metadata = {
    enable-osconfig = "TRUE"
  }

  name = "instance-20260507-161631"

  network_interface {
    access_config {
      network_tier = "PREMIUM"
    }

    queue_count = 0
    stack_type  = "IPV4_ONLY"
    subnetwork  = "projects/gcp-training-494216/regions/us-central1/subnetworks/default"
  }

  reservation_affinity {
    type = "ANY_RESERVATION"
  }

  scheduling {
    automatic_restart   = true
    on_host_maintenance = "MIGRATE"
    preemptible         = false
    provisioning_model  = "STANDARD"
  }

  service_account {
    email  = "898473385066-compute@developer.gserviceaccount.com"
    scopes = ["https://www.googleapis.com/auth/devstorage.read_only", "https://www.googleapis.com/auth/logging.write", "https://www.googleapis.com/auth/monitoring.write", "https://www.googleapis.com/auth/service.management.readonly", "https://www.googleapis.com/auth/servicecontrol", "https://www.googleapis.com/auth/trace.append"]
  }

  shielded_instance_config {
    enable_integrity_monitoring = true
    enable_secure_boot          = false
    enable_vtpm                 = true
  }

  zone = "us-central1-a"
}

1. In the Google Cloud console, in the Navigation menu (

   

   ), click Compute Engine > VM instances.

2. Click Create Instance.

3. For Name, type a name for your instance. Hover over the question mark icon for advice about what constitutes a properly formed name.

4. For Region and Zone select europe-west3 and europe-west3-c respectively.

5. For Series, select E2.

6. For Machine type, examine the options.

7. For Machine type, select standard > e2-standard-4 (4 vCPUs, 16 GB memory). How did the cost change?

8. For Machine type, select Shared-core > e2-medium (2 vCPUs, 4 GB memory).

9. Click Networking.

10. For Network interfaces, click the dropdown icon.

11. For External IPv4 address, select None.

12. Click Done.

13. Leave the remaining settings as their defaults, and click Create. Wait until the new VM is created.

Note: External IP addresses that don’t fall under the Free Tier of the Google Cloud Free Program will incur a small cost. Learn more about the pricing in the External IP address pricing section of the Virtual Private Cloud Guide.

Explore the VM details

1. On the VM instances page, click on the name of your VM.

2. Locate CPU platform and note the value. Click Edit.

3. Click Cancel.

4. Examine Availability policies.

Explore the VM logs

1. On the VM instance details page for your VM, click Logging.

2. Explore the VM logs

   1. On the VM instance details page for your VM, click Logging.

Task2- Create a Windows virtual machine

Create a VM

1. In the Google Cloud console, in the Navigation menu (

), click Compute Engine > VM instances.

2. Click Create instance.

3. Specify the following:

   

4. For Series, select E2.

5. For Machine type, select standard > e2-standard-2 (2 vCPUs, 8 GB memory).

6. Click OS and storage, and then click Change.

7. For Operating system, select Windows Server.

8. For Version, select Windows Server 2016 Datacenter Core.

9. For Boot disk type, select SSD persistent disk.

10. For Size (GB), enter 64.

11. Click Select.

12. Click Networking.

13. For Firewall, enable Allow HTTP traffic and Allow HTTPS traffic.

14. Click Create.

    ---

    Set the password for the VM

    1. Click on the name of your Windows VM to access the VM instance details.

    2. You don’t have a valid password for this Windows VM: you cannot log in to the Windows VM without a password. Click Set Windows password.

    3. Click Set.

    4. Copy the provided password, and click CLOSE.

    ---

    Task 3 - Create a custom virtual machine

    Create a VM

    1.In the Google Cloud console, in the Navigation menu (

    

    ), click Compute Engine > VM instances.

    2. Click Create instance.

    3.Specify the following:

4. For Series, select E2.

5.For Machine type, click Custom.

6. For Cores, enter 2.

7. For Memory, enter 4 GB.

8. Click OS and storage.

9. If the Image shown is not Debian GNU/Linux 12 (bookworm), click Change and select Debian GNU/Linux 12 (bookworm), and then click Select.

10. Click Create.

Connect via SSH to your custom VM

1. For the custom VM you just created, click SSH.

2. To see information about unused and used memory and swap space on your custom VM, run the following command:

   free

3. To see details about the RAM installed on your VM, run the following command:

sudo dmidecode -t 17

4. To verify the number of processors, run the following command:

   nproc

5. To see details about the CPUs installed on your VM, run the following command:

   lscpu

6. To exit the SSH terminal, run the following command:

   exit

The Google Cloud Associate Cloud Engineer certification exam contains 50-60 questions. These are multiple-choice and multiple-select format questions.

The exam is 2 hours long and tests your ability to deploy applications, monitor operations, manage enterprise solutions, and configure access and security on Google Cloud Platform.

• Partners study path

• Regular users study path

  Join online sessions with GDG Letterkenny by registering using the links in the post

Session1 - Certification Study Group: Becoming a Google Associate Cloud Engineer
Registration link - https://lnkd.in/eTWi2Bpt
Session Date : April 23rd - 4:45 PM - 5:15 PM BST/Irish Time Zone
Speaker : Srinivasulu Paranduru ( Srinivasulu P.)

Session 2 - Certification Study Group: Becoming a Google Associate Cloud Engineer
Registration link - https://lnkd.in/e3VFduQF
Session Date : April 30th - 4:45 PM - 5:15 PM BST/Irish Time Zone
Speaker : Srinivasulu Paranduru ( Srinivasulu P.)

Session 3 - Certification Study Group: Becoming a Google Associate Cloud Engineer
Registration link - https://lnkd.in/enGDfy54
Session Date : May 7th - 4:45 PM - 5:15 PM BST/Irish Time Zone
Speaker : Srinivasulu Paranduru( Srinivasulu P.)

Session 4 - Certification Study Group: Becoming a Google Associate Cloud Engineer
Registration link - https://lnkd.in/exytnJZB
Session Date : May 15th - 4:45 PM - 5:15 PM BST/Irish Time Zone
Speaker : Srinivasulu Paranduru( Srinivasulu P.)

Session 5 - Certification Study Group: Becoming a Google Associate Cloud Engineer
Registration link -https://lnkd.in/e8pu4pz5
Session Date - May 22nd - 4:45 PM - 5:15 PM BST/Irish Time Zone
Speaker : Srinivasulu Paranduru( Srinivasulu P.)

• All registered google email users will be given access to credits for doing practise.

• At the end of last session one lucky winner will get Google Associate Cloud Engineer for free.

• All the recordings will be uploaded in youtube and materials will be shared through blogs

Basics of Packer :

- Packer is an open-source tool for automating the creation of machine images for multiple platforms from a single source configuration.

- A common use case is creating golden images for organizations to use in cloud infrastructure.

Key Concepts:

- Template: JSON or HCL file describing how images are built.
- Builders: Create images for platforms (e.g., AWS, Azure, VirtualBox).
- Provisioners: Install and configure software within the image (e.g., shell scripts).
- Post-processors: Actions after image creation (e.g., compress, upload).

Basic Workflow:
1. Write a template file (e.g., `template.json` or `template.pkr.hcl`).
2. Run `packer init` (for HCL) to initialize plugins.
3. Run `packer build template.pkr.hcl` to create the image.

Packer Architecture

Install Packer & Verify the installation Reference :

https://developer.hashicorp.com/packer/tutorials/aws-get-started/get-started-install-cli

Packer Block

The packer {} block contains Packer settings, including specifying a required Packer version.

In addition, you will find required_plugins block in the Packer block, which specifies all the plugins required by the template to build your image.

packer {
  required_plugins {
    amazon = {
      source  = "github.com/hashicorp/amazon"
      version = "~> 1"
    }
  }
}

Each plugin block contains a version and source attribute.

Source block

• The source block configures a specific builder plugin, which is then invoked by a build block. Source blocks use builders and communicators to define what kind of virtualization to use.

• Builders and communicators are bundled together and configured side-by-side in a source block

• A source can be reused across multiple builds

• A builder plugin is a component of Packer which is responsible for creating a machine and turning that machine into a image.

• A source block has two important labels: a builder type and a name.

In the example template given below, the builder type is amazon-ebs and the name is ubuntu.

source "amazon-ebs" "ubuntu" {
  ami_name      = "learn-packer-linux-aws"
  instance_type = "t2.micro"
  region        = "us-west-2"
  source_ami_filter {
    filters = {
      name                = "ubuntu/images/*ubuntu-jammy-22.04-amd64-server-*"
      root-device-type    = "ebs"
      virtualization-type = "hvm"
    }
    most_recent = true
    owners      = ["099720109477"]
  }
  ssh_username = "ubuntu"
}

• Amazon-ebs builder configuration launches a t2.micro AMI in the us-west-2 region using an ubuntu-jammy AMI as the base image, then creates an image named learn-packer-linux-aws from that instance.

The Build Block

The build block defines what Packer should do with the EC2 instance after it launches.

In the example template, the build block references the AMI defined by the source block above (source.amazon-ebs.ubuntu).

build {
  sources = [
    “source.amazon-ebs.ubuntu”
  ]
}

Initialize Packer configuration

1. Initialize your Packer configuration.

packer init .

2.Format your Packer template

packer fmt .

3.Validate your Packer template

packer validate .

4.Build Packer image - Build the image with the packer build command

packer build aws-ubuntu.pkr.hcl

Visit the AWS AMI page to verify that Packer successfully built your AMI.

Managing the Image

Packer only builds images. It does not attempt to manage them in any way. After they’re built, it is up to you to launch or destroy them as you see fit.

Conclusion: Introduction to Packer

💬 If you enjoyed reading this blog post and found it informative, please take a moment to share your thoughts by leaving a review and liking it 😀 and subscribe me in substack.com for more updates , linkedin, github

What are the measurements taken to observe a software system , they are metrics, logs , traces and they together represented as Telemetry signals.

Telemetry Signals:

• Logs

• Metrics

• Traces

Logs

A log is an append-only data structure that records events occurring in a system. A log entry consists of a timestamp that denotes when something happened and a message to describe details about the event. However, coming up with a standardized log format is no easy task. Way of logging formats totally varies based on project requirements.

Initially, text-based formats catered to human readability. However, as software systems became more complex, the volume of logs soon became unmanageable. To overcome this logs are stored in key/value pairs .

Earlier logs stored in systems and which becomes more burden to the volumes/machine to go through the logs. As a result, people started to build logging agents and protocols to forward logs to dedicated services. These logging systems allowed for efficient storage as well as the ability to search and filter logs in a central location.

Metrics

Four common types of metrics: Counters, Gauges, Histogram and summaries

Logs shine at providing detailed information about individual events. However, sometimes we need a high-level view of the current state of a system. This is where metrics come in. A metric is a single numerical value derived by applying a statistical measure to a group of events.

In other words, metrics represent an aggregate. This is useful because their compact representation allows us to graph how a system changes over time

Traces

• On a single machine, stack traces allow us to track an exception back to a line of code.

• In a distributed environment, we don’t have this luxury. Instead, we perform extensive filtering to locate log events of interest

• To understand the larger context, we need to know specific requests or transactions that initiated the log entry and the sequence of services or microservices involved in processing that request across the system.

• This often results in a lot of manual labor (e.g. comparing timestamps) or requires extensive domain knowledge about the applications.

• Recognizing this problem, Google developed Dapper, which popularized the concept of distributed tracing.

Three pillars of observability

• Telemetry is the process of automatically collecting and transmitting data from remote or distributed systems to monitor, measure, and track the performance or status of those systems.

• Telemetry data provides real-time insights into how different parts of an application are performing.

• Telemetry provides the data for observability tooling to help developers and system administrators observe, troubleshoot, and optimize the system without needing to manually check each component.

Having dedicated systems for logs, metrics, and traces is why we commonly refer to them as the three pillars of observability. The notion of pillars provides a great mental framework because it emphasizes the following:

• There are different categories of telemetry

• Each pillar has its own unique strengths and stands on its own

• Pillars are complementary and must be combined to form a stable foundation for achieving observability

Problems with Our Approach to Observability

With multiple open source and observability solutions available on the market, you might ask a question

• If there are plenty of mature solutions for generating, collecting, storing, and analyzing logs, metrics and traces, why should I care?

• What’s wrong with the current state of observability?

• Oh, great … is this yet another attempt at standardization?

Siloed Telemetry is Difficult to Work With

The only information we currently have is that something happened at a particular point in time.

• The first step is to use the metrics system to look for other metrics showing temporally correlated, abnormal behavior.

• Drill down and investigate the root cause of the problem. To gain additional information, we typically switch to the logging system.

• Unfortunately, traditional logging systems lack the mechanisms to reconstruct the chain of events in that particular transaction.

• Traditional logging systems often fail to capture the full context of an operation, making it difficult to correlate events across different services or components

Lack of Instrumentation Standard Leads to Low Quality Data

• Another factor that makes root-cause analysis hard is that telemetry data often suffers from a lack of consistency.

• This leads to difficulties in correlating events across different services or components, as there is no standardized way to identify related events, such as through trace IDs or span IDs.

Struggling Observability Vendors / High Barrier for Entry

• At first glance, vendors appear to be the only ones profiting from the current situation.

• In the past, high-quality instrumentation was a great way to differentiate yourself from the competition.

• Moreover, since developing integrations for loads of pre-existing software is expensive, the observability market has a relatively high barrier to entry.

• With customers shying away from expensive re-instrumentation, established vendors have faced less competition and pressure to innovate.

What is OpenTelemetry?

• OpenTelemetry (OTel) is an open source project designed to provide standardized tools and APIs for generating, collecting, and exporting telemetry data such as traces, metrics, and logs.

• It aims to give developers deep visibility into applications, helping to monitor, troubleshoot, and optimize software systems.

The main goals of OpenTelemetry are:

• Unified telemetry: Combines tracing, logging, and metrics into a single framework enabling correlation of all data and establishing an open standard for telemetry data.

• Vendor-neutrality: Integration with different backends for processing the data.

• Cross-platform: Supports various languages (Java,Python,Go and C#)and platforms, making it versatile for different development environments.

What OpenTelemetry is NOT

OpenTelemetry is:

• Not an All-in-One Monitoring or Observability Tool
  OpenTelemetry doesn’t replace full-fledged monitoring or observability platforms like Datadog, New Relic, or Prometheus. Instead, it helps collect and standardize telemetry data so that you can send it to these tools for visualization and analysis.

• Not a Data Storage or Dashboarding Solution
  OpenTelemetry doesn’t store or visualize data. It focuses on the collection and export of telemetry data to external systems that handle storage and presentation, such as Grafana, Jaeger, or Prometheus.

• Not a Pre-configured Monitoring Tool
  OpenTelemetry is a toolkit for collecting and exporting data, but it requires configuration and integration with other systems. It doesn’t automatically provide out-of-the-box monitoring or alerting functionality.

• Not a Performance Optimizer
  While OpenTelemetry helps you collect detailed performance data, it doesn’t automatically optimize application performance. It’s a diagnostic tool that helps you gather insights for manual tuning.

OpenTelemetry is an integration and standardization tool for telemetry data, not an all-in-one solution for monitoring, logging, or performance management. It complements other tools by standardizing the data collection process.

OpenTelemetry is a powerful framework that provides developers with the tools to monitor, trace, and log their applications with a unified observability solution.

In today’s digital age, where microservices architectures and cloud-native solutions are prevalent, the ability to observe and understand the behaviour of distributed systems is crucial. There are already many solutions to tackle this, but the solutions, protocols and data formats are not unified nor correlated.

OpenTelemetry addresses the challenges of monitoring modern software environments by offering a unified API and set of tools that can be integrated into various languages, platforms and frameworks.

OpenTelemetry receives so much attention because it promises to be a fundamental shift in the way we produce telemetry.

Highlights

• OpenTelemetry is—a vendor-neutral, open-source tool for collecting and standardizing telemetry data

• OpenTelemetry is not an all-in-one observability platform, but a powerful integration and data collection tool.

• OpenTelemetry addresses the limitations of traditional observability solutions by offering a unified way to gather traces, metrics, and logs in a highly adaptable and cross-platform manner.

References :

https://github.com/magsther/awesome-opentelemetry

Conclusion: Introduction to OpenTelemet4ry

💬 If you enjoyed reading this blog post and found it informative, please take a moment to share your thoughts by leaving a review and liking it 😀 and follow me in substack.com , linkedin, github

Platform engineering is a practice built up from DevOps principles that seeks to improve each development team’s security, compliance, costs, and time-to-business value through improved developer experiences and self-service within a secure, governed framework.

Gartner expects around 80 percent of engineering organizations to have a team dedicated to platform engineering by 2026.

These teams focus on building what's called an internal developer platform.

These platforms include tools that:

• Help developers be self-sufficient (for example, starter kits and IDE plugins).

• Assist with common tasks.

• Encapsulate common patterns and practices into reusable building blocks.

• Provide early advice and feedback on problems or security risks.

• Simplify operations by managing underlying infrastructure and tools.

What is an internal developer platform?

An internal developer platform focuses on a company’s internal development practices. You define a set of recommended and supported development paths to production and incrementally “pave” a way through them with an internal platform.

Developers are the primary consumers or customer of an internal developer platform. Automation and centralization enable efficient operations while ensuring that stakeholder requirements like compliance are met.

With platform engineering, you create this internal platform by combining a product mindset with learnings from DevOps and DevSecOps to deliver a set of tools. These tools provide sufficient automation, tracking, governance, and observability that guide development teams naturally “into the pit of success.”

Platform engineering was adopted for increasing speed or velocity in delivering products. Centralized teams eliminate the need for each team to worry about infrastructure, thus increasing efficiency

An internal developer platform helps you centralize and scale specialized knowledge across the entirety of your development and operations lifecycle by reducing or eliminating cognitive load and manual steps.

Platform Engineering vs. Application Engineering

While platform engineering and application engineering are closely related, they have distinct roles within an organization. Platform engineering focuses on building and maintaining the infrastructure and tools that developers use to create applications

"Platform Engineering streamlines development by creating tools that increase systems resiliency and enhance efficiency to accelerate value delivery."

Quick Recap Quiz:

1.What is the primary role of platform engineering in an organization?

A. Building user-facing applications or services.

B. Creating marketing strategies for the company’s products.

C. Creating and managing a cohesive, integrated platform that supports developers in building, deploying, and maintaining applications.

Ans. C