AWS Identity and Access Management, commonly known as AWS IAM, is a service that allows you to control who can access your AWS services and what actions they can perform.

Simple Example:
Imagine you own a mobile phone. You have full control over who can access it and at what level. For instance:

• Some people can only view your phone (e.g., notifications or the screen lock).

• Others might have deeper access, like viewing your photos or contacts.

Similarly, AWS IAM helps you define who can access your AWS resources and sets permissions at the required levels to ensure security.

IAM Users

An IAM User is an individual identity you create within your AWS account for a specific person or application that needs access to AWS services.
For example:
If someone needs access to manage an EC2 instance, you can create a user for them and attach the required IAM Policy that defines their permissions.

IAM Policy

An IAM Policy is a document that specifies the permissions for a user, group, or role in JSON format.
You can think of it as an agreement document that defines what the user is allowed or restricted from doing within AWS.

• For instance, an IAM Policy might specify that a user can "Start/Stop EC2 instances" but not "Delete S3 buckets."

Policy Structure

An IAM Policy typically includes the following elements:

1. Effect: Specifies whether the policy allows or denies access.
   Example: "Effect": "Allow" or "Effect": "Deny"

2. Action: Lists the actions the policy allows or denies.
   Example: "Action": "ec2:StartInstances"

3. Resource: Specifies the resources the actions apply to.
   Example: "Resource": "arn:aws:ec2:region:account-id:instance/instance-id"

IAM Groups

An IAM Group is a collection of users that share the same set of permissions.
Example Scenario:
If multiple users require the same permissions, such as access to EC2 instances, you can create a group (e.g., "EC2Admins") and attach the required policy to the group. Instead of individually attaching the policy to each user, you simply add them to the group.

Note:

• A user can belong to multiple groups.

• However, groups cannot contain other groups.

Automation of AWS IAM and Other AWS Services

You can automate the creation of IAM users, policies, and other AWS resources using the following tools:

1. AWS CLI:
   The Command Line Interface is used for performing smaller tasks, such as creating IAM users or launching EC2 instances.

2. AWS SDK (e.g., Boto3 for Python):
   The SDK provides programmatic access to AWS services and is particularly useful for serverless application development.
   Why prefer AWS SDK over AWS CLI?
   While both serve similar purposes, the SDK is more versatile, enabling you to write code for serverless services and integrate AWS with custom applications.

3. AWS CloudFormation (CFT):
   CFT enables you to define your infrastructure as code, automating the creation and management of AWS resources.

4. Terraform:
   Like CloudFormation, Terraform is used for Infrastructure as Code (IaC) but is platform-agnostic, meaning it supports multiple cloud providers.

Use Cases:

• AWS SDK/CLI: Automating smaller tasks like creating users or managing instances.

• AWS CloudFormation/Terraform: Automating infrastructure provisioning for larger deployments.

Final Thoughts

AWS IAM is a cornerstone of security in AWS, helping you ensure that only authorized users can access specific resources. By combining IAM with automation tools like AWS CLI, SDKs, and Infrastructure as Code solutions, you can manage access efficiently and scale your AWS environment securely.

But then, a thought crossed my mind: Why not push myself a little harder? 💭

Initially, I hesitated. After all, today was also a working day, and I had to dedicate 9 hours to my regular job. But I made a decision—let’s give it a try. And boy, did it pay off!

The Morning Grind: DevOps Learning 🖥️💡

The first thing I did was jump back into DevOps learning before diving into the project. I started at 6 AM, diving into AWS theory, specifically AWS SNS and AWS Route 53. 📚

I also tried my hand at some architecture design, including load balancing with NLB and ALB. And while I was at it, I spent about 3 hours trying to wrap my head around Route 53. And let me tell you, I didn’t manage to finish it. 😅

But you know what? I didn’t give up. Sometimes, it’s not about finishing everything immediately. I reminded myself, "Hey man, heroes don’t win all the time!"

Work Hours: A Break and the Job 🧑‍💻

By 12 PM IST, it was time for my regular work shift. So, I took a one-hour break to recharge before diving into my job, which runs from 12:00 PM IST to 9:00 PM IST. 🕛

After work, I returned to the challenge and watched the video. And you know what? I was ecstatic! 😁 All my tiredness melted away when I saw AWS SNS featured in the project. I know it may seem like a small thing to others, but for a beginner like me, it was HUGE! 💥

Reflecting on the Journey: Is It All Worth It? 🤔

During my work hours, a lot of questions popped up in my mind. Am I doing the right thing? Should I stop my regular learning and just focus on the DevOps challenge? I wondered if it would be more effective to concentrate on just one thing. But then, as I thought about how the theory I learned in the morning linked to the project in the evening, everything started to make sense. 🧠✨

Key Takeaways from Day 2 📌

1. Believe in the journey, not the destination.

   • If you trust the process, you’ll get there. It might take time, but you’ll reach your goal eventually. 💪

2. Push yourself beyond your limits.

   • I realized that opportunities like this may not come every day. Even when things seem difficult, you need to keep pushing yourself. 💯

Conclusion: A Day of Growth 🌱

Looking back, today was a day of learning, progress, and reflection. I’ve learned that success is a journey, not a sprint. Whether it’s DevOps, programming, or any challenge in life, perseverance is key. Today, I pushed myself further than before—and it was worth it. 😊

Thanks for reading my journey on Day 2! I hope you find motivation in this story. If you're also in the middle of your learning journey, remember to believe in yourself and keep pushing forward. The rewards will follow. 🔥

Feel free to leave a comment or share your thoughts. Let’s keep learning and growing together! 🌍

Today, I want to share my experience from the first day of my 30-day DevOps challenge, sponsored by the Cozy Cloud Crew. To give you some context, I was a complete beginner with no clue about what I was about to dive into. At first, it felt like an impossible challenge, and I had no idea where to begin. People in the community were talking about their accomplishments, like completing the AWS SAA certification, which made me feel lost and discouraged.

Honestly, on my first day in the community, I thought about quitting. Everyone seemed so far ahead, and I didn't know what I was doing. I was stuck in what’s often referred to as "tutorial hell," where you watch videos, repeat exercises, and feel too scared to actually show your work. But then, I decided to take a step back. I turned off my laptop for a moment, paused, and thought: What am I really doing here?

I realized that I didn’t want to stay stuck in that cycle forever. I didn’t want to keep watching videos without gaining any real experience. This time, I decided, I would make a change.

The Decision to Keep Going

I had a moment of clarity. No more skipping through content or copying and pasting code just for the sake of completing tasks. This time, I would truly understand what I was doing, even if it took longer.

I had a great resource to help me — ShaeInTheCloud, who explains each step of the project clearly. But instead of just copying the code, I told myself I would learn and understand it fully. This would be a journey of true learning.

Day 1: The Analogy

To stay motivated and focused, I created a story around my Day 1 challenge. I imagined this as a movie where I am the hero, and the project is the goal I need to accomplish. Of course, there are obstacles in the way, but I was determined to face them head-on.

So, what were the problems I had to solve?

1. Python - I had never worked with Python before.

2. APIs - I knew very little about APIs.

I knew I couldn’t master Python in one day, but I made it my goal to at least understand the code I was working with. To do this, I needed to break down the task into smaller pieces and figure out exactly what I needed to learn.

The Plan: Understanding Python

Python was unfamiliar to me. I didn’t know where to start, so I turned to my trusty friend — ChatGPT.

I asked ChatGPT, "Hey buddy, can you tell me the Python topics that are covered in the code I’m working with?" And voilà, I got a list of topics.

I decided not to rush this part. I copied each topic and searched for tutorials in my native language to understand Python’s syntax and use cases. By taking this approach, I covered the basics of Python one step at a time.

Diving Into the Code

Once I understood the syntax, it was time to read the code. I took my time, analyzing each line. Whenever I didn’t understand something, I went back to ChatGPT to clarify.

For about 4 hours, I slowly worked through the code, asking questions, and learning. By the end of that time, I was able to understand the project.

The Next Obstacle: APIs

The next challenge was understanding APIs. I wasn’t familiar with them at all, so I asked ChatGPT again, "What is an API, and what types are there?" I also wanted to know what type of API the project was using, and it turned out to be the OpenWeather API.

I spent an hour reading up on APIs and learning how they work. Once I understood the basics, I was ready to move forward.

The Struggles and Errors

Once I felt prepared, I began executing the project, but, as expected, I ran into errors. Here are the main ones I encountered:

1. Unable to install via pip – This error said the environment was externally managed. The solution: I needed to install the packages system-wide.

2. AWS key not configured correctly – I hadn’t set up my AWS credentials properly, so I fixed that.

3. S3 bucket name declaration issue – I forgot to declare the bucket name correctly.

4. Region not configured properly – I didn’t set the correct AWS region.

For every error, I went back to ChatGPT and asked, "What is this error, and why is it happening?" Slowly but surely, I managed to solve each issue.

10 Hours Later...

After about 10 hours of hard work, I completed the project. It wasn’t easy, but it was worth it. I didn't regret a single moment spent learning and troubleshooting.

Lesson Learned

The biggest lesson from Day 1: Don’t compare yourself to others.

At the beginning of the day, I was discouraged by seeing how much more experienced everyone else seemed. I thought I wouldn’t be able to finish the challenge in 30 days. But by the end of the day, I had a new mindset. I told myself, "From now on, it’s going to be me vs. yesterday’s me. Not me vs. others."

I also realized that I don't have to finish the challenge in 30 days. The goal is to learn and grow, even if it takes time. I’m in this for the long run, and I’m committed to pushing myself forward, even if I stumble along the way.

Final Thoughts

I’m proud of myself for taking this challenge head-on, and I’m excited to see where the next 29 days take me. I know there will be more challenges, but I’m ready to face them with the same determination.

I encourage anyone reading this to stop comparing yourself to others and start focusing on your personal growth. We all have different learning speeds and journeys, but as long as we keep moving forward, we’re on the right path.

That’s the first day of my DevOps challenge journey with Cozy Cloud Crew. I hope this inspires you to take on your own challenges and keep pushing yourself to learn, no matter where you start!

Hello Everyone! Welcome to my blog! Yesterday, I embarked on an exciting yet challenging journey—implementing an AWS VPC three-tier architecture. Along the way, I made plenty of mistakes, learned a lot, and ended the day with a big smile (and a lot of new knowledge). Let me walk you through my day, mistakes included!

The CIDR Block Saga 💨

My first struggle started with CIDR blocking. Honestly, I kind of skipped that part initially (big mistake 😅). When I attempted to create subnets, I ran into the dreaded subnet overlap issue. At that moment, I paused and thought, "Wait, what does subnet overlapping even mean?"

I went back to the basics and spent time learning how to split subnets and calculate IP ranges using binary values. It took me two hours to understand CIDR blocks properly, but hey, it was worth it! 🚀

Back to the Console 🚒

Armed with my newfound CIDR knowledge, I went back to the AWS Console and successfully set up:

• VPC

• Route tables

• Internet Gateway

I even created a jump server to access the web server in my private subnet. At this point, I thought, "Wow, I’m a cloud engineer now!" 😎 But reality hit me hard when my EC2 instance in the private subnet couldn’t access the internet. 🙄

Enter the NAT Gateway 🌐

This problem led me to learn about the NAT Gateway. I went back to my resources, studied how it works, and returned to the console to set it up. Success! My EC2 instance could now access the internet. Feeling confident, I installed Jenkins on the private subnet and thought everything was perfect.

But…

The Load Balancer Revelation 🤦‍♂️

When I tried to access Jenkins from my browser, nothing worked. "Why?!" I spent three hours troubleshooting, scratching my head, and Googling. Finally, after seeking help from the community (thank you, amazing people! 💖), I learned about the Load Balancer.

I researched Load Balancers, re-architected my design, and added one to my setup. Finally, I was able to access Jenkins, which was running in my private subnet. Victory at last! 🎉

Before

At last

Key Takeaways 🎡

1. Learn by Doing: This experience taught me that hands-on practice is incredibly powerful. Watching tutorials alone doesn’t work for me; doing things step by step taught me far more.

2. Embrace Mistakes: Mistakes are opportunities to learn. Every error pushed me to dig deeper into concepts.

3. Community is Everything: The DevOps community’s support and insights were invaluable.

Final Thoughts

Spending an entire day on AWS VPC might sound intense, but for me, it was worth every second. This marks a significant step in my restarted journey towards DevOps. If you’re on a similar path, don’t be afraid to dive in and make mistakes. The lessons you learn will stick with you forever.

Keep learning and keep building! 🚀

Introduction:

A Virtual Machine (VM) is a virtual computer that allows multiple applications to run on a single physical machine.

Why Did VMs Come Into the Tech World?

To understand the need for VMs, let’s first look at how applications were traditionally hosted in data centers.

What is a Data Center?
A data center is essentially a collection of physical systems (servers) located in one place, used to host applications and services.

The Problem with Traditional Hosting

In the early days, companies would buy space in data centers to deploy their applications. Here’s an example:

• Imagine your company developed a software application and needed to deploy it on a server.
  Scenario 1:

  • You estimate that your application requires 8 GB of RAM and 1 TB of disk space.

  • So, you purchase that capacity from a data center.

Scenario 2:

• Later, you develop another application, but this one requires a Linux environment.

• You end up buying additional server space to host it, even though it doesn’t need as many resources.

Disadvantages of the Traditional Approach

1. Underutilized Resources:

   • Your first application might only use 300 GB of disk space during peak times, while your second application uses just 100 GB.

   • However, you purchased 2 TB of space in total, wasting significant resources.

2. One Application, One Server Model:

   • This was the standard in the early days of the software industry. Each server hosted a single application, leading to inefficiencies and high costs.

The Solution: Virtual Machines

How can we run multiple applications on a single machine?
That’s where Virtual Machines (VMs) come into play! VMs enable multiple applications to run on the same physical server by isolating them into virtual environments. This approach maximizes resource utilization and reduces costs.

Hypervisor

A hypervisor (like VMware, Hyper-V, or KVM) creates and manages VMs.The hypervisor acts as a bridge between the physical hardware and the virtual machines.Each VM is isolated and runs its own operating system and applications.

Benefits of Virtual Machines

1. Cost Efficiency:

   • By utilizing the same hardware for multiple applications, companies save money on hardware and energy costs.

2. Resource Optimization:

   • VMs allocate only the required amount of resources to each application, minimizing wastage.

3. Flexibility:

   • Different operating systems (e.g., Windows, Linux) can run on the same physical server using separate VMs.

4. Scalability:

   • New VMs can be easily created to accommodate additional applications or workloads.

5. Testing and Development:

   • VMs are ideal for creating isolated environments for testing without affecting the main system.

6. Disaster Recovery:

   • Snapshots of VMs can be created to restore the system in case of failure.

Challenges and Limitations of VMs

1. Performance Overhead:

   • VMs can have slower performance compared to running directly on hardware due to the hypervisor's overhead.

2. Resource Contention:

   • Multiple VMs on the same hardware may compete for resources, leading to performance degradation if not managed well.

3. Complexity in Management:

   • Managing a large number of VMs requires expertise and additional tools.

Conclusion

Virtual Machines revolutionized the way we utilize physical hardware, enabling better resource optimization, flexibility, and scalability. They addressed the inefficiencies of the "one application, one server" model, making them a cornerstone of modern IT infrastructure. Whether for hosting multiple applications, testing, or cloud computing, VMs play a critical role in the tech ecosystem. As technology evolves, VMs continue to coexist with newer innovations like containers, ensuring businesses have robust solutions to meet diverse needs.

Thank you for reading! Feel free to share your thoughts or questions in the comments. Let’s keep learning together!

Introduction:

A Version Control System (VCS), like Git, is an essential tool in modern software development. It allows developers to track and manage changes in their code over time. By using a version control system, developers can store their code in a central place called a repository, collaborate with others, and easily revert back to previous versions of their code when needed.

So, what does Version Control actually mean?

Let’s use a simple analogy:

Imagine you’re a farmer growing various products, such as vegetables, wheat, and fruits. When it’s time to deliver these products to your customers, you need to gather everything and put it all into one vehicle for transportation. This ensures the delivery process is organized and efficient.

In software development, developers work on different features or modules of an application. These pieces of code are stored in one common location called a repository (or repo). This is similar to the farmer's delivery vehicle — it holds all the code that makes up the application.

Version control helps you keep track of changes to your code. If something goes wrong, you can go back to previous versions and see exactly what was changed. This makes it easy to undo mistakes or figure out what caused an issue in the code.

Why is Version Control Important?

1. Track Changes: Version control helps you keep track of all changes made to your code. Every time you make a change and save it, Git records that change, creating a version. You can look back at previous versions to see what was changed, when, and by whom.

2. Collaboration: When working in teams, version control allows multiple developers to work on the same project at the same time without interfering with each other’s work. Git allows developers to create branches where they can work independently, and later merge their changes into the main project.

3. Backup and Restore: If you accidentally break something in your code, version control acts as a safety net. You can always roll back to a previous, working version. It’s like having an automatic backup for your code.

4. Code Quality: By using version control, you can review each other’s changes. This makes it easier to maintain high-quality code and identify potential issues before they become bigger problems.

If Git is a Version Control System, then what are GitHub, GitLab, Bitbucket, etc.?

Git is the version control system that tracks and manages your code on your local machine. GitHub, GitLab, Bitbucket, and similar platforms are services that host your Git repositories online. These platforms provide additional features like:

• Collaboration Tools: You can work on projects with others, making it easy to track who’s working on what.

• Issue Tracking: You can report and manage bugs or new features directly within the platform.

• Pull Requests (PRs): Before changes are merged into the main codebase, developers can create pull requests, allowing teammates to review and discuss changes before accepting them.

These platforms also allow you to back up your code in the cloud, which ensures it’s safe and accessible from anywhere.

How Does Git Work? (Basic Git Commands)

Now, let’s go over some basic Git commands that developers use every day:

1. git init:
   This command initializes a new Git repository in your project folder. It creates a .git directory where Git will store all the version history of your project.

2. git clone:
   Use this command to clone (copy) a remote repository (like one on GitHub) to your local machine.

   Syntax : git clone <repository URL>

3. git status:
   This command shows you the current state of your working directory, including which files are modified or not yet tracked by Git.

4. git add:
   Before committing changes, you need to add files to the staging area. This command tells Git to include your changes in the next commit.

   Syntax: git add <file_name>

5. git commit:
   A commit is like saving a snapshot of your project. After adding files, you can commit them with a message describing the changes you made.

   Syntax: git commit -m "Your commit message here"

6. git push:
   After committing your changes, you use git push to upload them to a remote repository (like GitHub).

   Syntax: git push origin main

7. git pull:
   This command is used to download changes from the remote repository to your local machine, ensuring you have the latest version of the project.

   syntax: git pull origin main

8. git branch:
   Git allows you to create different branches to work on features or bug fixes without affecting the main codebase. Use this command to list or create branches.

   syntax: git branch <branch_name>

9. git merge:
   When your feature or bug fix is ready, you can merge your branch back into the main project (usually main or master branch) using this command.

   syntax: git merge <branch_name>

Conclusion:

Version control systems like Git are essential tools for managing and tracking code changes in modern software development. Whether you’re working alone or with a team, version control helps you stay organized, avoid mistakes, and collaborate more effectively. Platforms like GitHub, GitLab, and Bitbucket make it easy to store and share your code, collaborate with others, and track changes over time.

By learning the basics of Git and version control, you can improve your workflow, keep your projects organized, and reduce the chances of errors in your code. As you gain experience with Git, you’ll become more comfortable with advanced features and workflows that make team collaboration even smoother.

Linux file permissions are a critical part of system security, allowing administrators and users to control who can read, write, or execute files. Let’s break down how these permissions work and how to modify them.

So what is permission exactly and what we are talking about now?

For example we take our smart phones

As the owner of the phone you have full access to your mobile like you can delete the files create the files updating the system etc simply you can do whatever you want since it was your

for the scenario lets say your friend ask your phone for one 30 mins, what we will do? for security purpose we will keep passwords to our phones and the applications inside in it so that your friend doesn't change anything without your knowledge

Same thing applies here

in Linux system the owner is root

root user can do any configuration related to the system

so what about the other users? how the system admin will change the files and how they configure the things ?

Lets say your friend wants to install one application so he will ask your permission can i install it ? and you say okay it doesn't affect anything to my phone go ahead

and you give your access to install it

In linux system as the normal user you don't have access to the entire system in that cases you will use the command called sudo

sudo -> Super User Do

this command allows you to perform the action with the root access like changing the permissions to the files

CHMOD

You can change the permission of the file using the command called chmod

Breaking Down the Permission Structure

When you view a file's details using ls -l, you’ll see something like:

This line can be broken down as follows:

1. File Type

• File Type: The first character indicates the type of file:

  • - for a regular file

  • d for a directory

  • l for a symbolic link

2. Permissions

• Permissions: The next nine characters represent the permissions, divided into groups of three:

  • First Set (rwx): Permissions for the owner of the file.

  • Second Set (r-x): Permissions for the group that owns the file.

  • Third Set (r-x): Permissions for others (anyone else on the system).

Example Breakdown:

• The owner has read (r), write (w), and execute (x) permissions.

• The group and others has read (r) and execute (x) permissions.

Changing Permissions with chmod

To modify permissions, you use the chmod command, which allows changes in either symbolic or numeric mode.

Symbolic Mode

In symbolic mode, you specify:

• Who: u (user/owner), g (group), o (others), or a (all).

• Operation: + (add), - (remove), = (set).

• Permission: r (read), w (write), or x (execute).

Example

Syntax

chmod <permission> <file name >

Kindly please note below the other dont have access to write and excute the file

Now im going to give write and excute permissions to the other users

for that im going to excute the command
chmod o+wx file.txt

now we will see the file below

Numeric Mode

In numeric mode, each permission is represented by a number:

• Read (r) = 4

• Write (w) = 2

• Execute (x) = 1

The sum of these values represents different permission levels:

• 7 (4+2+1) for read, write, execute

• 6 (4+2) for read and write

• 5 (4+1) for read and execute

• 4 for read-only

To set permissions, use a three-digit number where:

• The first digit is for the owner.

• The second digit is for the group.

• The third digit is for others.

  syntax for this mode is

  chmod <permission in numbers> <filename>

By understanding these commands and concepts, you’ll have greater control over file security and permissions on a Linux system!

"Hello everyone! In this blog, we’ll cover the basics of the Linux filesystem and introduce a few essential commands."

Filesystem Concept

"The filesystem in Linux is organized as a hierarchical tree starting from the root (/), branching out into various directories. Navigating and understanding this structure is crucial for deepening your Linux knowledge."

Default Directories in Linux

"These directories are set up automatically when you install Linux:"

• /bin: Contains essential binaries needed to boot your system.
  What are binaries? Think of them like executable files for your operating system (OS). When you install Linux, it’s similar to installing any software on your computer. You download an ISO image, which extracts files and organizes them in specific locations. After installation, each time the OS runs, it triggers certain files to operate, which are stored in the /bin directory.

• /home: The home directory, similar to the Desktop folder on Windows. When you log in to Linux, this is your landing point, where you’ll store personal documents and downloads.

• /etc: Stores configuration files for the system and applications.
  Example: This is similar to the installation paths chosen on Windows. When software is installed, configuration files are stored here.

• /var: Contains variable files, like logs.
  Example: For instance, /var/log holds system log files where you can track actions taken on your system.

• /tmp: A temporary file storage area, automatically cleared on reboot.

• /dev: Contains device files (e.g., hard drives, USB devices).
  This directory holds details about your hardware components.

• /proc: Contains information about system processes.

• /mnt and /media: Default mount points for external devices like USBs and DVDs.

Filesystem Types

• Ext4: The most widely used on Linux, reliable and high-performing.

• XFS: Optimized for large files, often used in enterprise environments.

• Btrfs: Supports advanced features like snapshots, which allow you to save the filesystem’s state.

• FAT32/exFAT: Commonly used on USB drives to ensure compatibility with Windows.

Basic Commands in Linux

For navigating and managing files:

• ls: Lists directory contents

  • ls -l: Shows a detailed list

  • ls -a: Includes hidden files

• cd: Changes directory

  • cd ..: Goes up one level

  • cd ~: Returns to the home directory

• pwd: Prints the current directory path

For working with files and directories:

• touch filename.txt: Creates an empty file or updates the timestamp

• mkdir new_folder: Creates a directory

  • mkdir -p /path/to/multiple/folders: Creates nested folders

• rm filename.txt: Deletes a file

  • rm -r folder_name: Deletes a directory and its contents

• cp file1 file2: Copies a file

  • cp -r folder1 folder2: Copies a folder

• mv oldname.txt newname.txt: Moves or renames a file

For viewing and editing files:

• cat file.txt: Displays file contents

• less file.txt: Opens a file in a scrollable view

• head -n 10 file.txt: Shows the first 10 lines

• tail -n 10 file.txt: Shows the last 10 lines

  • tail -f logfile.log: Follows real-time updates (useful for logs)

Conclusion

"Understanding the Linux filesystem is the backbone of system administration. If you’re going to work with Linux, start by understanding the system’s structure. In the next blog, we’ll cover permissions and delve into more filesystem commands."