Linux & Shell Scripting Interview Questions & Answers | Preplance

Mobile App Now Available

Master Interviews
Anywhere, Anytime

Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.

Get it on

Google Play

4.9/5 Rating on Store

186. Explain the complete process of creating, modifying, and deleting user accounts. Include commands, files involved, and best practices.

Difficulty: MediumType: SubjectiveTopic: User Management

Create user with useradd: useradd -m -s /bin/bash -G sudo,docker -c 'Full Name' username creates user with home directory (-m), bash shell (-s), adds to groups (-G), and sets comment (-c). Set password immediately with passwd username for security. Verify creation with id username showing UID, GID, and groups. Modify users with usermod: usermod -aG newgroup username adds to supplementary group (append, doesn't remove existing), usermod -s /bin/zsh username changes shell, usermod -L username locks account (prevents login), usermod -U username unlocks. Change primary group with usermod -g groupname username. Rename user with usermod -l newname oldname, but manually rename home directory with mv /home/oldname /home/newname. Delete users with userdel: userdel username removes user but leaves home directory and files, userdel -r username removes user and home directory (use caution - data loss). Check for running processes with ps -u username before deletion. Find files owned by deleted users with find / -uid UID -ls, then reassign ownership or delete as appropriate. Best practices: use consistent UID ranges (1000+ for regular users), enforce strong passwords with PAM configuration, lock accounts rather than deleting for users who leave (preserves file ownership), audit user access regularly, document account purposes especially for service accounts, set account expiration dates with chage for temporary accounts, and maintain user provisioning/deprovisioning procedures. Security considerations: disable root SSH login (PermitRootLogin no in sshd_config), require key-based authentication, set password policies (minimum length, complexity, expiration), monitor for unauthorized accounts in /etc/passwd, and regularly review sudo access. Automate user management with configuration management tools like Ansible or Puppet for consistency across multiple systems.

187. How do you troubleshoot permission denied errors? Describe the systematic approach to identifying and fixing permission issues.

Difficulty: HardType: SubjectiveTopic: File Permissions

Start by identifying what operation failed and what user performed it. Check file permissions with ls -l filename, showing owner, group, and permissions. Check user's identity and groups with id username or whoami and groups. Match user's groups against file's group to understand access level. Check if special permissions (setuid, setgid, sticky bit) are involved with ls -l. Verify directory permissions in the path. To access a file, you need execute permission on all parent directories. Example: accessing /home/user/data/file.txt requires execute on /, /home, /home/user, and /home/user/data, plus read on file.txt. Use namei -l /path/to/file to show permissions for entire path, identifying where access fails. Check ACLs with getfacl filename if '+' appears in ls -l output. ACLs might grant or deny access beyond standard permissions. Check SELinux context with ls -Z filename if SELinux is enabled - wrong context causes permission denied even with correct file permissions. Verify with getenforce showing Enforcing/Permissive/Disabled. Check audit logs at /var/log/audit/audit.log for SELinux denials. Common fixes: chmod to adjust file permissions, chown to change ownership, chgrp to change group, usermod -aG to add user to required group (requires logout/login), setfacl to add specific user/group access, chcon or restorecon to fix SELinux contexts. For directories, ensure execute permission. For shared access, consider creating shared group, setting group ownership, and using 2770 permissions (rwxrws--- with setgid). Preventive measures: use umask to set default permissions for new files (e.g., umask 0022 for 644 files, 755 directories), document permission schemes, establish ownership standards for shared directories, use group-based access control over ACLs when possible for simplicity, and test permission changes before applying to production. Understanding permission inheritance and defaults prevents future issues.

188. Explain the /etc/sudoers file structure and how to configure granular sudo access. Include examples of different sudo configurations.

Difficulty: HardType: SubjectiveTopic: Sudoers Config

The /etc/sudoers file controls sudo access and must be edited with visudo command (never edit directly - visudo validates syntax preventing lockout). Basic syntax: user host=(runas_user:runas_group) commands. Example: john ALL=(ALL:ALL) ALL gives john full sudo access on all hosts, running any command as any user/group. User specifications: root ALL=(ALL:ALL) ALL (root has full access), %sudo ALL=(ALL:ALL) ALL (group specification with % prefix - all sudo group members have full access), john ALL=(ALL) NOPASSWD: ALL (john doesn't need password for sudo), jane ALL=/usr/bin/systemctl,/usr/bin/service (jane can only run specific commands with sudo). Command aliases simplify management: Cmnd_Alias SERVICES = /usr/bin/systemctl, /usr/bin/service then john ALL=(root) SERVICES allows john to run service management commands. User aliases: User_Alias ADMINS = john, jane, bob then ADMINS ALL=(ALL) ALL gives multiple users access. Host aliases for multi-host environments: Host_Alias WEBSERVERS = web1, web2. Advanced configurations: john ALL=(apache) NOPASSWD: /usr/bin/systemctl restart httpd allows john to restart apache as apache user without password, useful for deployment scripts. Restrict to specific hosts: john WEBSERVERS=(ALL) ALL only on webservers. Deny commands: john ALL=(ALL) ALL, !/usr/bin/rm -rf / (whitelist with blacklist exceptions, though blacklisting is generally ineffective). Best practices: use visudo always (syntax checking), prefer groups over individual users (easier management), use NOPASSWD sparingly (security risk), be specific with command paths (prevents PATH manipulation), validate command arguments where possible, include sudoers.d directory (includedir /etc/sudoers.d) for modular configuration, test sudo rules thoroughly, and document why each rule exists. Regular audits prevent permission creep.

189. Explain password management in Linux including /etc/shadow, password policies, and the chage command. How do you enforce password complexity and expiration?

Difficulty: HardType: SubjectiveTopic: Password Management

The /etc/shadow file stores encrypted passwords and password aging information, readable only by root. Format: username:encrypted_password:last_change:min:max:warn:inactive:expire:reserved. Last_change is days since epoch of last password change, min is minimum days between changes, max is maximum days before required change, warn is warning days before expiration, inactive is days after expiration before account locks, expire is absolute expiration date. Manage password aging with chage: chage -l username displays aging information, chage -M 90 username sets maximum 90 days between password changes, chage -m 7 username sets minimum 7 days between changes (prevents immediate password change back), chage -W 14 username warns 14 days before expiration, chage -E 2024-12-31 username sets account expiration date, chage -I 30 username locks account 30 days after password expires. Enforce password complexity with PAM (Pluggable Authentication Modules) configuration in /etc/pam.d/common-password (Debian/Ubuntu) or /etc/pam.d/system-auth (RHEL/CentOS). Install libpam-pwquality package. Configure with pam_pwquality.so: minlen=12 (minimum length), dcredit=-1 (require digit), ucredit=-1 (require uppercase), ocredit=-1 (require special char), lcredit=-1 (require lowercase), difok=3 (minimum character changes from old password), maxrepeat=2 (max repeated characters). Password history prevents reusing recent passwords: configure pam_unix.so remember=10 to remember last 10 passwords. Failed login attempts: pam_faillock.so locks accounts after N failed attempts within time window, mitigating brute force. Example: deny=5 unlock_time=900 locks after 5 failures for 15 minutes. Best practices: enforce minimum complexity (12+ characters, mixed case, numbers, symbols), regular password changes (60-90 days max age), prevent password reuse (remember last 10+), account lockout after failed attempts, user education on password security, consider key-based authentication over passwords for SSH, use password managers for complex passwords, and regular password audits with tools like John the Ripper (authorized testing only).

190. What are service accounts and how should they be managed? Explain best practices for creating and securing service accounts.

Difficulty: MediumType: SubjectiveTopic: Privilege Escalation

Service accounts are special user accounts for running services, applications, or automated processes rather than for human login. They typically have /sbin/nologin or /bin/false as shell preventing interactive login, and UIDs in system range (often 1-999). Examples: www-data for web servers, mysql for MySQL database, nobody for unprivileged operations. Create service accounts with useradd -r -s /sbin/nologin -c 'Service Description' servicename. The -r flag creates system account with UID in system range. Assign minimal necessary permissions following least privilege principle - service accounts should only access files/directories needed for their function. Use dedicated groups for service account permissions rather than giving broad access. Security best practices: disable password login (service accounts shouldn't have passwords), use SSH keys or other authentication mechanisms if remote access needed, restrict sudo access (service accounts rarely need sudo), set proper file ownership (service should own its files), use SELinux or AppArmor to confine service processes, regularly audit service account permissions, document each service account's purpose, and remove unused service accounts. For containerized environments, avoid root in containers - use USER directive in Dockerfile to run as non-root service account. For Kubernetes, use ServiceAccount resources with RBAC for permissions. For cloud platforms, use IAM roles instead of long-lived credentials. Never share service accounts across different services - each service should have dedicated account for auditing and isolation. Monitoring: track service account activity in logs, alert on unexpected access patterns (service accounts have predictable behavior), audit file access, and regularly review permissions. Use configuration management tools (Ansible, Puppet) to ensure consistent service account setup across systems. Document which human administrator is responsible for each service account.

191. Explain umask in Linux. How does it work and how do you calculate default permissions for new files and directories?

Difficulty: HardType: SubjectiveTopic: File Permissions

Umask (user file creation mask) defines default permissions for newly created files and directories by specifying which permission bits to remove from the default permissions. Default permissions before umask are 666 (rw-rw-rw-) for files and 777 (rwxrwxrwx) for directories. Umask subtracts permissions from these defaults. Calculation: umask 0022 (common default) removes write permission for group and others. For files: 666 - 022 = 644 (rw-r--r--). For directories: 777 - 022 = 755 (rwxr-xr-x). Note that umask 0002 would give 664 for files and 775 for directories, allowing group write access. More restrictive umask 0077 gives 600 files and 700 directories (owner-only access). Set umask temporarily with umask 0022 command (affects current shell session). Set permanently in ~/.bashrc, ~/.profile, or /etc/profile for system-wide defaults. View current umask with umask command showing octal value, or umask -S showing symbolic format (u=rwx,g=rx,o=rx). Different umask for different users by setting in individual profiles. Common umask values: 0022 (files 644, dirs 755) - standard for most users, allows others to read but not modify; 0002 (files 664, dirs 775) - collaborative environments where group members share write access; 0077 (files 600, dirs 700) - restrictive, only owner has access, used for sensitive data; 0000 (files 666, dirs 777) - fully permissive, rarely appropriate. Security considerations: more restrictive umask is more secure but less convenient for collaboration. Choose based on environment: single-user workstations can use 0022, shared servers might need 0002 for group collaboration, security-sensitive systems should use 0077. Remember umask affects default permissions - can always change permissions after creation with chmod. Understanding umask prevents permission issues with newly created files.

192. Explain setuid and setgid special permissions. Provide examples of when they're necessary and security implications.

Difficulty: HardType: SubjectiveTopic: Privilege Escalation

Setuid (Set User ID) on executable files causes the file to execute with owner's privileges instead of the executor's. When setuid bit is set on file owned by root, any user running it executes with root privileges. Indicated by 's' in owner execute position (rwsr-xr-x). Set with chmod u+s file or chmod 4755 file (4 in leading digit). Classic example: /usr/bin/passwd has setuid bit and is owned by root. Regular users need to modify /etc/shadow (root-only file) to change their password. Setuid allows passwd to run as root, modify shadow file, but only accepts user's own password change. Other examples: sudo, su, ping (needs raw sockets requiring root), mount (some implementations). Setgid (Set Group ID) on executables causes execution with file's group privileges. Indicated by 's' in group execute position (rwxr-sr-x). Set with chmod g+s file or chmod 2755 file. On directories, setgid causes new files to inherit directory's group instead of creator's primary group, useful for shared directories where all files should be group-owned. Setgid directory example: mkdir /shared/project && chgrp developers /shared/project && chmod 2775 /shared/project creates shared directory where all files inherit developers group ownership, allowing team collaboration. Without setgid, files would have creator's primary group, potentially breaking access for team members. Security implications: setuid/setgid are major security risks if misused - they're common attack vectors. Audit setuid files regularly: find / -perm -4000 -type f 2>/dev/null lists all setuid files. Review necessity, ensure secure coding (no shell command injection, buffer overflows, path manipulation). Remove setuid from unnecessary files. Avoid creating custom setuid programs unless absolutely necessary and thoroughly security-reviewed. Use capabilities instead of setuid where possible (more granular privileges). SELinux can restrict setuid operations. Understanding these permissions is critical for security hardening.

193. What are best practices for managing a multi-user Linux system? Discuss user isolation, resource limits, and security hardening.

Difficulty: HardType: SubjectiveTopic: Privilege Escalation

User isolation: each user should have separate home directory (mode 700) preventing other users from accessing their files. Use private groups (one group per user) as primary group. Avoid shared accounts - each person should have individual account for accountability. Separate service accounts from user accounts. Use PAM to restrict which users can login, which services they can use, and from where (IP restrictions). Resource limits with ulimit or /etc/security/limits.conf prevent users from consuming excessive resources. Set limits on: max processes (nproc), max open files (nofile), max file size (fsize), max CPU time (cpu), max memory (as, rss). Example: username hard nproc 100 limits user to 100 processes. Use cgroups for more sophisticated resource management including CPU shares, memory limits, and I/O priorities. Password policies: enforce strong passwords with pam_pwquality, set maximum password age with chage, implement account lockout after failed attempts with pam_faillock, require password on sudo unless specific exceptions, disable root login over SSH, and use key-based authentication where possible. Regular password audits detect weak passwords before attackers do. Access control: principle of least privilege - grant minimum necessary permissions. Use groups for permission management rather than ACLs when possible. Regularly audit user accounts removing inactive accounts (lastlog shows last login). Monitor suspicious activity with log analysis (failed login attempts, sudo usage, file access). Set up proper file ownership on shared directories with setgid and appropriate umask. Monitoring and auditing: enable audit logging with auditd, monitor logs for suspicious patterns (excessive failed logins, privilege escalation attempts, unusual file access), set up alerts for critical events, track sudo usage, and regularly review user list in /etc/passwd. Use centralized logging for multi-system environments. Implement file integrity monitoring (AIDE, Tripwire) to detect unauthorized changes to system files.

202. Describe a systematic approach to troubleshooting network connectivity issues. Include commands and diagnostic steps.

Difficulty: HardType: SubjectiveTopic: Network Diagnostics

Start with basic connectivity: ping 127.0.0.1 tests loopback interface ensuring TCP/IP stack works. Ping default gateway (ip route | grep default shows gateway) tests local network connectivity. Ping external IP like 8.8.8.8 (Google DNS) tests internet connectivity without DNS. If this works but domain names don't, the issue is DNS. Check interface configuration: ip addr shows IP addresses and interface status (UP/DOWN), ip link shows physical layer status. Verify correct IP address, subnet mask, and interface is UP. Check route table with ip route or route -n ensuring default gateway exists. Incorrect IP configuration or missing gateway prevents communication beyond local network. DNS troubleshooting: cat /etc/resolv.conf shows configured DNS servers. Test DNS with nslookup domain or dig domain. If resolution fails, try different DNS server: nslookup domain 8.8.8.8. Check /etc/hosts for local hostname overrides. NetworkManager or systemd-resolved might manage DNS configuration - check their status. Port and service testing: telnet host port or nc -zv host port tests specific port connectivity. Check if service is listening with netstat -tuln or ss -tuln. Verify firewall rules with iptables -L -n or firewall-cmd --list-all. Check if remote firewall blocks connection. Use tcpdump or wireshark for packet capture: tcpdump -i eth0 port 80 captures HTTP traffic for detailed analysis. Common issues and solutions: no IP address (DHCP problem - check dhclient or NetworkManager), wrong subnet (verify netmask), no default gateway (check routing), DNS failure (check resolv.conf and DNS server), firewall blocking (check iptables/firewalld), cable unplugged (check ip link for interface state), service not listening (check netstat and service status). Document findings and solutions for future reference.

203. Explain SSH key-based authentication and security best practices for SSH configuration. How do you set up and secure SSH access?

Difficulty: HardType: SubjectiveTopic: SSH Security

Generate SSH key pair with ssh-keygen -t rsa -b 4096 -C 'comment' creating private key (~/.ssh/id_rsa) and public key (~/.ssh/id_rsa.pub). Never share private key. Use ed25519 keys for better security with smaller key size: ssh-keygen -t ed25519. Protect private key with passphrase for additional security layer. Copy public key to remote server with ssh-copy-id user@host or manually append public key to ~/.ssh/authorized_keys on remote server with correct permissions (700 for .ssh directory, 600 for authorized_keys file). Test key authentication: ssh user@host should login without password. If prompted for password, check permissions and sshd_config settings. Secure SSH configuration in /etc/ssh/sshd_config: disable root login (PermitRootLogin no), disable password authentication (PasswordAuthentication no) after setting up keys, change default port (Port 2222) for security through obscurity, allow specific users (AllowUsers user1 user2), use Protocol 2 only, set LoginGraceTime 30 to prevent connection hanging attacks, limit authentication attempts (MaxAuthTries 3). Advanced security: use fail2ban to block brute force attempts by banning IPs with multiple failed logins, configure two-factor authentication with Google Authenticator PAM module, use SSH certificates instead of keys for large deployments, implement jump hosts/bastion servers for accessing internal networks, restrict SSH access by IP with firewall rules or TCPWrappers (/etc/hosts.allow, /etc/hosts.deny). Monitoring and auditing: monitor /var/log/auth.log for failed login attempts and suspicious activity, set up alerts for successful root logins or logins from unexpected IPs, regularly audit authorized_keys files for unauthorized entries, rotate SSH keys periodically, and review SSH configuration with tools like ssh-audit. Apply updates promptly to patch security vulnerabilities. Understanding SSH security is critical for protecting server access.

204. Explain firewall configuration in Linux using iptables and firewalld. How do you allow or block network traffic?

Difficulty: HardType: SubjectiveTopic: Firewall Tools

Iptables is the traditional Linux firewall managing packet filtering rules. Rules organized in chains (INPUT for incoming, OUTPUT for outgoing, FORWARD for routed packets) within tables (filter, nat, mangle). View rules with iptables -L -n -v. Rules processed sequentially - first matching rule applies, so order matters. Basic iptables rules: iptables -A INPUT -p tcp --dport 22 -j ACCEPT allows SSH, iptables -A INPUT -p tcp --dport 80 -j ACCEPT allows HTTP, iptables -A INPUT -s 192.168.1.0/24 -j ACCEPT allows traffic from specific subnet, iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT allows established connections. Set default policy: iptables -P INPUT DROP drops all not explicitly allowed. Persist iptables rules with iptables-save > /etc/iptables/rules.v4 and restore with iptables-restore < /etc/iptables/rules.v4. Install iptables-persistent package on Debian/Ubuntu for automatic persistence. Delete rule: iptables -D INPUT rule_number. Insert rule at specific position: iptables -I INPUT 1 rule inserts at top. Firewalld (default on RHEL/CentOS 7+) provides dynamic firewall management with zones concept. List zones: firewall-cmd --get-zones. Default zone: firewall-cmd --get-default-zone. Add service: firewall-cmd --add-service=http --permanent (permanent flag persists across reboots). Add port: firewall-cmd --add-port=8080/tcp --permanent. Reload: firewall-cmd --reload applies changes. Firewalld zones: public (default for public interfaces, limited access), internal (trusted internal networks), dmz (DMZ with limited external access), trusted (all traffic allowed). Rich rules provide advanced control: firewall-cmd --add-rich-rule='rule family=ipv4 source address=1.2.3.4 reject' --permanent. Understanding firewall management is essential for securing Linux servers against unauthorized access.

205. Explain DNS configuration in Linux including /etc/hosts, /etc/resolv.conf, and DNS troubleshooting commands.

Difficulty: MediumType: SubjectiveTopic: DNS Config

The /etc/hosts file provides static hostname-to-IP mappings checked before DNS queries. Format: IP_address hostname [aliases]. Example: 127.0.0.1 localhost, 192.168.1.10 server.local server. Changes take effect immediately. Use hosts file for local development, overriding DNS for specific hosts, or improving resolution speed for frequently accessed hosts. The /etc/resolv.conf file configures DNS servers for system-wide name resolution. Format: nameserver IP lists DNS servers (queries in order listed), search domain sets search domains for short hostnames, domain sets local domain. Example: nameserver 8.8.8.8, nameserver 8.8.4.4 uses Google DNS. Modern systems often have resolv.conf managed by systemd-resolved or NetworkManager - check for symlinks. Systemd-resolved manages DNS in modern systems. Configuration in /etc/systemd/resolved.conf. Check status: systemd-resolve --status or resolvectl status. Set DNS servers: resolvectl dns interface 8.8.8.8. Flush cache: resolvectl flush-caches. Resolution order: /etc/hosts → systemd-resolved cache → configured DNS servers → /etc/nsswitch.conf defines this order. DNS troubleshooting tools: nslookup domain shows DNS query result and server used. Dig (domain information groper) provides detailed DNS query information: dig domain shows A record, dig domain MX shows mail servers, dig @8.8.8.8 domain queries specific DNS server, dig +trace domain shows full DNS resolution path from root servers. Host command: host domain simpler output than dig. Common DNS issues: wrong DNS server (check resolv.conf), DNS server not responding (test with dig @server), caching issues (flush cache), local hosts file overriding DNS (check /etc/hosts), NetworkManager overwriting resolv.conf (make immutable with chattr +i or configure NetworkManager). Understanding DNS configuration is crucial for network connectivity and troubleshooting name resolution issues.

206. Explain advanced package management including repository configuration, package dependencies, and resolving package conflicts.

Difficulty: HardType: SubjectiveTopic: Package Management

Repository configuration for Debian/Ubuntu in /etc/apt/sources.list and /etc/apt/sources.list.d/*.list. Format: deb http://repo.url/ubuntu focal main restricted adds repository for Ubuntu 20.04 (focal). Components: main (officially supported), restricted (proprietary drivers), universe (community maintained), multiverse (restricted by copyright). Add PPA (Personal Package Archive): add-apt-repository ppa:user/repo adds third-party repository. RHEL/CentOS repository configuration in /etc/yum.repos.d/*.repo. Format: [repo-id] name=Repository Name, baseurl=http://repo.url, enabled=1, gpgcheck=1, gpgkey=http://repo.url/RPM-GPG-KEY. Add EPEL (Extra Packages for Enterprise Linux): yum install epel-release adds additional packages not in official repos. Import GPG keys: rpm --import keyfile verifies package authenticity. Dependency management: apt/yum automatically resolve dependencies installing required packages. Check dependencies: apt-cache depends package or yum deplist package. Reverse dependencies: apt-cache rdepends package shows packages depending on this one. Broken dependencies: apt --fix-broken install or yum check resolves issues. Hold packages from upgrade: apt-mark hold package or yum versionlock add package. Package conflicts occur when packages provide same files or have incompatible dependencies. Resolve by: identifying conflicting packages (dpkg -S filename shows which package owns file), removing one conflicting package, using alternatives system (update-alternatives --config program selects default), or building from source if packaged versions conflict. Force installation with dpkg --force-overwrite or rpm --force (use cautiously - can break system). Best practices: keep systems updated (security patches), enable automatic security updates, test updates on non-production first, use stable repositories for production (avoid testing/unstable), document custom repositories and packages, backup before major upgrades, monitor package changelogs for breaking changes, and clean package cache periodically (apt clean, yum clean all). Understanding package management prevents dependency hell and maintains stable systems.

207. Compare different methods for transferring files between Linux systems: scp, rsync, and sftp. When should you use each?

Difficulty: MediumType: SubjectiveTopic: File Transfer

SCP (Secure Copy) uses SSH protocol for encrypted file transfers. Basic usage: scp source user@host:destination copies to remote, scp user@host:source destination copies from remote. Copy directories: scp -r directory/ user@host:path. Preserve timestamps and permissions: scp -p. Simple and secure but copies entire files even if destination has similar file - no delta transfer optimization. Rsync is more efficient, only transferring changed portions of files (delta transfer). Basic usage: rsync -avz source/ user@host:destination. Flags: -a (archive mode preserving permissions, timestamps, symlinks), -v (verbose), -z (compression), -P (progress and partial transfers). Rsync over SSH: rsync -avz -e ssh. Exclude files: rsync --exclude='*.tmp'. Dry run: rsync -n tests without changes. Rsync advantages: resume interrupted transfers, only transfer changed data (efficient for large files or slow connections), delete files in destination not in source (--delete), bandwidth limiting (--bw-limit), preserve hard links, ACLs, and extended attributes. Use rsync for backups, syncing large directories, or when source and destination have similar content. Rsync is ideal for incremental backups and mirroring. SFTP (SSH File Transfer Protocol) provides interactive file transfer over SSH with commands similar to FTP. Connect: sftp user@host. Commands: ls (remote list), lls (local list), cd (remote change dir), lcd (local change dir), put file (upload), get file (download), mkdir, rm. Batch mode: sftp -b batchfile user@host processes commands from file. Good for interactive transfers or when GUI-like interface needed. Choose SCP for simple one-time transfers of small files, rsync for efficient transfers of large directories or when files might change (backups, syncing), and SFTP for interactive browsing and transferring. All use SSH for security. For very large files, consider rsync with compression (--compress-level=9) and progress monitoring. Understanding these tools enables efficient secure file transfers in DevOps workflows.

208. Explain systemd service management including creating custom service units, service dependencies, and troubleshooting service failures.

Difficulty: HardType: SubjectiveTopic: Service Management

Systemd service units defined in /etc/systemd/system/ (custom) or /lib/systemd/system/ (packaged). Unit file format has [Unit], [Service], and [Install] sections. Example: [Unit] Description=My Service, After=network.target ensures service starts after network. [Service] Type=simple, User=appuser, ExecStart=/path/to/binary, Restart=on-failure. [Install] WantedBy=multi-user.target enables with systemctl enable. Service types: simple (default, main process specified by ExecStart), forking (service forks background process), oneshot (process expected to exit, good for scripts), notify (service sends notification when ready), idle (delays execution until other jobs finish). Choose type based on application behavior. ExecStartPre and ExecStartPost run commands before/after main process. Dependencies and ordering: Wants= suggests dependencies (service starts even if dependency fails), Requires= enforces dependencies (service fails if dependency fails), After=/Before= controls ordering without enforcing dependencies. Example: After=postgresql.service Requires=postgresql.service ensures database starts first and is required. Conflicts= prevents services from running simultaneously. Troubleshooting: systemctl status service shows current state and recent logs. Journalctl -u service shows full logs, journalctl -u service -f follows logs live, journalctl -u service --since "1 hour ago" filters by time. Check service file syntax: systemd-analyze verify service.service. View dependencies: systemctl list-dependencies service. Test configuration: systemctl daemon-reload reloads after editing units. Common issues: service fails immediately (check ExecStart path and permissions), service times out starting (increase TimeoutStartSec or fix slow startup), service restarts repeatedly (check Restart= setting and logs for crash cause), service doesn't start at boot (check WantedBy= and systemctl enable status), environment variables not set (use Environment= or EnvironmentFile=). Create minimal test service to isolate issues. Understanding systemd is crucial for managing services in modern Linux environments.

209. Explain advanced network diagnostic tools including traceroute, mtr, tcpdump, and netcat. Provide use cases for each.

Difficulty: HardType: SubjectiveTopic: Network Diagnostics

Traceroute maps the network path to a destination showing each hop (router) along the way. Basic usage: traceroute hostname. Output shows hop number, hostname/IP, and three round-trip times. High latency at specific hop indicates bottleneck. Asterisks (*) indicate no response (router filtering ICMP). Use traceroute to identify where network delays or failures occur, troubleshoot routing issues, or understand network topology. MTR (My Traceroute) combines ping and traceroute functionality, continuously monitoring network path and providing statistics. Usage: mtr hostname displays real-time updating view. Shows loss percentage, sent/received packet counts, and latency statistics (best, average, worst, standard deviation) for each hop. More useful than traceroute for identifying intermittent issues or patterns. Use mtr to diagnose packet loss locations, identify unstable network paths, or monitor connection quality over time. Tcpdump captures and analyzes network packets at low level. Basic usage: tcpdump -i interface captures on specific interface, tcpdump port 80 captures HTTP traffic, tcpdump host 1.2.3.4 captures traffic to/from specific host, tcpdump -w file.pcap saves to file for later analysis. Filters: tcpdump 'tcp and port 443' captures HTTPS. Advanced: tcpdump -A shows packet contents in ASCII. Use tcpdump to debug protocol-level issues, verify firewall rules, analyze network problems, or capture traffic for security analysis. Netcat (nc) is networking Swiss Army knife for reading/writing network connections. Uses: nc -l -p port listens on port (server mode), nc host port connects to host:port (client mode). Test port connectivity: nc -zv host port scans port. Transfer files: nc -l -p 1234 > file (receiver), nc host 1234 < file (sender). Debug services by manually sending protocol commands: nc smtp_server 25 to interact with mail server. Create simple TCP/UDP clients and servers for testing. Combining tools: use ping for basic connectivity, traceroute to identify path issues, mtr for ongoing monitoring and statistics, tcpdump for detailed protocol analysis, and netcat for testing specific ports or protocols. Each tool provides different perspective on network behavior. Understanding these tools enables diagnosing complex network issues efficiently.

210. How do you ensure package security in Linux? Discuss package verification, security updates, and vulnerability scanning.

Difficulty: MediumType: SubjectiveTopic: Package Management

Package verification uses GPG signatures to ensure packages haven't been tampered with and come from trusted sources. APT checks signatures automatically if repository provides Release.gpg file. Import repository keys: apt-key add keyfile (legacy) or place in /etc/apt/trusted.gpg.d/. For YUM/DNF, gpgcheck=1 in repo configuration enables verification, keys imported with rpm --import. Verify individual packages: rpm -K package.rpm checks signature. Security updates are critical for patching vulnerabilities. Enable automatic security updates: install unattended-upgrades on Debian/Ubuntu, configure /etc/apt/apt.conf.d/50unattended-upgrades to only install security updates. For RHEL/CentOS, yum-cron or dnf-automatic handle automatic updates. Configure notification on updates. Test updates in staging before production, but don't delay security patches excessively. Monitor security advisories: subscribe to distribution security mailing lists (ubuntu-security-announce, centos-announce), check vendor security pages, or use automated tools. Apt-get changelog package shows recent changes including security fixes. Yum updateinfo list security shows available security updates. USN (Ubuntu Security Notices) and RHSA (Red Hat Security Advisories) provide detailed vulnerability information. Vulnerability scanning: use tools like Lynis (system auditing), OpenSCAP (security compliance), or commercial scanners like Nessus. Check installed packages for known vulnerabilities: apt-cache policy shows installed versions, compare against CVE databases. Debian Security Tracker and Red Hat CVE database track vulnerabilities. Debsecan on Debian identifies packages with security issues. Best practices: minimize installed packages (smaller attack surface), keep systems updated (automate security patches), verify package sources (only use trusted repositories), audit installed packages regularly (remove unused), use configuration management to maintain consistent secure state, monitor security advisories proactively, and scan for vulnerabilities periodically. Consider container security scanning for containerized applications. Understanding package security prevents compromised packages from affecting systems.

219. Explain the basic structure of a well-written shell script including shebang, comments, error handling, and style conventions.

Difficulty: MediumType: SubjectiveTopic: Shell Scripting

Start with proper shebang: #!/bin/bash or #!/bin/sh depending on required features. Add script description comments at top explaining purpose, usage, author, and date. Example: ```bash #!/bin/bash # Script: backup.sh # Purpose: Backup specified directory # Usage: ./backup.sh <source_dir> <dest_dir> # Author: John Doe # Date: 2024-01-15 ``` Enable strict mode for safer scripts: set -e (exit on error), set -u (exit on undefined variable), set -o pipefail (pipeline returns failure if any command fails). Together: set -euo pipefail catches more errors. Add IFS=$'\n\t' to prevent word splitting issues. Use 'set -x' for debugging (prints each command before execution). Structure script logically: parse arguments and validate input first, define functions for reusable code, main script logic, cleanup on exit using trap. Example: ```bash trap cleanup EXIT function cleanup() { rm -f "$TEMP_FILE"; } function usage() { echo "Usage: $0 <arg>"; exit 1; } [ $# -eq 0 ] && usage main_logic_here ``` Style conventions: use meaningful variable names in UPPER_CASE for constants, lower_case for local variables, use functions for repeated code, comment complex logic, validate inputs before use, check exit status of important commands, provide helpful error messages with context, and use constants for file paths and configuration. Indent consistently (2 or 4 spaces), use snake_case for function names, and quote variables consistently. Error handling: check critical command results: if ! command; then echo "Error: command failed"; exit 1; fi. Validate file existence: [ -f "$FILE" ] || { echo "File not found"; exit 1; }. Provide usage help: if [ $# -ne 2 ]; then echo "Usage: $0 arg1 arg2"; exit 1; fi. Log errors to stderr: echo "Error" >&2. Understanding these practices creates maintainable, reliable scripts.

220. Explain variable scope in bash including local vs global variables, environment variables, and readonly variables.

Difficulty: HardType: SubjectiveTopic: Shell Variables

Global variables by default: any variable assigned at top level is accessible throughout script and sub-functions. Example: VAR=value at script level is global. Changes in functions affect global scope unless declared local. This can cause unintended side effects if functions modify global variables. Local variables declared with 'local' keyword inside functions are only accessible within that function, preventing pollution of global namespace. Example: ```bash function test() { local LOCAL_VAR="function scope" GLOBAL_VAR="modified globally" } ``` LOCAL_VAR isn't accessible outside function, GLOBAL_VAR modifies global variable or creates it if didn't exist. Environment variables exported with 'export' are passed to child processes (subshells, executed commands). Example: export PATH=$PATH:/new/path makes PATH available to all subsequent commands. Declare and export together: export VAR=value. Child processes inherit exported variables but changes in child don't affect parent. Check environment: env shows all exported variables, printenv VARNAME shows specific variable. Readonly variables can't be modified after creation: readonly CONST=value or declare -r CONST=value. Attempting modification causes error. Use for constants like configuration values that shouldn't change. Unset doesn't work on readonly variables. Readonly -p lists all readonly variables. Special variables: $HOME (home directory), $USER (username), $PWD (current directory), $OLDPWD (previous directory), $PATH (executable search path), $SHELL (default shell), $$ (current process PID), $! (last background process PID). These are typically environment variables set by shell or system. Best practices: use local for function variables preventing side effects, export only variables needed by child processes, use readonly for true constants, prefix global variables with descriptive names avoiding conflicts, and document variable scope in complex scripts. Understanding scope prevents hard-to-debug issues from variable conflicts.

226. What techniques and tools can you use to debug shell scripts? Explain various debugging approaches.

Difficulty: HardType: SubjectiveTopic: Script Debugging

Set -x enables debug mode printing each command before execution with expanded variables: set -x at script start or bash -x script.sh runs entire script in debug. Disable with set +x. Output prefixed with +. Helps trace execution flow and see actual values. Use PS4 variable to customize prefix: export PS4='+(${BASH_SOURCE}:${LINENO}): ${FUNCNAME[0]:+${FUNCNAME[0]}(): }' shows file, line, and function. Set -v (verbose) prints script lines as read before execution, showing raw commands. Combine: set -xv shows both raw and expanded. Set -e exits on first error, set -u exits on undefined variables, set -o pipefail fails on pipeline errors. Together: set -euxo pipefail creates strict mode catching most errors. Strategic echo statements: add echo "Reached checkpoint 1" at key points, echo "VAR=$VAR" shows variable values, echo "$(date): processing $FILE" adds timestamps. Redirect debug output to file: exec 5> debug.log; BASH_XTRACEFD=5; set -x sends trace to file descriptor 5 instead of stderr. Validation and testing: check exit status: command; echo $? shows return code, test command availability: command -v cmd tests if command exists, validate variables: [ -z "$VAR" ] && { echo "Error: VAR empty"; exit 1; }, verify file operations: [ -f "$FILE" ] || { echo "File not found"; exit 1; }. Shellcheck is lint tool for shell scripts finding bugs, deprecated syntax, and suggesting improvements: shellcheck script.sh. Install and run on all scripts. Explains errors with wiki links. Bash -n script.sh checks syntax without executing. Interactive debugging: trap 'read -p "Paused at line $LINENO. Press enter to continue..."' DEBUG pauses at each line. Function for debugging: debug() { [ "$DEBUG" ] && echo "DEBUG: $*" >&2; }; DEBUG=1 for debug mode. Use logging functions categorizing messages by severity. Understanding debugging techniques quickly identifies and fixes script issues.

237. Explain advanced function concepts including return values, variable scope, function libraries, and recursive functions.

Difficulty: HardType: SubjectiveTopic: Shell Functions

Return values: functions return exit status (0-255) via return N, not actual values. Get output with command substitution: RESULT=$(function_name). Echo values in function: function get_value() { echo "result"; }, VALUE=$(get_value). Multiple return values: echo space-separated values, split with read: read var1 var2 <<< "$(function)". Variable scope: variables are global by default, visible everywhere. Local variables with local keyword exist only in function: ```bash function test() { local LOCAL_VAR="function scope" GLOBAL_VAR="modified globally" } test echo $GLOBAL_VAR # Visible echo $LOCAL_VAR # Empty ``` Use local for all function variables preventing side effects. Export doesn't affect function scope (only child processes). Function libraries: source or . loads functions from external files. Create library file: ```bash # lib/common.sh log() { echo "[$(date)] $*"; } error() { echo "ERROR: $*" >&2; exit 1; } ``` Source in scripts: source lib/common.sh or . lib/common.sh. Check file exists: [ -f lib/common.sh ] && source lib/common.sh || { echo "Library not found"; exit 1; }. Organize related functions into libraries for reuse across scripts. Recursive functions: function calls itself. Example factorial: ```bash factorial() { local n=$1 if ((n <= 1)); then echo 1 else echo $((n * $(factorial $((n-1))))) fi } ``` Need base case to prevent infinite recursion. Use for tree traversal, directory processing, or algorithms naturally recursive. Bash has limited stack depth (~1000 levels). For deep recursion, consider iteration or external programs. Best practices: one function, one purpose; meaningful names; document parameters and return values; handle errors; validate inputs; use local variables; return early on errors; keep functions short (<50 lines). Understanding advanced function usage enables writing modular, maintainable, professional scripts.

240. Explain advanced parameter expansion techniques in bash including default values, pattern substitution, substring extraction, and case modification.

Difficulty: HardType: SubjectiveTopic: Shell Parameters

Default values: ${VAR:-default} returns default if VAR unset or empty (doesn't modify VAR), ${VAR:=default} assigns default if unset/empty (modifies VAR), ${VAR:+alternate} returns alternate if VAR set (opposite of :-), ${VAR:?error} exits with error message if unset/empty. Examples: ```bash FILE=${1:-input.txt} # Use $1 or default PORT=${PORT:=8080} # Set PORT to 8080 if not set : ${DIR:=/tmp} # Idiom for setting defaults ``` String length and substrings: ${#VAR} returns length, ${VAR:offset} extracts from offset to end, ${VAR:offset:length} extracts length characters from offset, ${VAR: -5} extracts last 5 characters (note space before minus). Example: FILE="path/to/file.txt"; NAME="${FILE##*/}"; EXT="${FILE##*.}". Pattern removal: ${VAR#pattern} removes shortest match from beginning, ${VAR##pattern} removes longest match from beginning, ${VAR%pattern} removes shortest match from end, ${VAR%%pattern} removes longest match from end. Examples: ```bash FILE="/path/to/file.tar.gz" DIR=${FILE%/*} # /path/to (remove filename) NAME=${FILE##*/} # file.tar.gz (basename) BASE=${FILE%%.*} # /path/to/file (remove all extensions) EXT=${FILE##*.} # gz (last extension) ``` Pattern substitution: ${VAR/pattern/replacement} replaces first match, ${VAR//pattern/replacement} replaces all matches, ${VAR/#pattern/replacement} replaces at beginning only, ${VAR/%pattern/replacement} replaces at end only. Examples: ```bash PATH="/usr/local/bin:/usr/bin" NEW_PATH=${PATH//bin/sbin} # Replace all 'bin' with 'sbin' STR="Hello World" LOWER=${STR,,} # Convert to lowercase (bash 4+) UPPER=${STR^^} # Convert to uppercase CAPITAL=${STR^} # Capitalize first char ``` Case modification (bash 4+): ${VAR^} uppercases first character, ${VAR^^} uppercases all, ${VAR,} lowercases first, ${VAR,,} lowercases all, ${VAR~} toggles case of first, ${VAR~~} toggles all. Indirection: ${!VAR} expands to value of variable named in VAR. Example: KEY="PATH"; echo ${!KEY} prints PATH's value. Indirect array: keys="!ARRAY[@]"; for key in ${!keys}; do echo $key; done. Understanding parameter expansion eliminates need for external commands like basename, dirname, cut, sed for many string operations, making scripts faster and more portable.

241. Explain process substitution in bash. How does it differ from command substitution and when should you use it?

Difficulty: HardType: SubjectiveTopic: Command Substitution

Process substitution treats command output as file using <(command) for reading or >(command) for writing. Bash creates temporary FIFO (named pipe) or /dev/fd/ file descriptor connected to command output/input. Syntax: <(command) creates readable file, >(command) creates writable file. Use when commands expect files but you have command output. Examples: ```bash # Compare outputs of two commands diff <(ls dir1) <(ls dir2) # Sort and compare without temp files comm <(sort file1) <(sort file2) # Feed command output to multiple commands tee >(process1) >(process2) < input # Read from multiple sources while read line; do echo "$line"; done < <(cat file1 file2) ``` Difference from command substitution $(): command substitution captures output as string for variable assignment or inline use: VAR=$(command) or echo "Result: $(command)". Process substitution creates file-like interface for commands expecting file arguments. Command substitution stores all output in memory, process substitution streams data through pipe. Use cases: commands requiring file arguments (diff, comm, paste, join), avoiding temporary files, parallel processing (multiple outputs with tee), reading output preserving while loop variables (avoiding subshell issue). Example: ```bash # This works (process substitution avoids subshell) while read line; do COUNT=$((COUNT+1)) done < <(cat file) echo "Lines: $COUNT" # COUNT visible # This doesn't (pipe creates subshell) cat file | while read line; do COUNT=$((COUNT+1)) done echo "Lines: $COUNT" # COUNT not visible ``` Limitations: not POSIX portable (bash, zsh, ksh only), may not work with commands checking file type, order of execution may differ from expectation. Understanding process substitution enables advanced I/O manipulation without temporary files, cleaner code, and solves subshell variable visibility issues.

242. What are best practices for organizing large shell scripts? Discuss structure, modularity, and maintainability.

Difficulty: MediumType: SubjectiveTopic: Shell Scripting

Structure template: ```bash #!/bin/bash # Script header: description, usage, author, version set -euo pipefail # Strict mode # Constants (UPPERCASE) readonly SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" readonly SCRIPT_NAME="$(basename "$0")" readonly CONFIG_FILE="${SCRIPT_DIR}/config.conf" # Default variables (lowercase) verbose=0 log_file="/var/log/${SCRIPT_NAME}.log" # Functions usage() { ... } log() { ... } error() { ... } validate_input() { ... } main() { ... } # Parse arguments while getopts "vhf:" opt; do ...; done # Main execution main "$@" ``` Modularity: break into logical functions (single responsibility), source common functions from libraries, separate configuration from code, use function names describing action. Group related functions: all validation functions together, all logging functions together, main logic functions. Library organization: ``` project/ ├── bin/ │ └── main_script.sh ├── lib/ │ ├── common.sh # Shared utilities │ ├── logging.sh # Logging functions │ └── validation.sh # Input validation ├── conf/ │ └── config.conf └── README.md ``` Source libraries: source "${SCRIPT_DIR}/../lib/common.sh". Check if sourced: [[ -n ${COMMON_LIB:-} ]] && return prevents double-sourcing. Configuration management: external config files for environment-specific values, validate config on load, provide defaults, document required variables. Example config.conf: ```bash # Database config DB_HOST="localhost" DB_PORT=5432 DB_NAME="mydb" ``` Load: [ -f "$CONFIG_FILE" ] && source "$CONFIG_FILE" || error "Config not found". Documentation: header comments explaining purpose and usage, function comments describing parameters and return values, inline comments for complex logic only, usage function showing examples, README for multi-script projects. Version control: use git, tag releases, maintain changelog. Error handling: validate all inputs, check command exit status for critical operations, provide meaningful error messages with context, log errors to file and stderr, clean up on exit (trap), fail fast with set -e. Testing: unit tests for functions, integration tests for workflows, test error cases, automate testing. Understanding organization principles makes scripts maintainable, enables collaboration, simplifies debugging, and allows reuse across projects.

251. Explain how to analyze system logs for troubleshooting. What are common log files and what do they contain?

Difficulty: HardType: SubjectiveTopic: Journalctl Logs

Key log files: /var/log/syslog or /var/log/messages (general system messages from kernel, system daemons, applications), /var/log/auth.log or /var/log/secure (authentication, sudo, SSH login attempts), /var/log/kern.log (kernel messages, hardware issues, driver problems), /var/log/dmesg (boot messages, hardware detection), /var/log/boot.log (service startup during boot). Application logs: /var/log/apache2/ or /var/log/httpd/ (web server access and error logs), /var/log/mysql/ (database logs), /var/log/nginx/ (nginx logs), /var/log/mail.log (mail server), application-specific directories. Check application documentation for log locations. Systemd journal: journalctl queries systemd journal (binary format, queryable). Commands: journalctl -xe (recent entries with explanations), journalctl -u service (service-specific), journalctl --since "1 hour ago" (time-based), journalctl -f (follow), journalctl -b (current boot), journalctl -k (kernel messages), journalctl -p err (priority filter). Log analysis techniques: tail -f /var/log/syslog monitors in real-time, grep 'ERROR' /var/log/syslog finds errors, awk, sed for parsing structured logs, sort | uniq -c for frequency analysis. Example: grep 'Failed password' /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn lists failed login attempts by IP. Common patterns: "Out of memory" indicates memory exhaustion, "Connection refused" suggests service not running or firewall blocking, "Permission denied" indicates file permission issues, "No space left on device" means disk full, "segmentation fault" indicates application crash. Correlate timestamps across logs to understand event sequences. Log rotation: logrotate prevents logs from filling disk. Configuration in /etc/logrotate.conf and /etc/logrotate.d/. Settings: rotation frequency (daily, weekly), number of old logs to keep, compression, post-rotation scripts. Check logrotate status in /var/lib/logrotate/status. Centralized logging: for multiple servers, use centralized logging (ELK stack, Splunk, Graylog) shipping logs to central server for analysis, correlation, and alerting. Understanding log analysis is fundamental for troubleshooting production issues.

252. Explain advanced cron usage including environment variables, output handling, error reporting, and alternatives like systemd timers.

Difficulty: HardType: SubjectiveTopic: Cron Jobs

Cron environment: limited PATH, HOME=/home/user, SHELL=/bin/sh by default. Set variables in crontab: PATH=/usr/local/bin:/usr/bin:/bin, MAILTO=admin@example.com, SHELL=/bin/bash. Variables before entries apply to all subsequent entries. Example: ``` PATH=/usr/local/bin:/bin:/usr/bin MAILTO=admin@example.com 0 2 * * * /path/to/backup.sh ``` Output handling: cron emails stdout/stderr to MAILTO user (if mail configured). Redirect: 0 2 * * * /path/to/script.sh > /var/log/backup.log 2>&1 logs output. Suppress: 0 2 * * * /path/to/script.sh > /dev/null 2>&1 discards all output. Email only errors: 0 2 * * * /path/to/script.sh > /var/log/backup.log sends only stderr via email. Error reporting: wrap scripts with error handling: ```bash #!/bin/bash set -e trap 'echo "Backup failed" | mail -s "Backup Error" admin@example.com' ERR # Backup commands ``` Or use cron wrapper: 0 2 * * * /usr/local/bin/cron-wrapper /path/to/script.sh where wrapper handles logging and error notification. Locking: prevent overlapping executions: ```bash 0 */6 * * * flock -n /var/lock/backup.lock -c '/path/to/backup.sh' ``` Flock ensures only one instance runs. Alternative: check for PID file in script. Systemd timers: modern alternative to cron. Create timer unit (/etc/systemd/system/backup.timer): ``` [Unit] Description=Backup Timer [Timer] OnCalendar=daily OnCalendar=*-*-* 02:00:00 Persistent=true [Install] WantedBy=timers.target ``` And service unit (backup.service). Enable: systemctl enable backup.timer, systemctl start backup.timer. Advantages of timers: better logging with journalctl, dependency handling, RandomizedDelaySec for load distribution, OnBootSec for run-after-boot. List: systemctl list-timers. Disadvantages: more complex setup, systemd-specific. At command: one-time scheduled tasks. at 10pm runs commands entered interactively. at 2:30 AM tomorrow < script.sh schedules script. List: atq, remove: atrm jobnumber. Understanding scheduling options enables reliable task automation.

253. How do you troubleshoot disk space and inode exhaustion issues? Explain finding large files, cleaning up space, and preventing future issues.

Difficulty: HardType: SubjectiveTopic: Disk Management

Identify disk space issues: df -h shows filesystem usage, alerts when >80-90% full. Find large files: du -sh /* | sort -h shows top-level directory sizes, du -ah /var | sort -h | tail -20 finds 20 largest files/dirs under /var. Recursive: find / -type f -size +100M lists files over 100MB, find / -type f -size +1G -exec ls -lh {} \; shows details. Common space consumers: /var/log (old logs), /tmp (temporary files), /home (user files), /var/cache/apt or /var/cache/yum (package caches), Docker images (/var/lib/docker), database dumps. Clean: logrotate for logs, apt-get clean or yum clean all for package caches, docker system prune for Docker cleanup. Inode exhaustion: df -i shows inode usage. Symptom: "No space left on device" despite df showing free space. Cause: millions of small files exhausting inodes. Find: find / -xdev -type f | cut -d / -f 2 | sort | uniq -c | sort -rn shows file count by top-level directory. Clean: remove unnecessary files, especially in /tmp, /var/spool. Safe cleanup: ```bash # Find old files find /var/log -type f -mtime +30 -name "*.log" # Archive before deleting tar -czf old-logs-$(date +%Y%m%d).tar.gz $(find /var/log -type f -mtime +30 -name "*.log") find /var/log -type f -mtime +30 -name "*.log" -delete # Truncate instead of delete (preserves file handles) > /var/log/large.log ``` Monitoring and alerts: set up monitoring (Nagios, Zabbix, Prometheus) alerting at 80% capacity. Automated cleanup: cron jobs deleting old files, log rotation, temporary file cleanup. Capacity planning: track growth trends, expand storage before reaching limits. Quota management: set user quotas preventing individuals from filling disk. Enable: quotacheck, quotaon, edquota user sets limits. Useful in multi-user systems. Prevention: proper log rotation, automated cleanup, user quotas, capacity monitoring, storage expansion planning. Understanding disk management prevents outages from full filesystems.

254. Explain Linux system performance tuning techniques. How do you identify bottlenecks and optimize CPU, memory, disk, and network performance?

Difficulty: HardType: SubjectiveTopic: System Monitoring

Identify bottlenecks: use monitoring tools determining if CPU, memory, disk I/O, or network is constraining performance. Top or htop shows CPU and memory, vmstat shows system stats, iostat shows disk I/O, sar provides historical data. High load average (>CPU cores) indicates CPU bottleneck, high swap usage indicates memory pressure, high iowait indicates disk bottleneck. CPU optimization: identify CPU-intensive processes with top, nice/renice adjust process priority, taskset pins processes to specific CPU cores (CPU affinity), disable unnecessary services reducing CPU load, upgrade to more/faster CPUs. Tune: echo performance > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor sets CPU governor to performance mode. Memory optimization: add more RAM if constantly swapping, tune swappiness: echo 10 > /proc/sys/vm/swappiness reduces swap usage (default 60), tune cache pressure: echo 50 > /proc/sys/vm/vfs_cache_pressure controls caching behavior, identify memory leaks (growing RSS in top), disable unused services, use lightweight alternatives. Disk I/O optimization: use faster storage (SSD instead of HDD), tune I/O scheduler: cat /sys/block/sda/queue/scheduler shows schedulers, echo deadline > /sys/block/sda/queue/scheduler sets deadline scheduler (good for SSDs), increase read-ahead: blockdev --setra 8192 /dev/sda, use separate disks for different workloads (logs on separate disk from database), tune filesystem mount options (noatime reduces writes), enable write caching (with UPS backup). Network optimization: tune TCP buffers: sysctl -w net.core.rmem_max=16777216, sysctl -w net.core.wmem_max=16777216 increases buffer sizes, tune TCP settings: sysctl -w net.ipv4.tcp_tw_reuse=1 allows reusing TIME_WAIT connections, use faster network interface, enable jumbo frames on gigabit networks: ifconfig eth0 mtu 9000. Filesystem tuning: choose appropriate filesystem (XFS for large files, ext4 for general use), tune mount options (noatime, nodiratime, data=writeback for performance, data=journal for consistency), adjust reserved blocks: tune2fs -m 1 /dev/sda1 reduces reserved space from 5% to 1%. Kernel tuning: parameters in /etc/sysctl.conf or /proc/sys. Examples: net.ipv4.ip_local_port_range for port range, net.core.somaxconn for connection queue, vm.dirty_ratio and vm.dirty_background_ratio for write caching. Apply: sysctl -p. Benchmarking: establish baseline before tuning, benchmark after changes, common tools: sysbench (CPU, memory, I/O), iperf (network), fio (disk I/O), stress-ng (stress testing). Document changes and results. Understanding performance tuning optimizes system resource utilization.

255. Explain comprehensive backup and disaster recovery strategies for Linux systems. Discuss backup types, automation, testing, and recovery procedures.

Difficulty: HardType: SubjectiveTopic: Backup Restore

Backup types: Full backup copies all data (complete snapshot, large, slow), Incremental backup copies changes since last backup (faster, requires all previous backups for restore), Differential backup copies changes since last full backup (faster than full, easier restore than incremental), Snapshot/delta backup copies only changed blocks (efficient, requires special tools like rsnapshot, borgbackup). Backup strategy: 3-2-1 rule - 3 copies (original + 2 backups), 2 different media types (disk + tape/cloud), 1 offsite (protection against site disasters). RPO (Recovery Point Objective) - acceptable data loss timeframe, RTO (Recovery Time Objective) - acceptable downtime for restoration. Tools and methods: ```bash # Tar backup tar -czf backup-$(date +%Y%m%d).tar.gz /data --exclude='*.tmp' # Rsync incremental backup rsync -av --delete /data/ /backup/latest/ # Rsnapshot (hard-link based, space-efficient) rsnapshot daily # Borgbackup (deduplication, compression, encryption) borg create /backup/repo::$(date +%Y%m%d) /data # Database backup mysqldump -u root -p --all-databases | gzip > db-backup-$(date +%Y%m%d).sql.gz ``` Automation: cron jobs for scheduled backups: ```bash # /etc/cron.d/backup 0 2 * * * root /usr/local/bin/backup.sh 2>&1 | logger -t backup 0 3 * * 0 root /usr/local/bin/full-backup.sh 2>&1 | logger -t backup ``` Include error handling, notifications, logging. Lock files prevent overlapping backups. What to backup: configuration files (/etc), user data (/home), application data (/var/www, /var/lib), databases, log files (for forensics), system state (package list: dpkg --get-selections > packages.txt). Testing backups: regularly test restoration process (monthly), automate test restores to separate system, document recovery procedures, verify backup integrity (checksums, test files), test offsite retrieval. Recovery procedures: ```bash # File restore from tar tar -xzf backup.tar.gz -C / path/to/file # Rsync restore rsync -av /backup/latest/ /data/ # Borg restore borg extract /backup/repo::20240115 path/to/restore # Database restore zcat db-backup.sql.gz | mysql -u root -p ``` Disaster recovery: document DR plan, maintain recovery media (bootable USB with tools), store offsite backup credentials securely, practice full system rebuild, automate infrastructure with config management (Ansible, Puppet) enabling quick rebuild, document dependencies and configurations. Encryption: encrypt backups containing sensitive data: tar -czf - /data | gpg -c > backup.tar.gz.gpg, store encryption keys separately, test decryption regularly. Retention policy: daily backups for 7 days, weekly for 4 weeks, monthly for 12 months, yearly for long-term archival. Balance storage cost vs. recovery requirements. Understanding backup strategies prevents data loss and minimizes recovery time.

256. What are essential Linux security hardening practices? Discuss SSH security, firewall configuration, SELinux/AppArmor, and security updates.

Difficulty: HardType: SubjectiveTopic: Security Hardening

SSH hardening (/etc/ssh/sshd_config): disable root login (PermitRootLogin no), use key-based authentication only (PasswordAuthentication no, PubkeyAuthentication yes), change default port (Port 2222), limit users (AllowUsers user1 user2), use Protocol 2 only, set LoginGraceTime 30, MaxAuthTries 3, disable empty passwords (PermitEmptyPasswords no), disable X11 forwarding if not needed (X11Forwarding no). Firewall configuration: enable firewall (ufw, firewalld, iptables), default deny policy, whitelist necessary ports only. UFW: ufw default deny incoming, ufw allow 22/tcp, ufw allow 80/tcp, ufw enable. Iptables: iptables -P INPUT DROP, iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT, iptables -A INPUT -p tcp --dport 22 -j ACCEPT, persist with iptables-save. Minimize attack surface: disable unused services (systemctl disable service), remove unnecessary packages (apt remove or yum remove), close unnecessary ports, run services as non-root users, use chroot jails or containers for service isolation. SELinux/AppArmor: mandatory access control systems. SELinux (RHEL/CentOS): enforce policies restricting process actions, set to enforcing mode: setenforce 1, check status: getenforce, fix context: restorecon -Rv /path, audit logs in /var/log/audit/audit.log. AppArmor (Ubuntu): profile-based confinement, enable profile: aa-enforce /etc/apparmor.d/usr.bin.program, check status: aa-status. Security updates: enable automatic security updates (unattended-upgrades on Debian/Ubuntu, yum-cron on RHEL/CentOS), configure notification, test in staging before production, subscribe to security mailing lists (ubuntu-security-announce, centos-announce), monitor CVEs for installed software. Password policies: enforce strong passwords with PAM (pam_pwquality), set password expiration (chage -M 90 user), lock accounts after failed attempts (pam_faillock), audit passwords with john the ripper (authorized testing). File permissions: review world-writable files: find / -xdev -type f -perm -002, review setuid files: find / -xdev -type f -perm -4000 (potential security risks), protect sensitive files (600 for SSH keys, 640 for config files), audit with aide or tripwire detecting unauthorized changes. Audit logging: enable auditd for system call auditing, log important events (file access, authentication, privilege escalation), central log collection, regular log review, configure retention policy. Network security: disable IPv6 if not used, disable unnecessary network services, use TCP wrappers (/etc/hosts.allow, /etc/hosts.deny), configure reverse DNS, enable fail2ban for intrusion prevention (bans IPs with multiple failed logins). Monitoring: install intrusion detection (OSSEC, Snort), monitor logs for suspicious activity, set up alerts for critical events, regular security scans (nmap for open ports, nikto for web vulnerabilities - authorized testing only), vulnerability scanning (OpenVAS, Nessus). Understanding security hardening protects systems from attacks and ensures compliance with security standards.

257. Describe common Linux system issues and their troubleshooting approaches. Include boot failures, network problems, performance degradation, and service failures.

Difficulty: HardType: SubjectiveTopic: Service Management

Boot failures: symptoms - system won't start, kernel panic, drops to emergency shell. Troubleshooting: boot from live USB, check logs in /var/log, run fsck on filesystems, check /etc/fstab for errors (typos, wrong UUIDs), reinstall bootloader (grub-install), boot older kernel from GRUB menu, check hardware (bad RAM, failing disk with SMART data: smartctl -a /dev/sda). Network problems: symptoms - no connectivity, slow network, DNS issues. Troubleshooting: ping 127.0.0.1 (test loopback), ping gateway (test local network), ping 8.8.8.8 (test internet without DNS), nslookup google.com (test DNS), check interface status: ip link, check IP configuration: ip addr, check routes: ip route, check DNS: cat /etc/resolv.conf, restart network: systemctl restart networking, check firewall rules, test with different DNS: nslookup google.com 8.8.8.8. Performance degradation: symptoms - slow response, high load average, OOM killer activating. Troubleshooting: top/htop identify resource hogs, check CPU (>80% sustained), memory (high swap usage), disk I/O (high iowait in top), check for memory leaks (growing RSS), review logs for errors, analyze with sar historical data, investigate recent changes (new software, config changes, increased load), iostat for disk bottlenecks, netstat for network connections. Service failures: symptoms - service won't start, keeps restarting, crashes. Troubleshooting: systemctl status service shows state and recent logs, journalctl -xu service shows detailed logs, check config files for syntax errors, verify file permissions, check dependencies: systemctl list-dependencies service, test manually: /usr/bin/service --verbose, review recent changes, check available resources (disk space, memory), strace for system call tracing. Disk full issues: symptoms - "No space left" errors, applications crashing, can't write logs. Troubleshooting: df -h shows usage by filesystem, find large files: du -sh /* | sort -h, check inodes: df -i, clean /tmp and /var/tmp, rotate logs, clean package caches, find deleted but open files: lsof | grep deleted (restart services to release), expand filesystem or add storage. High CPU usage: identify process with top, check if legitimate load or bug (runaway loop), nice/renice to lower priority, kill if necessary, investigate application logs, check for infinite loops or inefficient queries, profile with strace or perf. Memory issues: check with free -h, identify memory hogs with top (RSS column), check for leaks (memory growing over time), adjust swappiness if swapping too aggressively, add more RAM if consistently over capacity, check OOM killer logs: dmesg | grep -i kill. Systematic approach: define problem clearly, collect information (logs, monitoring data, recent changes), form hypothesis, test hypothesis, implement fix, verify resolution, document solution. Understanding common issues and systematic troubleshooting reduces mean time to resolution.

Linux & Shell Scripting Interview Questions & Answers | Preplance | Preplance

Master Interviews Anywhere, Anytime

All Linux & Shell Scripting Interview Questions

Overview

1. Which command lists all files including hidden ones in Linux?

2. Which command prints the current working directory path?

Continue your preparation

3. Which command moves you one directory up in Linux?

4. Which command combination creates and removes directories?

5. Which command moves files in Linux?

6. Which command displays file content one screen at a time?

7. Which option with rm is required to delete directories recursively?

8. Which command finds files by name in the current directory and subdirectories?

9. What does the grep command do?

10. Explain the Linux directory structure and its top-level folders.

11. What is the difference between absolute and relative paths?

12. Differentiate between piping (|) and redirection (>).

13. What are wildcards in Linux and how are they used?

14. How do you view command history and create command aliases?

15. Which command changes file permissions in Linux?

16. Which command changes the ownership of a file in Linux?

17. In the permission string -rwxr-xr--, what does the second group (r-x) represent?

18. Which command creates a new user account?

19. Which command is used to change a user's password?

20. Which command displays currently running processes?

21. Which signal is sent by default when you run the kill command without specifying one?

22. What does the top command display?

23. Which command adjusts the scheduling priority of a process?

24. Explain the three types of file permissions in Linux.

25. Differentiate between sudo and su commands.

26. Describe the lifecycle of a Linux process.

27. How can you run a command in the background and bring it back to the foreground?

28. How do you add a user to a specific group in Linux?

29. What is the purpose of the first line '#!/bin/bash' in a shell script?

30. Which is the correct way to define a variable in Bash?

31. Which command reads user input into a variable?

32. What is the correct syntax for an if statement in Bash?

33. Which syntax correctly defines a for loop in Bash?

34. Which of the following executes until a condition becomes false?

35. Which keyword ends a case statement in Bash?

36. Which variable stores the exit status of the last executed command?

37. Which keyword defines a function in a shell script?

38. How is arithmetic performed in shell scripting?

39. How do you check if a string is empty or not in Bash?

40. Explain two ways to execute a shell script.

41. Give an example of a real use case for loops in automation.

42. Describe a practical scenario where if-else is used in a deployment script.

43. Which command is used to schedule tasks to run automatically at specific intervals?

44. Which command lists all cron jobs for the current user?

45. Which command runs a one-time task at a specific time in Linux?

46. What is the difference between '&&' and ';' when chaining commands?

47. Which symbol runs a command in the background?

48. What does '>>' do in shell redirection?

49. Which command combination finds and counts lines matching 'error' in a log file?

50. Which utility manages automatic log rotation and compression?

51. How can you pass and access command-line arguments in a shell script?

52. How do you handle errors gracefully in automation scripts?

53. Explain the five fields in a crontab schedule expression.

54. How do you log output from a shell script for future reference?

55. Describe how you would automate a daily file backup using cron.

56. Give a real-world example of using pipes for automation.

57. Which command shows how long the system has been running and the average load?

58. Which command displays disk usage information for mounted filesystems?

59. What does the 'du' command report?

60. Which command displays memory and swap usage in Linux?

61. Which command lists active network connections and ports?

62. What does the 'ping' command test?

63. Which command displays the path packets take to reach a destination host?

64. Which option of the 'tail' command follows log updates in real time?

65. Which command displays logs from the systemd journal?

66. How do you identify which process is consuming the most CPU and memory?

67. Describe the steps to troubleshoot network connectivity in Linux.

68. How do you identify which directories are using the most disk space?

69. Explain how to analyze application logs for errors or warnings.

70. How can you find which process is listening on a specific port?

71. Which command installs a package using the APT package manager?

72. Which command installs packages on Red Hat or CentOS systems?

73. What does the dpkg command do in Debian-based systems?

74. Which command starts a service using systemd?

75. Which command ensures a service starts automatically on boot?

76. Which systemctl command checks the current status of a service?

Master Interviews
Anywhere, Anytime