Question 1

What are Linux file permissions, and how do you read and modify them using chmod?

Accepted Answer

Linux file permissions control who can read, write, or execute a file or directory. Every file has three permission sets: one for the owner, one for the group, and one for everyone else. Understanding permissions is fundamental to keeping systems secure and operational.

Each permission set has three bits: read (r), write (w), and execute (x). When you run ls -l, you see something like -rwxr-xr-- which breaks down as: the first character indicates the file type (dash for regular file, d for directory), then three groups of three characters representing owner, group, and others permissions.

Question 2

How do you view and manage running processes in Linux? Explain the key commands and signals used.

Accepted Answer

Process management is one of the most important skills for an SRE because you need to monitor what is running, diagnose resource-hungry processes, and gracefully stop or restart services when needed.

The ps command shows a snapshot of current processes. The most common usage is ps aux, which lists all processes with details including the user, CPU usage, memory usage, and the command that started each process. For a more focused view, ps -ef shows processes in a tree-like format with parent process IDs, which helps you understand process relationships.

The top command provides a real-tim

Question 3

What is the difference between monitoring and observability, and why do SREs need both?

Accepted Answer

Monitoring and observability are related but distinct concepts that together give SREs the ability to understand and maintain system health. Understanding the difference helps you build effective systems for detecting and diagnosing problems.

Monitoring is about collecting predefined data points and checking them against known thresholds. You decide in advance what to watch: CPU usage above 90%, response time above 500 milliseconds, error rate above 1%. When a threshold is crossed, an alert fires. Monitoring answers the question "is something wrong?" It is excellent for known failure modes

Question 4

What is Prometheus, and how does it collect and store metrics? Explain the pull-based model.

Accepted Answer

Prometheus is an open-source monitoring and alerting toolkit that has become the standard for metrics collection in cloud-native environments. Originally built at SoundCloud and now a graduated CNCF project, it is designed for reliability and simplicity, which makes it a natural fit for SRE work.

Prometheus uses a pull-based model, which means it actively reaches out to your services to collect metrics rather than waiting for services to push data to it. Each service exposes a metrics endpoint, typically at /metrics, in a simple text format. Prometheus is configured with a list of targets (

Question 5

What is a production incident, and how do SRE teams typically classify incident severity levels?

Accepted Answer

A production incident is any unplanned event that disrupts or degrades a service for users. This includes complete outages, performance degradation, data inconsistencies, security breaches, and any situation where the service is not meeting its reliability targets. Incidents are a normal part of operating complex systems, and having a clear framework for handling them is what separates reactive firefighting from professional incident management.

Severity classification helps teams prioritize response effort and communication. While exact definitions vary by organization, a common four-level

Question 6

What does it mean to be on-call as an SRE, and what are the key responsibilities and best practices?

Accepted Answer

Being on-call means you are the designated first responder for production issues during a defined time period. When an alert fires, the on-call engineer receives a page through a tool like PagerDuty or Opsgenie and is responsible for acknowledging it, assessing the situation, and either resolving the issue or escalating to the right people. On-call is a fundamental part of SRE because it connects the team that builds reliability into systems with the real-world consequences of reliability failures.

Typical on-call rotations last one week, with the schedule distributed among team members so

Question 7

What are SLIs, SLOs, and SLAs, and how do they relate to each other in site reliability engineering?

Accepted Answer

SLIs, SLOs, and SLAs form a hierarchy that connects technical measurements to business commitments. Understanding this hierarchy is fundamental to SRE because it provides the framework for making reliability decisions based on data rather than gut feeling.

A Service Level Indicator (SLI) is a quantitative measurement of some aspect of the service that users care about. It is the raw data point. Common SLIs include request latency (how long a request takes to complete), availability (the proportion of requests that succeed), throughput (the number of requests the system can handle), and erro

Question 8

How do you choose the right SLIs for a web service? What makes a good SLI versus a bad one?

Accepted Answer

Choosing the right SLIs is critical because they form the foundation of your entire reliability framework. Bad SLIs lead to misaligned priorities where the team optimizes for metrics that do not reflect what users actually experience. Good SLIs directly capture user happiness.

The fundamental principle is that SLIs should measure things users care about from the user's perspective. A good SLI for a web service answers questions like: can users successfully complete their actions (availability), how long do they wait (latency), and is the data they receive correct (correctness)?

Good SLIs

Question 9

What are the essential Bash scripting concepts an SRE should know, and how do you write a reliable script for production use?

Accepted Answer

Bash scripting is the most fundamental automation skill for an SRE because it is available on virtually every Linux system without installing anything extra. Whether you are automating log cleanup, health checks, or deployment tasks, Bash is often the fastest path from manual task to automated solution.

Every production Bash script should start with a proper shebang line (#!/bin/bash) and strict mode settings. The set -euo pipefail combination is essential: -e makes the script exit immediately if any command fails, -u treats unset variables as errors instead of silently expanding to empty s

Question 10

How do cron jobs work in Linux, and what are the best practices for scheduling and managing automated tasks?

Accepted Answer

Cron is the standard Linux job scheduler that runs commands or scripts at specified times and intervals. For SREs, cron jobs handle routine tasks like log rotation, backup verification, certificate renewal checks, metrics collection, and cleanup of temporary files. Understanding cron is essential because poorly managed cron jobs are a frequent source of production issues.

The cron schedule format has five fields: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7, where both 0 and 7 represent Sunday). An asterisk means "every." For example, 30 2 * * * runs a

SRE / Platform Engineer

Topics

Linux & System Administration

Monitoring & Observability Basics

Incident Response Fundamentals

SLIs, SLOs & SLAs

Basic Automation & Scripting

Mock Interview

Quick Stats