Lab 01 — Linux Administration

Welcome to your first hands-on Linux lab.

You have completed the Linux certification learning path:

Linux Essentials
      ↓
LPIC-1
      ↓
CompTIA Linux+
      ↓
RHCSA
      ↓
RHCE

Now we move from:

Learning Linux

to:

Operating Linux

This lab brings the major administration concepts together into one practical workflow.

Mission Information

Lab: Linux Administration
Level: Beginner → Intermediate
Estimated Time: 90–120 minutes
Environment: Authorized Linux VM or disposable lab server
Primary Role: Linux Administrator
Secondary Roles: Cloud Engineer, SOC Analyst, Security Engineer, DevOps Engineer

Mission Scenario

You have joined an infrastructure team responsible for a newly provisioned Linux server.

Before the server can be handed over to an application team, you have been asked to perform an administrative readiness review.

Your responsibilities include:

Identify the System

Inspect Resources

Understand the Filesystem

Review Users and Groups

Create Controlled Lab Identities

Configure Permissions

Inspect Processes

Manage Services

Review Packages

Inspect Storage

Validate Networking

Review Logs

Inspect Scheduled Tasks

Assess System Health

Troubleshoot Problems

Document the Server

The objective is not simply to execute commands.

You must understand:

What Am I Checking?

Why Am I Checking It?

What Does the Result Mean?

What Should I Validate?

Lab Architecture

+--------------------------+
|      Your Workstation    |
+------------+-------------+
             |
             | SSH / Console
             |
             v
+--------------------------+
|      Linux Lab Server    |
|                          |
|  Users                   |
|  Groups                  |
|  Files                   |
|  Processes               |
|  Services                |
|  Packages                |
|  Storage                 |
|  Network                 |
|  Logs                    |
+--------------------------+

You only need one Linux VM for this lab.

Recommended Lab Environment

You may use an authorized disposable VM running a mainstream Linux distribution such as:

Ubuntu

Debian

Rocky Linux

AlmaLinux

Red Hat Enterprise Linux

Commands can vary slightly between distributions.

Where appropriate, the lab explains the concept rather than assuming every Linux distribution behaves identically.

Safety Rules

Use only:

Your Own VM

Your Organization's Authorized Lab

An Approved Training Environment

Do not practice administrative changes on production systems unless specifically authorized.

Before changing:

Users

Permissions

Packages

Services

Storage

Networking

understand the impact first.

Lab Objectives

By completing this lab, you should be able to:

Identify a Linux system
Navigate the filesystem
Create and manage files and directories
Understand Linux filesystem hierarchy
Review users and groups
Create training users and groups
Configure ownership and permissions
Inspect running processes
Review and manage services
Inspect installed packages
Review storage and filesystem utilization
Understand mount points
Review network configuration
Identify listening services
Review system logs
Inspect scheduled tasks
Evaluate basic system health
Troubleshoot common Linux problems
Produce an administration report

Part 01 — Connect to the Linux Server

Connect using either:

Console

or an approved remote administration method such as:

SSH

Once connected, do not immediately begin changing the system.

First determine:

Who Am I?

Where Am I?

Which Server Is This?

Step 01 — Identify Your Current User

Run:

whoami

Record the result.

Then:

id

Observe:

UID

Primary GID

Group Membership

Why This Matters

Before performing administration, always know:

Which Identity
Is Executing Commands?

The privileges of your current identity determine what you can access and modify.

Step 02 — Identify the Host

Run:

hostname

Then:

hostnamectl

where supported.

Record:

Hostname

Operating System

Architecture

Step 03 — Identify the Distribution

Review:

cat /etc/os-release

Look for information such as:

Distribution Name

Version

Distribution Family

Step 04 — Identify the Kernel

Run:

uname -r

Then:

uname -a

Understand the difference between:

Linux Distribution

and:

Linux Kernel

Step 05 — Review Uptime

Run:

uptime

Record:

Current Time

Uptime

Logged-In Users

Load Averages

Do not interpret load numbers in isolation.

They must be considered alongside:

CPU

Processes

I/O

Workload

Checkpoint 01

You should now be able to document:

Hostname:

Distribution:

Version:

Kernel:

Architecture:

Current User:

UID:

Groups:

Uptime:

Part 02 — Explore the Linux Filesystem

Linux organizes resources under:

The root of the filesystem hierarchy.

Run:

pwd

Then:

ls /

Important Directories

Become familiar with:

Directory	Typical Purpose
`/etc`	System and application configuration
`/home`	Regular user home directories
`/root`	Root user’s home directory
`/var`	Variable application and system data
`/var/log`	Common log location
`/tmp`	Temporary files
`/usr`	User-space programs and supporting data
`/opt`	Optional/additional software
`/boot`	Boot-related files
`/dev`	Device interfaces
`/proc`	Process/kernel runtime information
`/sys`	Kernel/device information

Exact layouts can vary by distribution.

Step 06 — Navigate Directories

Practice:

cd /
pwd

Then:

cd /etc
pwd

Return to your home directory:

cd ~

Step 07 — List Files

Run:

ls

Then:

ls -l

Then:

ls -la

Observe:

File Type

Permissions

Owner

Group

Size

Timestamp

Name

Step 08 — Understand Hidden Files

Files beginning with:

are normally hidden from basic directory listings.

Examples may include:

.bashrc

.profile

.ssh

Use:

ls -la

to include hidden entries.

Part 03 — Create a Lab Workspace

Do not scatter training files across the system.

Create a dedicated workspace inside your home directory.

mkdir -p ~/linux-admin-lab

Move into it:

cd ~/linux-admin-lab

Confirm:

pwd

Step 09 — Create Directories

Create:

mkdir documents
mkdir logs
mkdir backups

Verify:

ls -l

Step 10 — Create Files

Create harmless training files:

touch documents/server-info.txt
touch documents/admin-notes.txt

Verify:

ls -l documents

Step 11 — Write Content

Add some lab information:

echo "Linux Administration Lab" > documents/server-info.txt

Read it:

cat documents/server-info.txt

Append another line:

echo "Hostname: $(hostname)" >> documents/server-info.txt

Review:

cat documents/server-info.txt

Important Concept

Understand:

versus:

>>

> writes output to a file and can replace existing contents.

>> appends output.

Be careful when redirecting output into important configuration files.

Step 12 — Copy Files

cp documents/server-info.txt backups/server-info.bak

Verify:

ls -l backups

Step 13 — Move and Rename Files

mv documents/admin-notes.txt documents/operations-notes.txt

Verify:

ls -l documents

Step 14 — Search for Files

From your lab directory:

find . -name "server-info*"

Understand:

Search Location

Search Criteria

Matching Results

Part 04 — Work With Text

Linux administrators frequently work with:

Configuration Files

Logs

Reports

Command Output

Step 15 — Read Files Safely

Practice:

cat documents/server-info.txt

For longer files, tools such as:

less /etc/services

may be more practical.

Exit less with:

Step 16 — View Beginning and End

Practice against an appropriate readable text file:

head /etc/services

and:

tail /etc/services

Step 17 — Search Text

Example:

grep "ssh" /etc/services

The exact output depends on the system.

Step 18 — Use Pipes

Run:

cat /etc/services | grep "ssh"

Conceptually:

Command 1
   ↓
Output
   ↓
Pipe
   ↓
Command 2

A more direct form is often:

grep "ssh" /etc/services

The exercise demonstrates how pipelines work.

Part 05 — Review Users

Linux identities are fundamental to both administration and security.

Review:

cat /etc/passwd

Do not interpret this file as containing plaintext passwords.

Modern Linux systems normally store password-verifier information separately with restricted access.

Step 19 — Understand passwd Entries

A typical entry conceptually contains:

Username

UID

GID

Description

Home Directory

Login Shell

Step 20 — Find Your Account

Use:

getent passwd "$(whoami)"

Record:

Username:

UID:

GID:

Home:

Shell:

Step 21 — Review Groups

Run:

groups

Then:

getent group

You do not need to memorize every system group.

Focus on understanding:

User
   ↓
Group Membership
   ↓
Access

Part 06 — Create a Training Group

The following exercises require administrative authorization on your lab VM.

Create a training group:

sudo groupadd labadmins

Verify:

getent group labadmins

Step 22 — Create a Training User

Create:

sudo useradd -m labuser

Verify:

getent passwd labuser

Depending on your distribution and lab objectives, password configuration can be handled through your normal approved account-management process.

Step 23 — Add User to Group

sudo usermod -aG labadmins labuser

Verify:

id labuser

You should see:

labadmins

among the user’s groups.

Important Administrative Lesson

Be careful with group modification.

Your objective is:

Add Membership

without accidentally removing required existing memberships.

Part 07 — Linux Permissions

Create a shared training directory:

sudo mkdir -p /srv/linux-admin-lab

Review:

ls -ld /srv/linux-admin-lab

Step 24 — Configure Group Ownership

Assign the training group:

sudo chown root:labadmins /srv/linux-admin-lab

Verify:

ls -ld /srv/linux-admin-lab

Step 25 — Configure Permissions

Set:

sudo chmod 770 /srv/linux-admin-lab

Review:

ls -ld /srv/linux-admin-lab

Interpret:

Owner:
rwx

Group:
rwx

Others:
---

Permission Model

OWNER
   ↓
Read Write Execute

GROUP
   ↓
Read Write Execute

OTHERS
   ↓
No Access

Step 26 — Understand Numeric Permissions

Remember:

Read    = 4

Write   = 2

Execute = 1

Therefore:

7 = rwx

6 = rw-

5 = r-x

4 = r--

0 = ---

Security Question

Why is:

usually a poor default for sensitive directories?

Because it may provide unnecessary access to:

Other Users

A better approach is:

Business Requirement
      ↓
Required Users/Groups
      ↓
Minimum Permission

Part 08 — Directory Permissions

Directory permissions have important semantics.

For a directory:

Read

relates to listing directory entries.

Write

relates to creating/removing entries.

Execute

relates to traversing/accessing entries through the directory.

Understanding this is critical when troubleshooting access problems.

Part 09 — Inspect Processes

Run:

ps

Then:

ps aux

Review fields such as:

USER

PID

CPU

MEMORY

COMMAND

Step 27 — Investigate Your Shell

Find your current shell process.

You can inspect your shell PID with:

echo $$

Then:

ps -p $$ -o pid,ppid,user,cmd

Observe:

PID

PPID

User

Command

Process Relationship

Parent Process
      ↓
Child Process
      ↓
Child Process

Process ancestry is extremely useful during incident investigation.

Step 28 — Real-Time Process Monitoring

If available:

top

Observe:

CPU

Memory

Load

Processes

Exit with:

Security Perspective

Unexpected resource consumption may result from:

Legitimate Workload

Application Failure

Misconfiguration

Runaway Process

Unexpected Software

Evidence must determine which.

Part 10 — Create a Safe Background Process

Run:

sleep 300 &

The shell should display a background job.

Run:

jobs

Find it:

ps -ef | grep "[s]leep 300"

Step 29 — Stop the Training Process

Use the job mechanism where appropriate:

kill %1

Then:

jobs

The exact job number may differ if other background jobs exist.

Important Lesson

Do not use:

kill -9

as your first response to every process problem.

Prefer:

Understand Process
      ↓
Request Graceful Termination
      ↓
Escalate Only if Necessary

Part 11 — Review Services

Modern Linux distributions commonly use systemd.

Check:

systemctl --version

Then review running services:

systemctl --type=service --state=running

Step 30 — Select a Harmless Service

Choose a service already present on your lab VM.

For example, your environment may have an SSH service.

Review status using the correct service name for your distribution.

Conceptually:

systemctl status <service-name>

Observe

Loaded

Active

PID

Recent Logs

Step 31 — Understand Service States

Know the distinction between:

Running Now

and:

Configured to Start Automatically

These are different operational states.

Service Lifecycle

Installed
   ↓
Configured
   ↓
Started
   ↓
Enabled
   ↓
Monitored

Part 12 — Review Service Logs

For a selected systemd service:

journalctl -u <service-name>

For recent entries:

journalctl -u <service-name> -n 20

Troubleshooting Pattern

Service Problem
      ↓
Status
      ↓
Logs
      ↓
Configuration
      ↓
Dependencies
      ↓
Permissions
      ↓
Network

Part 13 — Package Management

First determine your distribution.

Debian/Ubuntu-oriented systems commonly use:

APT / dpkg

Red Hat-oriented systems commonly use:

DNF / RPM

Step 32 — Inspect Installed Packages

On Debian-family systems, an example is:

dpkg -l

On RPM-family systems:

rpm -qa

Do not install or remove packages blindly.

Step 33 — Query a Package

Choose a known installed package and inspect its information using the appropriate package manager.

Your goal is to understand:

Package Name

Version

Architecture

Source

Security Perspective

Package management affects:

Vulnerability Management

Patch Management

Software Inventory

Supply-Chain Security

Part 14 — Review Storage

Run:

lsblk

Observe:

Disk

Partition

Size

Mount Point

Then:

df -h

Review filesystem utilization.

Step 34 — Check Your Lab Directory Size

Run:

du -sh ~/linux-admin-lab

Understand:

df

versus:

du

Conceptually:

df
→ Filesystem Utilization

du
→ File/Directory Utilization

Step 35 — Review Filesystem Types

Run:

df -Th

Record:

Filesystem

Type

Size

Used

Available

Mount Point

Step 36 — Review Mounts

Use:

findmnt

Observe the relationship:

Device
   ↓
Filesystem
   ↓
Mount Point

Important Safety Note

Do not practice destructive storage operations against your primary system disk.

Partitioning, formatting, and filesystem creation should be performed only on:

Disposable Lab Storage

Part 15 — Review Inodes

Run:

df -i

Why?

Because:

Free Disk Space

does not always mean:

New Files Can Be Created

A filesystem can run out of available inodes.

Troubleshooting Model

No Space Left
      ↓
Check Capacity
      +
Check Inodes

Part 16 — Review Networking

Run:

ip addr

Record:

Interface

State

IP Address

Step 37 — Review Routes

Run:

ip route

Identify:

Connected Routes

Default Route

Gateway

Step 38 — Review Hostname

hostname

Then, where appropriate:

hostname -f

The fully qualified hostname may depend on local DNS and host configuration.

Step 39 — Test Basic Connectivity

In your authorized lab network, test an approved reachable destination.

ping -c 4 <approved-destination>

Remember:

Ping Failure

does not automatically prove:

Host Is Down

ICMP may be filtered.

Part 17 — Review DNS

If available, use an appropriate DNS lookup utility installed in your environment.

Your troubleshooting model is:

Can Reach IP?
      ↓
Can Resolve Name?
      ↓
Can Reach Service?

Separating these layers prevents confusion.

Part 18 — Review Listening Ports

Run:

ss -lnt

For a broader socket view:

ss -lntu

With appropriate privilege, process information may also be available:

sudo ss -lntup

Record

Choose a few listening services and document:

Protocol

Local Address

Port

Process/Service

Expected?

Security Perspective

Every listening service should answer:

What Is It?

Who Owns It?

Why Is It Running?

Who Can Reach It?

Is It Required?

Part 19 — Network Troubleshooting Workflow

When connectivity fails, use:

01 Interface

02 IP Address

03 Subnet

04 Route

05 Gateway

06 DNS

07 Listening Port

08 Firewall

09 Application

Avoid jumping directly to:

Restart Everything

Part 20 — Review System Logs

Depending on your distribution, logs may be available through:

systemd journal

and/or files under:

/var/log

Start with:

journalctl -n 50

Review only authorized system information.

Step 40 — Review Boot Logs

journalctl -b

This can help investigate:

Boot Problems

Service Failures

Device Problems

Configuration Errors

Step 41 — Review Authentication Activity

Authentication logging differs across distributions.

Possible sources include:

systemd Journal

/var/log/auth.log

/var/log/secure

Do not assume every distribution uses the same file.

Security Perspective

Authentication evidence may help investigate:

Successful Logins

Failed Logins

sudo Activity

Account Problems

Part 21 — Review Logged-In Users

Run:

who

Then:

Observe:

User

Terminal

Login Time

Source

Current Activity

Where available:

last

Use this to understand historical login activity.

Security Question

Suppose you find:

Successful Login

Unknown Source

Privileged User

Unexpected Time

Do not immediately conclude compromise.

Instead:

Validate Identity
      ↓
Validate Source
      ↓
Review Authentication Evidence
      ↓
Review Activity
      ↓
Build Timeline

Part 22 — Review Scheduled Tasks

Scheduled tasks are useful for:

Maintenance

Backups

Automation

Reporting

They are also security-relevant because unauthorized scheduled execution can provide persistence.

Step 43 — Review Your Cron Configuration

Run:

crontab -l

If no personal crontab exists, that is acceptable.

Review system scheduling locations appropriate to your distribution, without modifying them.

Investigation Questions

Which User Runs It?

What Command Executes?

When?

Who Created It?

Is It Required?

Part 23 — Review Environment Variables

Run:

env

Review variables such as:

HOME

USER

SHELL

PATH

Step 44 — Inspect PATH

echo "$PATH"

Understand:

Command Entered
      ↓
Shell Searches PATH
      ↓
Executable Found
      ↓
Command Runs

Security Perspective

PATH configuration matters because executable search order can affect which program is executed.

Part 24 — Review System Resource Health

Collect:

uptime

Then:

free -h

Then:

df -h

Then review processes:

ps aux

Health Snapshot

Record:

Load:

Memory:

Swap:

Disk:

Top Processes:

Unexpected Conditions:

Part 25 — Create a System Inventory Report

Return to your lab workspace:

cd ~/linux-admin-lab

Create:

touch system-inventory.txt

Collect non-sensitive information into the report.

For example:

echo "Linux Administration Inventory" > system-inventory.txt
echo "Hostname: $(hostname)" >> system-inventory.txt
echo "Kernel: $(uname -r)" >> system-inventory.txt
echo "Current User: $(whoami)" >> system-inventory.txt
echo "Date: $(date)" >> system-inventory.txt

Review:

cat system-inventory.txt

Part 26 — Build a Simple Administration Script

Create:

nano system-check.sh

or use another text editor available in your environment.

Add:

#!/bin/bash

echo "Linux Administration System Check"
echo "================================="
echo "Hostname: $(hostname)"
echo "Date: $(date)"
echo "Current User: $(whoami)"
echo
echo "Uptime:"
uptime
echo
echo "Memory:"
free -h
echo
echo "Filesystem Usage:"
df -h
echo
echo "Network Interfaces:"
ip -brief addr

Save the file.

Step 45 — Make It Executable

chmod u+x system-check.sh

Run:

./system-check.sh

What You Just Built

You transformed:

Multiple Manual Checks

into:

Repeatable Administration

This is your bridge toward:

Shell Automation

Ansible

RHCE

DevOps

Part 27 — Troubleshooting Exercise 01

Scenario

A user reports:

I Cannot Access
the Shared Directory

Use:

USER
  ↓
GROUP
  ↓
OWNER
  ↓
PERMISSIONS
  ↓
PARENT DIRECTORY
  ↓
ACL / SECURITY POLICY

Questions:

Which user is affected?
Which groups does the user belong to?
Who owns the directory?
Which group owns it?
What are the permissions?
Does the user have effective access?
Is another security layer involved?

Part 28 — Troubleshooting Exercise 02

Scenario

An application team reports:

Service Is Not Running

Use:

SERVICE STATUS
      ↓
LOGS
      ↓
CONFIGURATION
      ↓
DEPENDENCIES
      ↓
PERMISSIONS
      ↓
PORT
      ↓
SECURITY CONTROL

Do not begin by randomly restarting services.

Part 29 — Troubleshooting Exercise 03

Scenario

A user reports:

Server Cannot Reach
an Application

Use:

Interface
   ↓
IP
   ↓
Route
   ↓
DNS
   ↓
Port
   ↓
Firewall
   ↓
Application

Document which layer fails.

Part 30 — Troubleshooting Exercise 04

Scenario

An application reports:

No Space Left on Device

Investigate:

Filesystem Capacity

Inodes

Large Directories

Unexpected Growth

Mount State

Do not delete files until you understand:

What They Are

Who Owns Them

Why They Exist

Whether Retention Is Required

Part 31 — Troubleshooting Exercise 05

Scenario

A server becomes unusually slow.

Review:

CPU

Load

Memory

Swap

Processes

Storage

Network

Logs

Do not assume:

High CPU

is always the root cause.

Part 32 — Administrative Troubleshooting Method

Use this method for almost every Linux problem:

01 Understand the Symptom

02 Determine Scope

03 Collect Evidence

04 Identify the Layer

05 Review Recent Changes

06 Form a Hypothesis

07 Test Safely

08 Apply Minimum Fix

09 Validate

10 Document

Part 33 — Security Review

Now perform a basic administrative security review.

Do not change anything yet.

Review:

Users

Groups

Administrative Access

Permissions

Services

Packages

Listening Ports

Logs

Scheduled Tasks

Step 46 — User Review

Ask:

Are All Accounts Recognized?

Are Service Accounts Appropriate?

Are Disabled Accounts Still Active?

Are Group Memberships Appropriate?

Step 47 — Privilege Review

Ask:

Who Has Administrative Access?

Why?

Is It Required?

Is It Excessive?

Step 48 — Service Review

Ask:

Which Services Are Running?

Which Are Network Accessible?

Are All Required?

Step 49 — Package Review

Ask:

What Software Is Installed?

Is It Required?

Is It Supported?

Is It Maintained?

Step 50 — Logging Review

Ask:

Are Logs Available?

Are Authentication Events Recorded?

Are Service Events Recorded?

Can Activity Be Investigated?

Part 34 — Finding Example

Suppose you identify an unnecessary network service.

Document it professionally.

Finding:
Unnecessary Network Service Enabled

Observation:
A network-facing service is running on
the Linux server without a confirmed
business requirement.

Security Concern:
Unnecessary services increase the
system's reachable attack surface.

Recommendation:
Confirm application ownership and
business requirements. If the service
is unnecessary, disable it through the
approved change-management process.

Part 35 — Finding Example: Excessive Permissions

Finding:
Overly Broad Directory Permissions

Observation:
A shared directory grants access beyond
the users who require the resource.

Security Concern:
Unauthorized users may be able to read,
modify, or delete data.

Recommendation:
Map required access to approved users
and groups and apply least-privilege
filesystem permissions.

Part 36 — Finding Example: Administrative Access

Finding:
Administrative Access Requires Review

Observation:
One or more accounts have elevated
administrative permissions.

Security Concern:
Excessive administrative access
increases the impact of credential
compromise or administrative error.

Recommendation:
Validate business requirements and
reduce administrative access to the
minimum permissions required.

Part 37 — Create Your Administration Report

Create a report containing:

Linux Administration Lab Report

Include:

1. System Information

Hostname

Distribution

Version

Kernel

Architecture

Uptime

2. Identity

Current User

Administrative Access

Training User

Training Group

3. Filesystem

Important Mounts

Filesystem Usage

Inode Usage

4. Services

Important Running Services

Startup State

Observed Issues

5. Networking

Interfaces

IP Addresses

Default Route

Listening Ports

6. Logging

Journal Available?

Authentication Evidence?

Service Logs?

7. Security Observations

For each:

Finding

Observation

Risk

Recommendation

Part 38 — Evidence Checklist

Capture appropriate non-sensitive evidence for:

Do not include:

Passwords

Private SSH Keys

Tokens

Sensitive Application Secrets

in your lab report.

Part 39 — Clean Up the Training Identities

If these identities were created only for this disposable lab and are no longer required, remove them after completing your evidence collection.

First verify:

Training User:
labuser

Training Group:
labadmins

Then follow your distribution’s approved account-removal process.

For example, on many systems:

sudo userdel -r labuser

Then, after verifying the group is no longer required:

sudo groupdel labadmins

Do not remove real system or application identities.

Part 40 — Clean Up Shared Lab Data

If:

/srv/linux-admin-lab

was created only for this exercise, verify its contents before removal.

Never use recursive deletion against an unverified path.

A professional administrator always confirms:

Target

Contents

Business Requirement

Backup Requirement

before deletion.

Lab Validation

You should now be able to answer:

Which Linux system am I administering?

Which identity am I using?

How is the filesystem organized?

Who has access?

Which processes are running?

Which services are active?

What software is installed?

How is storage configured?

How is the server connected?

Which ports are listening?

Where are the logs?

Which scheduled tasks exist?

Is the system healthy?

Can I troubleshoot common failures?

Administrator’s Mental Model

When you receive an unfamiliar Linux server, use:

SYSTEM
  ↓
IDENTITY
  ↓
FILES
  ↓
PROCESSES
  ↓
SERVICES
  ↓
SOFTWARE
  ↓
STORAGE
  ↓
NETWORK
  ↓
LOGGING
  ↓
SECURITY

Do not randomly execute commands.

Move systematically through the system.

Linux Administration vs Cybersecurity

Linux administration and Linux security are closely connected.

ADMINISTRATION
      ↓
Understand Expected State

SECURITY
      ↓
Identify Unexpected State

For example:

Administrator:
Which service should be running?

Security Analyst:
Why is this unexpected service running?

Another example:

Administrator:
Which users require sudo?

Security Analyst:
Why does this unexpected account have sudo?

This is why strong Linux administration knowledge is so valuable in cybersecurity.

Career Connection

The skills practiced in this lab directly support:

Linux Administrator

System Administrator

Cloud Engineer

DevOps Engineer

SOC Analyst

Security Engineer

Cloud Security Engineer

Platform Engineer

Interview Scenarios

Scenario 01

A Linux server is slow. What do you investigate?

Look across:

Load

CPU

Memory

Swap

Processes

Storage

I/O

Network

Logs

Recent Changes

Scenario 02

A service does not start. What do you check?

Status

Logs

Configuration

Dependencies

Permissions

Port

Security Controls

Scenario 03

A user cannot access a directory. What do you review?

Identity

Groups

Ownership

Permissions

Parent Directories

ACLs

Additional Security Controls

Scenario 04

A server has free disk space but cannot create files. Why?

One possible cause is:

Inode Exhaustion

Scenario 05

You discover an unknown listening port. What do you do?

Port
  ↓
Process
  ↓
User
  ↓
Service
  ↓
Business Requirement
  ↓
Network Exposure

30 Linux Administration Interview Questions

How do you identify the Linux distribution?
How do you identify the running kernel?
What is the difference between UID and GID?
What information does id provide?
What is the purpose of /etc/passwd?
What is the difference between a user and a group?
What do Linux rwx permissions represent?
What does permission 750 mean?
What is the purpose of chown?
What is the difference between > and >>?
What is a Linux process?
What is the difference between PID and PPID?
How would you investigate a high-CPU process?
What is systemd?
What is the difference between starting and enabling a service?
How would you troubleshoot a failed service?
What is a package manager?
Why is package inventory security-relevant?
What does df tell you?
What does du tell you?
What is an inode?
What is a mount point?
What information does ip addr provide?
What does ip route show?
How would you identify listening ports?
Why might ping fail even when a host is available?
Why are logs important?
Why should scheduled tasks be reviewed?
Why should administrators avoid unnecessary root usage?
What troubleshooting methodology do you use for Linux problems?

Lab Completion Checklist

System

Files

IAM

Permissions

Processes

Reviewed processes
Identified PID/PPID
Created safe background process
Terminated training process safely

Services

Reviewed running services
Inspected service status
Reviewed service logs
Understood running vs enabled state

Packages

Identified package-management family
Reviewed installed packages
Understood package-security implications

Storage

Network

Logs

Reviewed system journal
Reviewed boot events
Identified authentication evidence
Reviewed login history

Automation

Reviewed environment variables
Reviewed scheduled tasks
Built simple system-check script

Security

Documentation

Created system inventory
Recorded evidence
Documented findings
Created administration report

Mission Accomplished

You have now performed a practical Linux administration workflow covering:

System Discovery

Filesystem Administration

Identity Management

Permission Management

Process Management

Service Management

Package Review

Storage Administration

Networking

Logging

Automation

Troubleshooting

Security Review

More importantly, you practiced the professional Linux workflow:

OBSERVE
   ↓
UNDERSTAND
   ↓
CONFIGURE
   ↓
VALIDATE
   ↓
TROUBLESHOOT
   ↓
DOCUMENT

This foundation is critical because secure Linux systems cannot be built without first understanding how Linux systems are administered.

What’s Next?

➡️ Lab 02 — Linux Hardening

In the next lab, you will take a functioning Linux server and move from:

Linux Administration

to:

Secure Linux Administration

You will work through:

Security Baseline
      ↓
Account Hardening
      ↓
Privilege Review
      ↓
SSH Hardening
      ↓
Filesystem Security
      ↓
Service Reduction
      ↓
Package and Patch Review
      ↓
Host Firewall
      ↓
Logging and Auditing
      ↓
Security Validation

Your Linux lab journey continues:

Lab 01 — Linux Administration
        ↓
Lab 02 — Linux Hardening
        ↓
Lab 03 — Linux IAM
        ↓
Lab 04 — Linux Networking
        ↓
Lab 05 — Linux Security
        ↓
Linux Incident Investigation
        ↓
Linux Security Assessment
        ↓
Linux Server Hardening