📱

Get Our Mobile App

Take your business learning on the go!

Download on the App StoreGet it on Google Play

Mastering Linux Interviews: Top 15 Scenario-Based Questions & Answers | Linux Scenario Interview

DGR Uploads17:29

Transcription

Hello everyone and welcome back to my channel. In today's session, we will look at 15 scenario-based Linux interview questions along with their answers. Now, these scenarios are designed to mainly test your real-world problem-solving skills and also give you a a deeper understanding of the Linux system administration.

Once again, before I start off with the session, please don't forget to hit that subscribe button. So, let's let's get started with this. The first question I have is, uh, you need to find out why a server is running slowly and what steps would you take? So, for this, we can start off by checking the overall load on the system. So, for this, we can make use of the, uh, top command or the htop command, which will, uh, basically look at the usage of your CPU and also memory and then identify any processes which are consuming excessive resources. So, when we run this htop or the top command, this will give us the CPU utilization and the memory utilization for, uh, the respective processes, and we can look at that to see which process is consuming, uh, more resources. U, we can also make use of your iostat command and the iotop command to check the disk input, uh, uh, output. We can make use of the free -m command to check the memory usage, uh, df -h command to check for, uh, disk space utilization. We can also check for any network issues by making use of the netstat command or the ss command. Then, finally, we can review the system logs which are available in the /var/log path for any errors or any warnings. So, that's basically how we can, uh, troubleshoot the slowness of the system. So, we have lots of options, lots of commands that are available which can be used to get an understanding of why the system is slow.

The next question we have is, a user's home directory is filling up with disk space on the root partition. How would you resolve this? So, for this, we'll need to first check the disk usage of the user. So, for this, we can make use of the command which is du -sh and then the path of the user directory. And this command will help us to identify the large files or directories that are available within the, uh, path. If possible, we can move these large files or the directories to another partition which has more space by making use of the mv command or the rsync command. Other option that we can look at is advising the user to delete the files that are no longer needed or, uh, compress the unnecessary files so that, you know, the space can be released on the user's home directory. So, basically, uh, looking at options that can, uh, reduce the space, uh, either delete the files that are no longer needed or compress them or move them to another partition if the files are needed.

The next question we have is, you need to secure a web server against common vulnerabilities. What measures would you take? So, for this, we'll have to ensure that all the software is up to date by making use of the respective package manager. So, if you're on Ubuntu, then we can use apt. If you're on Red Hat/CentOS, then we can use yum. So, by using this command, we can make sure that the packages are always up to date. Uh, we can also configure a firewall by making use of iptables or firewalld, disable any unnecessary services and remove the default files. Also, implement HTTPS by making use of your SSL or TLS certificate. So, we can make use of Let's Encrypt or another CA to get the certificates and implement HTTPS. Uh, we have also tools like Fail2ban, which can be used to block any malicious IP addresses and also configure SELinux or AppArmor for enhanced security. So, that's basically how we can secure our, uh, web server from vulnerabilities. So, we have options, we can put in firewalls, we can block IP addresses, we can make use of enhanced security to, uh, basically protect the web server.

The next question we have is, the SSH service on your server is being targeted by brute force attacks. What steps would you take to mitigate this? So, for this, uh, one option we have is to change the default SSH port, which is your 22. So, change SSH port from 22 to something less commonly used, and we can change that in the /etc/ssh/sshd_config file. So, in that file, you can go ahead and, uh, change the default port number for your SSH. Uh, implement key-based authentication and disable password authentication. So, users will no longer be able to use any password authentication; they will need to have the key pair to authenticate to the server. Use Fail2ban to block any malicious IP addresses after a certain number of failed logins. So, if the user is trying to log into the server and after a certain number of failed attempts, the, the IP address should be blocked. No one should be, the user should not be able to log in from that IP address. And only allow specific IP addresses to connect to the server. Uh, and we can configure that by making use of your iptables or UFW. So, that will allow only specific IPs to connect to the server. So, that way, we can, uh, prevent, uh, uh, brute force attacks on the server.

The next question we have is, you need to automate backups of a directory to a remote server. How would you do it? So, for this, we can make use of rsync for very efficient, uh, file transfer, and then we can also set up SSH-based authentication between the local machine and the remote machine. So, basically, from your source to your destination machine, we can, uh, set up SSH authentication, uh, between them. Uh, then we will write a script that will run the rsync command with your desired options, and then schedule that script to run by using a cron job. Uh, that is, you know, you can use the crontab -e to set up your cron job that will run the script on a schedule, whatever you have defined, and it will start, uh, taking a backup of your data and pushing it, push it to the remote server, whatever you have configured.

The next question we have is, a critical service has crashed and it won't restart. What steps do you take to troubleshoot and resolve the issue? So, for this, we will need to check the overall status and the logs of the service. So, for this, we can make use of the command, uh, systemctl status <service_name>, and the other command we have is journalctl -u <service_name>. So, this will give us the, uh, status of your service along with the logs of the service. Uh, then we can also look at if there are any configuration errors or there are any dependencies that are missing for, uh, the service. Uh, if there are any configuration errors, we can verify that by making use of, basically, validating your configuration file syntax. So, if it's your Nginx, then we can make use of the nginx -t command. If it's your Apache, then we can make use of your apachectl configtest command, which will basically check the syntax of your configuration files. And any issues that we find, we will need to resolve these issues and then restart the service by making use of your systemctl restart <service_name>. So, basically, check the status, check the logs, identify the issues, resolve that issue, uh, make sure the configuration file syntax is correct, and then restart the service.

The next question we have is, your server's time is out of sync, causing issues with applications. How would you fix this? So, for this, we can install and configure, uh, ntpd or chrony to synchronize time with an NTP server. So, two options: ntpd or chrony, which can be used to synchronize the server's time. Uh, we can make use of this command, which is your ntpq -p, to check the status of your NTP peers. And then we need to ensure that the time zone is correct by making use of this timedatectl command. So, basically, we will need to update the time zone, we'll need to update the time so that it does not cause any issues with the application.

The next question we have is, you need to create a new user and ensure they have no shell access. How would you do this? So, for this, we can make use of the useradd command. So, whenever we talk about, uh, creating new users in Linux, we can make use of the useradd command. Now, for your, uh, no shell login, we can use this option, which is the -s option, to, uh, set the user's, uh, shell. So, in this case, if you don't want to give shell access, then we can either make use of the /sbin/nologin option or we can make use of the /bin/false option. So, example command would be useradd -s /sbin/nologin <username>. So, this will create the user, but it will not give any access to the shell.

The next question we have is, your server is running out of memory and starting to swap heavily. What actions would you take? So, one, uh, the first thing we will need to do is identify which process is, uh, taking up too much of memory space. So, for this, we can either make use of the top command or ps aux --sort -%mem, and then, uh, based on the percentage, basically on the memory, we're telling it to sort, and that will tell us the process which is, you know, very, uh, memory hogging and it's occupying too much of, uh, memory. Uh, then we can consider stopping or restarting those processes. So, sometimes when restarting the process, it will also release the, uh, memory. Then, uh, we can also think of increasing the swap space by creating a new swap file if it's required. So, this would be the command, uh, here we can use this command to create our, uh, swap file. Uh, optimize the application memory usage or add more physical memory to the server. That's another option we can think of. So, either, uh, so check the process which is consuming more memory, restart those processes, or just stop those processes, uh, increase the swap, uh, space, or increase the physical memory on the server. These are some of the options that we can use to, uh, optimize the memory utilization.

The next question we have is, you need to restrict a user's disk usage. How would you implement this? So, for this, we can make use of disk quotas. So, first, we will need to enable, uh, the quotas on the file system. So, for this, we can modify the /etc/fstab file and then remount the file system. Then we can use the edquota to set user-specific disk quotas and then quotaon to enable these quotas. And then we can check the usage with the quota. So, basically, uh, we can set, uh, limitations, uh, on the disk usage for specific users by making use of the disk quotas option, and we'll need to define this in the /etc/fstab file.

The next question we have is, your service needs to start on boot. How do you ensure this? So, for this, we will need to enable the service by using the systemctl enable <service_name>, and, uh, this will make sure the service starts at boot time as well. So, this basically creates the necessary symlinks for the service to start on boot. And then we can verify whether the service has been enabled or not by making use of this systemctl is-enabled <service_name>. So, if the service has been enabled, it will tell that it is enabled, and if not, it will tell that it is disabled. So, we can use this to make sure that even if the system is rebooting for any reason, it will automatically start the service for us.

The next question we have is, your web server is showing a 502 Bad Gateway error. What steps do you take to troubleshoot this? So, first, we will need to check the status and the logs of both your web server, let's say you're using Nginx for your web server, and also your backend service that it proxies to, like your PHP-FPM, to basically check the overall status and the logs of both these servers. Verify that the backend services are running and they're reachable, so they're able to talk to each other. Check the configuration files for any misconfigurations and ensure there are sufficient resources that are available, which is your CPU and, uh, memory. So, you know, these are some of the steps that we can, uh, uh, do to, uh, check why we are getting the, uh, 502 Gateway error. So, making sure, uh, all the servers are running as expected, they're able to talk to each other, there are no misconfigurations, we can look at those.

The next question we have is, you need to schedule, uh, recurring tasks to clean temporary files. How would you do this? So, for this, we can, uh, simply write a script which will clean the temporary files. So, the script may, maybe something like this: `rm -rf /path/to/temp/files`. Once the script is ready, we will need to make the script executable. For that, we can make use of the chmod command, which can be used to set the permissions. Uh, and then we will need to add a cron job to execute this script at the desired intervals. So, we can use this `crontab -e` command to set our cron job and define when the script needs to run. All right, and then the script will start running on a schedule and start deleting the temporary files for us.

The next question we have is, you need to compile and install software from source. What steps do you follow? So, the first thing we will need to do is we need to download that source code tarball, which is your compressed file, and then extract it by making use of this tar command: `tar -xzf <tar_file_name>`, which will basically uncompress the files. Change into that extracted directory and then, uh, we can read the README file or the INSTALL file to understand the specific instructions that we have. And post that, we will, so inside these extracted files, you will have, uh, scripts. Do the configure script, we can run that, then we can run the make command, and then finally the make install command, which can be used to install packages from source code.

The next question we have is, you need to find and kill all processes started by a specific user. How do you do this? So, for this, we will need to first, uh, uh, get the processes. So, we can make use of the ps command to list the processes running by the user. So, we can use `ps -u <username>`, which will list the processes started by that specific user. Once that is done, we'll need to pipe the output of that command to grep and awk to extract the process IDs. So, the, the ps -u command will give the processes. We need to get the process IDs from there and then pass those process IDs to the xargs kill command. So, uh, the, the command would be `ps -u <username> | grep -v PID | awk '{print $1}' | xargs kill -9`. Which will go ahead and kill the process, the specific process started by the, uh, user.

And that brings us to the end of our 15 scenario-based Linux interview questions along with their answers. I hope you found this video helpful and that it boosts your confidence for your next interview. If you have any questions or specific topics that you would like me to cover in future videos, please let me know in the comments section. Don't forget to like, share, and subscribe to the channel for more valuable content. Thank you for watching, and I will see you in the next video.