DEV Community: Harshitha S

AWS (Amazon Web Services) Course

Harshitha S — Fri, 19 Dec 2025 02:23:06 +0000

🔹 Overview of the Tool / Exam

Developing Solutions for Microsoft Azure (AZ-204) is a Microsoft certification exam (part of the Microsoft Certified: Azure Developer Associate) focused on building, deploying, and maintaining cloud applications and services on Azure. It tests your ability to design and implement solutions using core Azure services such as compute, storage, security, APIs, event-driven functions, and monitoring.

Unlike a singular “tool,” AZ-204 covers a set of Azure platform features and development practices — including working with App Services, Azure Functions, Cosmos DB, Key Vault, API Management, event and message-based solutions, caching, and monitoring.

⭐ Key Features / Skill Areas Covered

The exam evaluates real-world cloud development tasks across several domains:

Develop Azure compute solutions – App Services, container apps, Azure Functions, etc. ([Microsoft Learn][1])
Develop for Azure storage – Blob Storage, Cosmos DB, solutions that use cloud data. ([Microsoft Learn][1])
Implement Azure security – authentication/authorization with Azure AD/Entra, Key Vault, managed identities. ([Microsoft Learn][1])
Monitor, troubleshoot, and optimize – Application Insights, metrics, caching (e.g., Redis). ([Microsoft Learn][1])
Connect to and consume services – APIs (API Management), event- and message-based systems (Event Grid, Service Bus). ([Microsoft Learn][1])

These skills reflect the tasks that developers perform in building cloud apps and services.

🔁 How It Fits into DevOps / DevSecOps

📌 DevOps Integration:
AZ-204 skills align closely with DevOps practices by emphasizing automation, cloud-native deployment, and efficient development workflows:

CI/CD pipelines & automation: You’ll need proficiency with Azure CLI, PowerShell, and deployment automation tools, which can be integrated into CI/CD pipelines (GitHub Actions, Azure DevOps, etc.).
Observability and monitoring: Use Application Insights and Azure Monitor for application health in production, essential in DevOps.

📌 DevSecOps Integration:
Security is embedded in the exam’s skill domains — authentication with Azure AD/Entra, securing secrets with Azure Key Vault, and implementing secure configuration all contribute to shift-left security practices that are central to DevSecOps.

🧠 Programming Languages

The exam itself doesn’t limit you to a single language but expects you to be proficient in languages supported by Azure development tools and SDKs. Common languages used in AZ-204 work include:

C#
Python
JavaScript/TypeScript (Node)
PowerShell / Bash (for CLI scripting)

Most hands-on development and samples in documentation are shown using these languages.

🏢 Parent Organization / Ownership

Owner: Microsoft Corporation — the exam, study guides, and official learning paths are developed and maintained by Microsoft.
Certification: Part of Microsoft Certified: Azure Developer Associate credential.

There’s no separate “company” for AZ-204; it sits under Microsoft’s cloud platform strategy.

💰 Open Source or Paid?

✅ Certification Exam: Paid — Microsoft charges an exam fee (typically around USD 165, price varies by country).

💡 Learning Tools:

Microsoft Learn modules and documentation are free and publicly accessible (open for study).
Third-party courses (Coursera, Udemy, practice tests) may be paid. There’s no open-source “tool” called AZ-204 — the exam tests knowledge of Azure, which is a commercial cloud platform.

I’d like to thank our staff @santhoshnc for introducing and explaining about aws courses in such a clear and practical way. Their guidance helped us understand not just the tool itself, but how it fits into real-world . The hands-on explanations and industry-relevant insights made the learning experience truly valuable.

DevSecOps Tools

Harshitha S — Fri, 19 Dec 2025 02:13:21 +0000

🪝 Helm — Overview of the Tool

Helm is a package manager for Kubernetes: it helps you define, install, upgrade, and manage applications running in Kubernetes clusters using reusable packages called Charts. It streamlines complex deployments, manages dependencies, supports versioning and rollbacks, and simplifies configuration across environments.

⭐ Key Features

Package Management with Charts
Packages (called Charts) bundle Kubernetes resources and metadata so you can install complex applications with a single command.
Deployments & Upgrades
Helm handles install, upgrade, rollback, and uninstall tasks for Kubernetes applications.
Release Versioning
Every installation creates a release, allowing version control and easy rollback to a previous state.
Config & Templating
Charts use YAML + Go template syntax so you can customize parameters per environment via values.yaml.
Dependency Management
Charts can define and manage dependencies on other charts.
Repository Support
Helm dependencies and charts can be hosted in public or private repositories like Artifact Hub.
Rollbacks

🔁 How It Fits into DevOps / DevSecOps

In modern DevOps and DevSecOps workflows, Helm plays several critical roles:

CI/CD Integration
Works well with CI/CD tools (Jenkins, GitHub Actions, GitLab CI, Argo CD, etc.) to automate deployments. ([ijritcc.org][5])
Infrastructure as Code (IaC)
Helm abstracts manifest files into reusable packages, aligning with IaC practices.
Consistency Across Environments
Charts enforce consistent deployments across dev, staging, and production.
Security & Audit Controls
Removing server-side components like Tiller (from Helm 3 onwards) improves security posture by relying on Kubernetes’ native RBAC and API access.
Reusable Components
Helm promotes modular reuse of configurations, reducing human error and boosting team productivity.

💻 Programming Language

Helm is written in Go, a language commonly used in the cloud-native ecosystem, especially in Kubernetes-related tools.

🏢 Parent Company / Governance

Helm doesn’t have a traditional “parent company.” Instead:

It was originally created by Deis (later acquired by Microsoft).
Today, it’s an open-source project maintained under the Cloud Native Computing Foundation (CNCF) — the same foundation that governs Kubernetes.

This means it’s supported by a community of contributors from many organizations rather than being owned by a single company.

💡 Open-Source or Paid?

✅ Open-Source Tool
Helm is released under the Apache License 2.0, meaning the core project itself is free to use, modify, and distribute. However, commercial products like repository managers (Artifactory, private chart registries, etc.) may offer paid services around Helm usage — but Helm itself remains free.

I’d like to thank our staff @santhoshnc for introducing and explaining Helm in such a clear and practical way. Their guidance helped us understand not just the tool itself, but how it fits into real-world DevOps and Kubernetes workflows. The hands-on explanations and industry-relevant insights made the learning experience truly valuable.

Cursor and Trigger

Harshitha S — Fri, 03 Oct 2025 17:40:38 +0000

Cursor with condition → Fetch employee names whose salary > 50,000.

AFTER INSERT Trigger → Log every new student entry into an audit table.

Cursor Example (Process Cursor with Condition)

CREATE TABLE Employee (
EmpID INT PRIMARY KEY,
EmpName VARCHAR(50),
Salary INT
);

INSERT INTO Employee VALUES
(1, 'Arjun', 45000),
(2, 'Priya', 60000),
(3, 'Kiran', 75000),
(4, 'Meera', 48000),
(5, 'Rahul', 90000);

Output

Cursor Code (Employees with Salary > 50,000)
DECLARE
CURSOR high_salary_cursor IS
SELECT EmpName FROM Employee WHERE Salary > 50000;
v_name Employee.EmpName%TYPE;
BEGIN
OPEN high_salary_cursor;
LOOP
FETCH high_salary_cursor INTO v_name;
EXIT WHEN high_salary_cursor%NOTFOUND;
DBMS_OUTPUT.PUT_LINE('Employee: ' || v_name);
END LOOP;
CLOSE high_salary_cursor;
END;

Trigger Example (AFTER INSERT Trigger)
Create Student and Audit Tables
CREATE TABLE Studt (
StudentID VARCHAR(10) PRIMARY KEY,
StudentName VARCHAR(50)
);

CREATE TABLE Student_Audit (
AuditID INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
StudentID VARCHAR(10),
StudentName VARCHAR(50),
ActionDate TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Create AFTER INSERT Trigger
CREATE OR REPLACE TRIGGER student_insert_audit
AFTER INSERT ON Students
FOR EACH ROW
BEGIN
INSERT INTO Student_Audit (StudentID, StudentName)
VALUES (:NEW.StudentID, :NEW.StudentName);
END;

Insert Data into Studt
INSERT INTO Students VALUES ('S01', 'Arjun');
INSERT INTO Students VALUES ('S02', 'Priya');
INSERT INTO Students VALUES ('S03', 'Kiran');

SELECT * FROM Student_Audit;

Key Takeaways

Cursors allow row-by-row processing of query results.
Triggers automate actions on data changes (here, logging inserts).

Database Normalization in Livesql

Harshitha S — Fri, 03 Oct 2025 17:09:00 +0000

Normalization is one of the most important concepts in database design. In this blog, we’ll walk through normalizing a student-course-instructor dataset step by step — from 1NF to 3NF — using SQL CREATE TABLE and INSERT INTO statements.

Identify Anomalies
Insertion anomaly:
Can’t insert a new course unless a student enrolls.

Update anomaly:
If Dr. Kumar’s phone number changes, we must update multiple rows.

Deletion anomaly:
If student S02 drops the course, we lose info about the DBMS course entirely.

Convert to 1NF (First Normal Form)
Remove repeating groups, ensure atomic values.

Creation of table

Insertion of data

Output

Convert to 2NF (Second Normal Form)

Remove partial dependency (non-key attributes should depend on the whole key).

Create separate tables for Students, Courses, Instructors, Studentcourses.

Create table for Students

Insert values into the table

Output

Create table for Courses

Insertion of values

Output

Create table for Instructors

Insertion of values

Output

Create table for Studentcourses

Insertion of values

Output

Convert to 3NF (Third Normal Form)
Remove transitive dependency (non-key attributes shouldn’t depend on other non-keys).

👉 In our case, the InstructorPhone depends on Instructor, not directly on Course.
So we already separated Instructors, which makes this 3NF compliant.

Final tables in 3NF:

Students(StudentID, StudentName)
Instructors(Instructor, InstructorPhone)
Courses(CourseID, CourseName, Instructor)
StudentCourses(StudentID, CourseID)

Query Using JOINs

Simple Breakdown

By breaking down our initial table step by step:

1NF → Atomic values
2NF → Remove partial dependencies
3NF → Remove transitive dependencies

We achieved a clean, normalized schema that eliminates anomalies and improves consistency.

Database Normalization

Harshitha S — Fri, 03 Oct 2025 17:08:05 +0000

Identify Anomalies
Insertion anomaly:
Can’t insert a new course unless a student enrolls.

Update anomaly:
If Dr. Kumar’s phone number changes, we must update multiple rows.

Deletion anomaly:
If student S02 drops the course, we lose info about the DBMS course entirely.

Convert to 1NF (First Normal Form)
Remove repeating groups, ensure atomic values.

Creation of table

Insertion of data

Output

Convert to 2NF (Second Normal Form)

Remove partial dependency (non-key attributes should depend on the whole key).

Create separate tables for Students, Courses, Instructors, Studentcourses.

Create table for Students

Insert values into the table

Output

Create table for Courses

Insertion of values

Output

Create table for Instructors

Insertion of values

Output

Create table for Studentcourses

Insertion of values

Output

Convert to 3NF (Third Normal Form)
Remove transitive dependency (non-key attributes shouldn’t depend on other non-keys).

👉 In our case, the InstructorPhone depends on Instructor, not directly on Course.
So we already separated Instructors, which makes this 3NF compliant.

Final tables in 3NF:

Students(StudentID, StudentName)
Instructors(Instructor, InstructorPhone)
Courses(CourseID, CourseName, Instructor)
StudentCourses(StudentID, CourseID)

Query Using JOINs

Simple Breakdown

By breaking down our initial table step by step:

1NF → Atomic values
2NF → Remove partial dependencies
3NF → Remove transitive dependencies

We achieved a clean, normalized schema that eliminates anomalies and improves consistency.

ACID Properties with SQL Transactions

Harshitha S — Fri, 03 Oct 2025 14:17:02 +0000

Databases power almost every application we use daily—from banking systems to e-commerce platforms. To ensure data remains reliable, databases follow the ACID principles: Atomicity, Consistency, Isolation, and Durability.

In this blog, we’ll demonstrate ACID properties with SQL transactions using a simple Loan Management example.

Step 1: Setup the Schema

We’ll create a Loans table that stores customer loan detail

Enter the values to be inserted in the table

Check the result

ATOMICITY
All operations in a transaction must succeed or none should.

Update and roll back

Atomicity ensures no partial updates happen.

Consistency

Transactions must bring the database from one valid state to another. Invalid data should not enter the system.

Alter

Consistency ensures only valid data enters the database.

Isolation

Concurrent transactions should not affect each other’s intermediate results.

Isolation prevents dirty reads between transactions.

Durability

Once a transaction is committed, the changes must persist—even if the database crashes.

Durability guarantees committed data survives restarts.

Key Takeaways

Atomicity → All or nothing.
Consistency → Data always valid.
Isolation → Transactions don’t interfere.
Durability → Data persists after commit.

By applying ACID principles, databases remain reliable, fault-tolerant, and consistent even in high-concurrency environments like banking systems.

Transactions, Deadlocks & Log Based Recovery

Harshitha S — Fri, 03 Oct 2025 10:37:30 +0000

Managing database transactions safely is crucial to ensure data integrity and prevent issues like partial updates or deadlocks. In this tutorial, we’ll explore transactions, deadlocks, and log-based recovery using a simple Accounts table.

First, let’s create a sample table
CREATE TABLE Accounts (
acc_no INT PRIMARY KEY,
name VARCHAR(50),
balance INT
);

INSERT INTO Accounts VALUES
(1, 'Alice', 1000),
(2, 'Bob', 1500),
(3, 'Charlie', 2000);

*Transaction – Atomicity & Rollback
*
Suppose we want to transfer 500 from Alice to Bob. Using a transaction ensures that either both operations succeed or none.

START TRANSACTION;

UPDATE Accounts
SET balance = balance - 500
WHERE name = 'Alice';

ROLLBACK;

UPDATE Accounts
SET balance = balance + 500
WHERE name = 'Bob';

Deadlock Simulation

Deadlocks occur when two transactions block each other waiting for resources.

START TRANSACTION;
SELECT * FROM Accounts WHERE name='Alice' FOR UPDATE;
UPDATE Accounts SET balance = balance + 100 WHERE name='Bob';

START TRANSACTION;
SELECT * FROM Accounts WHERE name='Bob' FOR UPDATE;
UPDATE Accounts SET balance = balance - 100 WHERE name='Alice';

RESULT
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

Log-Based Recovery

Modern DBMS (MySQL/PostgreSQL) automatically maintain transaction logs. These logs help undo changes if a transaction fails.

UPDATE Accounts SET balance = balance - 300 WHERE name='Alice';

SELECT * FROM Accounts;

Log-based recovery ensures that undo operations are possible. Even if the database crashes, the system can restore a consistent state.

Summary

Transactions guarantee atomicity; either all operations succeed or none.

Deadlocks occur when transactions block each other; they must be handled with care.

Log-based recovery ensures durability and recoverability.

Indexing, Hashing, and Query

Harshitha S — Thu, 02 Oct 2025 18:19:30 +0000

Create a table

INSERT INTO Students VALUES
(101, 'Arun', 'CSBS', 8.5),
(102, 'Mathan', 'ECE', 8.8),
(103, 'Karthik', 'MECH', 6.9),
(104, 'Hareesh', 'CSE', 9.1),
(105, 'Ravi', 'EEE', 7.2),
(106, 'Srivishal', 'CSBS', 8.8),
(107, 'Vignesh', 'IT', 8.0),
(108, 'Harish', 'CSE', 9.3),
(109, 'Deepak', 'ECE', 7.5),
(110, 'Nidheesh', 'CSBS', 9.0),
(111, 'Pradeep', 'MECH', 6.8),
(112, 'Lokhitha', 'EEE', 7.6),
(113, 'Raj', 'CSBS', 8.7),
(114, 'Divya', 'IT', 8.4),
(115, 'Saravanan', 'CSE', 9.2),
(116, 'Monika', 'ECE', 7.9),
(117, 'Ganesh', 'MECH', 6.7),
(118, 'Kavya', 'CSBS', 9.1),
(119, 'Surya', 'EEE', 7.3),
(120, 'Anitha', 'IT', 8.2);

Create a B-Tree Index on roll_no
CREATE INDEX idx_rollno ON Students(roll_no);

Query Using B-Tree Index

SELECT * FROM Students WHERE roll_no = 110;

Create a B+ Tree Index on cgpa

SELECT * FROM Students WHERE cgpa > 8.0;

Query Using Hash Index

SELECT * FROM Students WHERE dept = 'CSBS';

CRUD Operation in MongoDB

Harshitha S — Thu, 02 Oct 2025 17:53:34 +0000

MongoDB is one of the most popular NoSQL databases used by developers today for building modern, scalable applications. Unlike traditional relational databases, MongoDB stores data in flexible JSON-like documents, making it easier to work with real-world scenarios.

In this blog, We’ll walk through CRUD operations (Create, Read, Update, Delete) in MongoDB using a simple example: a student database. We’ll insert student details, query them, update academic information, and even delete records.

To make it more exciting, we’ll run these queries directly on MongoDB Atlas Cluster (cloud-based MongoDB). Along the way, I’ll include screenshots of my MongoDB Atlas dashboard and outputs so you can follow along visually.

Outcome:-

How to insert multiple documents into a collection

How to read and filter records using queries

How to update documents (single & multiple)

How to delete documents based on conditions

How CRUD fits into real-world development

Setup: Creating a Cluster

Create a free MongoDB Atlas account

Create a cluster and a database called collegeDB
Inside it, create a collection called STUDENTS

Create (Insert):-

Insert at least 5 student records into the students collection.

We cannot start by inserting 5 student records into our students collection together. We can create each student as separate document.

Code:-

{
student_id: "S001",
name: "Harshitha",
age: 20,
department: "CSBS",
year: 2,
cgpa: 9
}

{
student_id: "S002",
name: "Madhummitha",
age: 21,
department: "CSBS",
year: 3,
cgpa: 8.5
}

{
student_id: "S003",
name: "Lokhitha",
age: 20,
department: "MI",
year: 3,
cgpa: 8
}

{
student_id: "S004",
name: "Hareesh",
age: 22,
department: "IT",
year: 3,
cgpa: 9.2
}

{
student_id: "S005",
name: "Dhaaraneesh",
age: 20,
department: "CIVIL",
year: 2,
cgpa: 8.8
}
{
student_id: "S006",
name: "Harish",
age: 22,
department: "CSE",
year: 3,
cgpa: 9.2
}

READ(QUERY)

Find all students with CGPA > 8.

db.students.find({ cgpa: { $gt: 8 } })

Find students belonging to the Computer Science department.

db.students.find({ department: "CSE" })

UPDATE

Update the CGPA of a specific student.

{ "student_id": "S005" }

Delete:-

Delete one student record by student_id.

{ "student_id": "S004" }

RESULT

Conclusion:-

In this blog, we explored how to perform CRUD operations in MongoDB using a real-world example of a student database. Starting from inserting records, querying based on conditions, updating multiple documents, and finally deleting specific records – we’ve covered the foundation of working with MongoDB.

CRUD operations form the building blocks of every application, whether you’re managing users in a website, products in an e-commerce app, or students in a college system.

Thanks to Mr.@santhoshnc for encouraging us in exploring new paths in technology and gain knowledge.

Creating Table for faculty

Harshitha S — Mon, 25 Aug 2025 17:22:47 +0000

Using Select Query

Harshitha S — Mon, 25 Aug 2025 17:16:50 +0000

Using Query to find length

Harshitha S — Mon, 25 Aug 2025 17:13:13 +0000