Linux is an open-source operating system based on the UNIX architecture. It was created by Linus Torvalds in 1991. UNIX, on the other hand, is a family of operating systems that was developed in the late 1960s at Bell Labs. The main differences between UNIX and Linux are:

• License: UNIX is proprietary, while Linux is open-source and free to use.
• Development: UNIX is developed by a few organizations (like IBM, Sun Microsystems, and HP), while Linux has a widespread community-driven development process.
• Portability: Linux is more portable and can be used on a wide range of hardware, whereas UNIX is limited to specific hardware platforms.
• User base: Linux has a broader user base, including personal computers, servers, and embedded systems, while UNIX is primarily used in enterprise environments.

The Linux kernel is the core component of the Linux operating system. It is responsible for managing the system's resources, providing an interface between hardware and software, and facilitating essential tasks such as memory management, process scheduling, and input/output (I/O) operations.

Inodes in Linux are data structures that store important information about files on a file system. Each file or directory in a Linux file system has an associated inode that contains metadata such as the file's size, permissions, ownership, timestamps, and the location of the file's data blocks on the disk.

When you create a file or directory, the file system assigns a unique inode number to it. The inode number serves as an identifier for the file, allowing the file system to access the inode's information and manage the file accordingly.

Here's a summary of what inodes store:

• File type (regular file, directory, symbolic link, etc.)
• File permissions (read, write, execute)
• Ownership (user and group)
• Timestamps (creation, modification, and access times)
• File size
• Number of hard links to the file
• Location of the file's data blocks on the disk

It's important to note that inodes don't store the file's name or the actual file data. The file name is stored in the directory that contains the file, which associates the name with the inode number. The actual file data is stored in separate data blocks on the disk, and the inode points to these blocks.

Inodes play a crucial role in managing files and directories within a Linux file system, providing an efficient way to access and manipulate file metadata.

The Linux boot process consists of several stages that initialize the system and load the operating system. Here's a brief overview of the key steps:

BIOS/UEFI: When the computer is powered on, the BIOS (Basic Input/Output System) or UEFI (Unified Extensible Firmware Interface) performs initial hardware checks and locates the boot device.

Bootloader: The bootloader (e.g., GRUB) loads from the boot device and presents the available operating systems to the user. It then loads the Linux kernel and initial RAM disk (initrd) into memory.

Kernel initialization: The Linux kernel initializes hardware, sets up memory management, starts essential processes, and mounts the initial RAM disk, which contains essential drivers and tools needed during the boot process.

Root file system: The kernel switches the root file system from the initial RAM disk to the actual root partition on the disk, typically identified by its UUID or device name (e.g., /dev/sda1).

Init process: The first user-space process, called init (e.g., Systemd, SysVinit, or Upstart), starts and manages system services and processes during the boot process and the system's runtime.

Runlevel/target: Init process initializes the predefined runlevel (SysVinit) or target (Systemd), which determines the services and processes to run at startup.

Login prompt: Once all services and processes specified in the runlevel/target have started, the system displays a login prompt, indicating that the boot process is complete and the system is ready for use.

A zombie process, also known as a defunct process, is a process that has completed its execution but still remains in the process table. This happens because the parent process has not yet read the child process's exit status, which is required to clean up the child process's resources and remove its entry from the process table.

Zombie processes don't consume any system resources, except for the process table entry, which includes the process ID (PID) and the exit status. The operating system keeps this information so that the parent process can eventually retrieve the exit status and perform the necessary clean-up.

More info on zombie processes below:

Typically, a well-behaved parent process will use the wait() or waitpid() system call to collect the exit status of its child processes. However, if the parent process doesn't do this, either due to a programming error or because the parent is still running and hasn't reached the point where it collects the exit status, the child process becomes a zombie.

Zombie processes are usually harmless, but if a system accumulates a large number of them, it could exhaust the available PIDs and prevent new processes from being created. To resolve this issue, the parent process should be fixed to correctly handle its child processes' exit status, or if the parent process is unresponsive or terminated, a system reboot might be necessary.

Soft links and hard links are two types of file links in a Unix-like file system, such as Linux. They serve different purposes and have distinct characteristics:

Soft Link (Symbolic Link):

• A soft link is a separate file that points to the target file or directory by storing its path.
• If the target file is deleted, the soft link becomes a "dangling" link, pointing to a nonexistent file.
• Soft links can span across different file systems and partitions.
• Soft links can link to directories as well as files.
• When a soft link is created, the link count of the target file doesn't change.
• Soft links have different inode numbers than their target files.

Hard Link:

• A hard link is a direct reference to the data on the disk, sharing the same inode as the target file.
• If the target file is deleted, the hard link still points to the data, and the data remains accessible until all hard links to it are removed.
• Hard links can only be created within the same file system or partition.
• Hard links cannot link to directories, only to files.
• When a hard link is created, the link count of the target file increases by one.
• Hard links have the same inode numbers as their target files.

In summary, a soft link is a more flexible but less reliable type of link that can point to files or directories across file systems, while a hard link is a more robust link that directly references the file's data, but is limited to the same file system and cannot link to directories.

Namespaces and cgroups (control groups) are two Linux kernel features that play a crucial role in implementing process isolation and resource management, especially in containerization technologies like Docker.

Namespaces:

Namespaces are a feature that provides process isolation by creating separate instances of certain system resources, which can only be accessed by processes within the same namespace. This isolation helps ensure that processes running in one namespace don't interfere with processes in another namespace

There are several types of namespaces, including:

• PID namespace: Isolates process IDs, allowing each namespace to have its own set of PIDs.
• Mount namespace: Isolates the file system mount points, so that each namespace has its own mount tree.
• Network namespace: Isolates network resources, providing each namespace with its own network stack, including interfaces, routes, and firewall rules.
• IPC namespace: Isolates inter-process communication resources, preventing processes in one namespace from communicating with processes in another namespace.
• UTS namespace: Isolates system identifiers like hostname, allowing each namespace to have its own unique hostname.
• User namespace: Isolates user and group ID mappings, enabling each namespace to have its own set of user and group IDs.

Cgroups (Control Groups):

Cgroups are a kernel feature that enables the management and limitation of system resources, such as CPU, memory, and I/O, for a group of processes. Cgroups help ensure fair distribution of resources, prevent resource starvation, and enforce limits on resource usage. Some of the key features of cgroups include:

• Resource limiting: Allows setting limits on resource usage for a group of processes, such as maximum CPU usage, memory consumption, and disk I/O bandwidth.
• Prioritization: Enables setting priorities for resource allocation among different cgroups, helping to ensure that critical processes receive sufficient resources.
• Accounting: Collects resource usage statistics for processes in a cgroup, which can be useful for monitoring, profiling, and billing purposes.
• Control: Provides a mechanism to start, stop, or freeze processes in a cgroup, allowing for better management of process groups.

In combination, namespaces and cgroups provide the necessary isolation and resource management capabilities required to build and run containers, enabling multiple containers to coexist on the same host without interfering with each other or consuming excessive resources.

Symbolic links, also known as soft links or symlinks, are a type of file link in Unix-like file systems, such as Linux. A symbolic link is a special file that points to another file or directory by storing its path. Symbolic links serve as a reference to the target file or directory, allowing users and applications to access the target through the link.

Symbolic links are useful in various scenarios, such as creating shortcuts, linking to files or directories in different locations, or maintaining multiple versions of a file or directory. Some key characteristics of symbolic links are:

Symbolic links can point to files or directories, and they can span across different file systems and partitions. If the target file or directory is moved or deleted, the symbolic link becomes a "dangling" link, pointing to a nonexistent location. Symbolic links have different inode numbers than their target files or directories. When listing files with the ls command, symbolic links are usually indicated by an "l" at the beginning of the file permissions and an arrow (->) pointing to the target file or directory.

To create a symbolic link in Linux, you can use the ln command with the -s option, followed by the target file or directory and the desired symlink name:

ln -s target_file symlink_name

Example:

ln -s /path/to/original/file.txt link_to_file.txt

This command creates a symbolic link named link_to_file.txt that points to the file located at /path/to/original/file.txt.

In Linux, there are three main types of permissions for files and directories, which determine how users can interact with them. These permissions are classified into categories based on the user's relationship to the file or directory: owner, group, and others (sometimes referred to as "world" or "public"). The three types of permissions are:

Read (r): Read permission allows a user to view the contents of a file or list the contents of a directory. For files, this means the user can open and read the file. For directories, the user can view the names of files and subdirectories within that directory.

Write (w): Write permission allows a user to modify the contents of a file or make changes within a directory. For files, this means the user can edit, append, or delete the file's content. For directories, the user can create, rename, or delete files and subdirectories within that directory. Note that deleting or renaming files within a directory requires write permission on the directory itself, not the individual files.

Execute (x): Execute permission allows a user to run a file as a program or script, or enter and access a directory. For files, this means the user can execute the file if it is a binary executable or script with a proper interpreter (e.g., a shell script or Python script). For directories, the user can change their current working directory to that directory, and access files and subdirectories within it.

These permissions are usually represented using a combination of letters (r, w, x) and dashes (-) for each of the three categories: owner, group, and others. For example, the permission string -rwxr-xr-- indicates:

• The first character - indicates it's a regular file (a d would indicate a directory).
• The owner has read (r), write (w), and execute (x) permissions: rwx.
• The group has read (r) and execute (x) permissions, but not write permission: r-x.
• Others have only read (r) permission: r--.

Alternatively, permissions can also be represented using octal notation (base-8), where read, write, and execute permissions are assigned values of 4, 2, and 1, respectively. The permissions are then represented by a three-digit number, with each digit corresponding to the owner, group, and others. For example, the permission string -rwxr-xr-- can be represented as 754 in octal notation.

Swap space is a dedicated area on a storage device (such as a hard drive or SSD) that functions as an extension of a computer's physical memory (RAM). It is used by the operating system to temporarily store data that does not fit into RAM or when the system experiences memory pressure due to high RAM utilization.

When the operating system needs more memory than is physically available, it can move the least recently used or less important data (called pages) from RAM to the swap space. This process is called "paging" or "swapping out." By doing so, it frees up space in RAM for more critical or frequently accessed data. If the swapped-out data is required again, the operating system will move it back into RAM, possibly swapping out other data in the process. This is called "swapping in."

Swap space can be implemented as a dedicated swap partition or a swap file. In Linux, you can manage swap space using commands such as swapon, swapoff, and mkswap. To check the current swap space usage on a Linux system, you can use the free or swapon -s commands.

chmod chmod (change mode) is a command used to change the permissions of a file or directory. You can set read, write, and execute permissions for the owner, group, and others. Permissions can be represented in octal notation (numeric) or using symbolic notation (letters).

Example: For example, to give the owner read, write, and execute permissions, the group read and execute permissions, and others only read permission, you would use:

• Using octal notation: chmod 754 file.txt
• Using symbolic notation: chmod u=rwx,g=rx,o=r file.txt

chown

chown (change owner) is a command used to change the ownership of a file or directory. You can specify a new owner and an optional new group for the file or directory.

Example: For example, to change the owner of file.txt to the user john and the group to developers, you would use:

chown john:developers file.txt

chgrp

chgrp (change group) is a command used to change the group assignment of a file or directory. You can specify a new group for the file or directory.

Example: For example, to change the group of file.txt to the group developers, you would use:

chgrp developers file.txt

Cronjobs, also known as cron jobs or simply cron, are scheduled tasks that run automatically at specified intervals on Unix-like operating systems, such as Linux. The term "cron" comes from the Greek word "chronos," which means "time." Cronjobs are commonly used for automating repetitive tasks, performing system maintenance, running periodic backups, and other similar activities.

Cronjobs are managed by a daemon called "cron," which runs in the background and executes the scheduled tasks. The configuration for cron jobs is stored in a series of files called "crontabs" (short for "cron tables"). Each user on the system can have their own crontab, and there is also a system-wide crontab.

For example, a cron job that runs every day at 3:30 AM would have the following entry in the crontab:

30 3 * * * /path/to/command arg1 arg2

To manage cron jobs, you can use the crontab command with various options:

• crontab -l: List the current user's cron jobs.
• crontab -e: Edit the current user's cron jobs using the default text editor.
• crontab -r: Remove the current user's cron jobs.
• crontab -u USER: Perform an operation (list, edit, or remove) on the specified user's cron jobs (requires root privileges).

The command chmod +x FILENAME is used to add execute permissions to a file in a Linux or Unix-like system. By adding execute permissions, you allow the file to be run as an executable or script, provided it has the appropriate format and interpreter (e.g., a shell script, Python script, or compiled binary). The +x option specifically grants execute permission to the owner, group, and others (all users).

For example, if you have a script named myscript.sh and you want to make it executable, you would run:

chmod +x myscript.sh

the free command is used to display information about free and used memory. The command provides details on total, used, free, shared, and available memory, as well as swap space usage.

To use the free command, simply type free in the terminal, followed by any desired options. Some common options include:

• -b: Display memory usage in bytes.
• -k: Display memory usage in kilobytes (default).
• -m: Display memory usage in megabytes.
• -g: Display memory usage in gigabytes.
• -h: Display memory usage in a human-readable format, automatically choosing the appropriate unit (e.g., B, K, M, or G).
• -t: Display a line containing the total amount of physical memory and swap space.
• -s N: Continuously display memory usage information, updating every N seconds.

For example, to display memory usage in a human-readable format, you would run:

free -h

pwd

kill -9 PID

find . -type f -name "*.yaml" -exec ls -l {} \;

ps -p <PID> >> for 1 process

ps aux >> display a detailed list of all running processes on the system

netstat -tuln

• ps -ef | grep <process_name>
• ps -ef | grep chrome

Debian based (Ubuntu):

• apt depends <packagename>
• apt-cache depends <packagename>

Red Hat based (Fedora, CentOS)

• dnf repoquery --requires <packagename>

On Linux systems, the concept of "free memory" may be a bit nuanced due to how Linux manages memory. While the term "free memory" is commonly used, Linux uses a sophisticated memory management system that maximizes the utilization of available memory for optimal performance.

In Linux, free memory refers to the memory that is not currently being used by any active processes or cached by the system. However, this does not mean that the memory is entirely unused or wasted. Linux takes advantage of available memory by utilizing it for disk caching, buffering, and other optimizations to improve system performance.

When you check the memory usage using tools like free or top, you will see several memory-related metrics, including "free," "used," "buffers," and "cache." These metrics represent different aspects of memory usage:

1. The ping command is a simple and widely used tool to check the connectivity between your Linux system and a remote server

ping <server_address>

2. The telnet command allows you to establish a connection to a specific port on a server. By attempting to connect to a server's port, you can determine if it's up and accepting connections

telnet <server_address> <port>

3. If the telnet command is not available on your system, you can use nc (netcat), which provides similar functionality.

nc -zv <server_address> <port>

The /proc directory is a virtual filesystem that provides an interface to access process-related information dynamically. It contains various files and folders that provide information about running processes and system configuration.

• It holds details about each running process in separate folders identified by their process IDs (PIDs).
• It also provides system-wide information such as CPU details, memory usage statistics, network-related data, and kernel parameters.
• The content of /proc changes dynamically based on the current state of the system and running processes.

• Check file permissions: Ensure that the process has the necessary permissions to write to the log files or directories. Verify the ownership and permissions of the log files, and make sure they are writable by the user or group associated with the process

• Verify available disk space: Insufficient disk space can prevent the process from writing to log files

• Restart the process

• Check log file size limit: Some processes have limits on the maximum size of log files they can generate

• Check file system or disk errors: Perform a file system check (fsck) on the relevant file system or check for disk errors using appropriate tools. File system errors or disk issues can sometimes interfere with file writing.

• Verify logging configuration: Ensure that the log file path and other settings are correctly specified

• Check for system-level logging issue: If multiple processes are unable to log files, there might be a system-wide issue with the logging infrastructure. Check system logs (e.g., /var/log/syslog or /var/log/messages) for any relevant error messages or indications of logging problems.

• LILO, short for "LInux LOader," is a boot loader program used in older versions of Linux distributions.
• LILO's main function is to load the Linux kernel into memory and initiate the boot process.It presents a menu to the user, allowing the selection of the desired kernel or operating system to boot (if multiple operating systems are installed).
• LILO writes itself to the Master Boot Record (MBR) of the disk, overwriting the existing boot loader.
• Its configuration file (/etc/lilo.conf) specifies the location of the Linux kernel image and boot parameters.
• LILO has been largely replaced by other boot loaders, particularly GRUB (Grand Unified Bootloader), which offers more advanced features and flexibility.
• GRUB has become the default boot loader for many Linux distributions.

• Syscalls are the interface between user-space applications and the kernel in Linux.
• They allow user programs to request services and access operating system resources.
• User programs invoke syscalls using special instructions, triggering a switch from user mode to kernel mode.

• "No route to host" is an error message that can occur in Linux when attempting to establish a network connection to a remote host

Hard Link

• Direct reference to an existing file or directory.
• Creates a new name or entry pointing to the same data.
• Both the original file and hard link refer to the same underlying data.
• Deleting one does not affect the other.
• Essentially multiple names for the same file.

Symbolic Link (Symlink)

• Special file that acts as a pointer or shortcut.
• Contains the path or location of the target file or directory.
• Resolves the path to the target when accessed.
• Can point to files or directories on different file systems or even non-existent or moved targets.
• Deleting the original file or directory doesn't automatically delete the symlink.
• Symlink becomes "broken" if the target is deleted or moved.

Example

Assume we have a file named "original.txt" with the content "Hello, world!" in the directory /home/user/.

Hard Link:

• Create a hard link named "hardlink.txt" to "original.txt" using the ln command: ln /home/user/original.txt /home/user/hardlink.txt
• Both "original.txt" and "hardlink.txt" now refer to the same file and share the same data.
• If you modify the content of "original.txt", the changes will be visible when accessing "hardlink.txt" and vice versa.
• Deleting either "original.txt" or "hardlink.txt" will not affect the other file.

Symbolic (soft) link:

• Create a symbolic link named "symlink.txt" to "original.txt" using the ln command with the -s option: ln -s /home/user/original.txt /home/user/symlink.txt
• "symlink.txt" is a separate file that acts as a pointer to "original.txt".
• If you modify the content of "original.txt", the changes will be reflected in "symlink.txt".
• Deleting "original.txt" will not automatically delete "symlink.txt", but accessing "symlink.txt" will result in a broken link if the target is not available.

In summary, with a hard link, you have multiple names for the same file sharing the same data, while with a symbolic link, you have a separate file acting as a pointer to another file or directory.

• BIOS/UEFI: When you power on the computer, the Basic Input/Output System (BIOS) or Unified Extensible Firmware Interface (UEFI) firmware is invoked. It performs hardware initialization, self-tests, and determines the boot device.

• Bootloader: GRUB (the most common Linux bootloader) loads the operating system into memory.

• Kernel Initialization: Once the bootloader hands off control, the Linux kernel is loaded into memory. It starts executing from its entry point. The kernel is responsible for managing system resources, such as memory, processes, devices, and file systems.

• Init Process: The first user-space process, known as the init process, is started by the kernel. The init process has a process ID (PID) of 1 and is responsible for initializing the system further. In modern Linux distributions that use systemd as the init system, the init process is replaced by the systemd process.

• Init System/Services: System services and daemons are launched.

• Login Manager: A login screen or prompt appears for user authentication.

• User Session: After login, the user's session starts with the desktop environment.

In summary, the boot process involves firmware initialization, bootloader loading the OS, kernel taking control, system initialization, login prompt, and user session start.

• Check File Permissions: Verify that the process has proper permissions to write to the log files or directories. Ensure that the file permissions and ownership are correctly set to allow the process to write logs.
• Review Log File Configuration: Check the configuration file (e.g., /etc/rsyslog.conf or /etc/syslog-ng/syslog-ng.conf) to ensure that the log files and their destinations are correctly defined.
• Check Disk Space: Insufficient disk space can prevent file logging. Use the df command to check the available disk space. Ensure that the filesystem containing the log files has enough free space to accommodate new logs.
• Check System Logs: Review the system logs (/var/log/syslog, /var/log/messages, etc.) for any relevant error messages or indications of issues related to the logging process. Look for log entries related to the process and check if any error messages are reported.
• Restart the Logging Service: Restart the logging service associated with the process (if you use rsyslog for logging) >> sudo systemctl restart rsyslog

• System Resource Usage:

  • Monitor CPU usage: Use tools like top or htop to check CPU usage and identify any processes consuming excessive CPU resources.
  • Check memory usage: Use commands like free or top to examine memory usage and ensure sufficient free memory is available.
  • Monitor disk usage: Use df or du commands to check disk space utilization and identify any partitions nearing capacity limits.

• System Services and Processes::

  • Check running processes: Use ps or top to view running processes and ensure critical services are active.
  • Verify system services: Use service management tools like systemctl (systemd) or service (init) to check the status of essential services.

• System Logs:

  • Review system logs: Examine log files in /var/log/ (e.g., /var/log/syslog, /var/log/messages) for any error or warning messages related to system components, applications, or hardware.
  • Monitor log files in real-time: Use the tail command with the -f option to track log files as new entries are added.

• Network Connectivity:

  • Check network interfaces: Use ifconfig or ip command to verify the status and configuration of network interfaces.
  • Test network connectivity: Use ping or traceroute to test connectivity to remote hosts or check for network latency or packet loss.

• Hardware monitoring?

• Security and updates?

• Backup and recover?

• The terminal program receives the command you typed and identifies the command and any arguments.

• The shell then searches for the location of the command binary within the directories specified in the PATH environment variable. It looks for an executable file with a matching name.

• Once the command binary is located, the shell initiates a system call, specifically the execve() system call, to load the command into memory and execute it.

• The kernel allocates memory for the command and sets up file descriptors for input, output, and error handling.

• The kernel performs a context switch, transitioning from the shell to the command.

• The command binary is loaded into memory, and its execution begins.

• As the command executes, it may make additional system calls to interact with the kernel. For example, the "ls" command might make system calls to read directory contents or retrieve file metadata.

• The command may manipulate the terminal's display using control codes.

• Once the command completes, the kernel returns control to the shell.

• The ping command is a simple and widely used tool to check the connectivity between your Linux system and a remote server >> ping <server_address>
• The telnet command allows you to establish a connection to a specific port on a server. By attempting to connect to a server's port, you can determine if it's up and accepting connections >> telnet <server_address> <port>
• If the telnet command is not available on your system, you can use nc (netcat), which provides similar functionality >> nc -zv <server_address> <port>

• In Linux, processes can be terminated or killed at a lower level using signals. Signals are software interrupts sent to a process to convey various notifications or requests. They can be used to terminate a process gracefully, forcefully, or perform other actions

  • SIGTERM (Signal 15): This is the default termination signal sent to a process when you use the kill command without specifying a signal. It politely requests the process to terminate and allows it to perform cleanup operations before exiting.

  • SIGKILL (Signal 9): This signal forcefully terminates a process. It does not allow the process to perform any cleanup or graceful shutdown procedures. The process is immediately terminated.

  • SIGINT (Signal 2): This signal is generated when you press Ctrl+C on the keyboard. It is typically used to interrupt or terminate a process that is running in the foreground.

  • SIGQUIT (Signal 3): Similar to SIGINT, this signal is generated when you press Ctrl+\ on the keyboard. It usually requests a process to terminate and provides a core dump for debugging purposes.

Method 1 - Copy the file from another system:

• If you have compatible systems, you can always just grab a copy of chmod from another server using scp or rsync.

cd /bin
mv chmod chmod.orig
scp twin:/bin/chmod .
diff chmod chmod.orig

Method 2 - Restoring from Backup:

• If you have a recent backup of the affected system, you can restore the correct permissions of the chmod command by replacing it with the version from the backup. Copy the chmod binary from the backup location to the /bin directory, ensuring that the correct permissions are retained.

Method 3

• Check Network Configuration: Verify that the network configuration is correct. Use commands like ifconfig or ip to check the status of network interfaces, IP addresses, subnet masks, and gateway settings.
• Ping: Use the ping command to test basic connectivity to a remote host or IP address. For example, ping 8.8.8.8 pings Google's public DNS server. If the ping is successful, it indicates that network connectivity is established.
• Check DNS Resolution: If you are having trouble accessing websites by domain name, check if DNS resolution is functioning correctly. Use the nslookup or dig command to query DNS servers and verify if they are returning the correct IP addresses for the given domain
• Check Routing: Use the traceroute or tracepath command to trace the route packets take to reach a destination. It helps identify any network hops or routing issues along the path.
• Firewall Configuration: Review the firewall configuration to ensure it is not blocking the required network traffic. Check the rules in tools like iptables, ufw, or other firewall management tools.
• Check Network Services: Ensure that required network services, such as DHCP (Dynamic Host Configuration Protocol) or DNS, are running and functioning properly. Use commands like systemctl or service to check the status of specific services.
• Inspect Network Logs: Check system logs in /var/log/ (e.g., /var/log/syslog, /var/log/messages) for any relevant error messages related to network interfaces, services, or connectivity issues.
• Test Connectivity with Different Tools: Use network troubleshooting tools like netcat (nc), curl, or wget to test connectivity to specific ports or services on remote hosts.

• Check Network Connectivity >> ping <server_ip_or_hostname>
• Verify DNS Resolution >> nslookup <server_hostname> or dig
• Check Firewall Settings: Verify that your local firewall or any intermediate firewalls are not blocking the necessary network traffic. Temporarily disable the firewall or configure it to allow the specific ports or protocols required to communicate with the remote server.
• Verify Port Connectivity >> telnet <server_ip_or_hostname> <port_number>
• Trace Route: Use the traceroute or tracepath command to trace the network path to the remote server >> traceroute <server_ip_or_hostname>
• Review Server Logs: Examine the server's logs for any error messages or indications of connectivity issues. Check logs related to the specific services running on the server, such as Apache logs for web server issues.
• Check Server Services: Ensure that the necessary services on the remote server are running and properly configured

• View logs >> cat /var/log/syslog - use SUDO
• Edit logs >> vim /var/log/syslog - use SUDO

• scp

• scp -r

The Hypertext Transfer Protocol (HTTP) is the foundation of the World Wide Web, and is used to load webpages using hypertext links. HTTP is an application layer protocol designed to transfer information between networked devices and runs on top of other layers of the network protocol stack. A typical flow over HTTP involves a client machine making a request to a server, which then sends a response message.

HTTPS is an extension of the Hypertext Transfer Protocol. The S in HTTPS stands for “secure.” When a website is encrypted with TLS (or SSL), it uses Hypertext Transfer Protocol Secure (HTTPS).

Basically, it’s HTTP with encryption. It is used to secure communication over a computer network and is widely used on the Internet. HTTPS encrypts and decrypts user page requests and the pages returned by the web server.

The most significant difference between the two protocols is that HTTPS is encrypted and secured using digital certificates, while HTML is not. When you visit a website using HTTPS, your connection to that site is encrypted. Any information you send or receive on that site is also encrypted.

Another difference between the protocols is that HTTPS uses port 443, while HTML uses port 80. Port 443 is the standard port for secured Hypertext Transfer Protocol (HTTPS). Port 80 is the default port for unsecured Hypertext Transfer Protocol.

An HTTP request is the way Internet communications platforms such as web browsers ask for the information they need to load a website.

Each HTTP request made across the Internet carries with it a series of encoded data that carries different types of information. A typical HTTP request contains:

1. HTTP version type
2. a URL
3. an HTTP method
4. HTTP request headers
5. Optional HTTP body

An HTTP method, sometimes referred to as an HTTP verb, indicates the action that the HTTP request expects from the queried server. For example, two of the most common HTTP methods are ‘GET’ and ‘POST’; a ‘GET’ request expects information back in return (usually in the form of a website), while a ‘POST’ request typically indicates that the client is submitting information to the web server (such as form information, e.g. a submitted username and password).

HTTP headers contain text information stored in key-value pairs, and they are included in every HTTP request. These headers communicate core information, such as what browser the client is using and what data is being requested.

The body of a request is the part that contains the ‘body’ of information the request is transferring. The body of an HTTP request contains any information being submitted to the web server, such as a username and password, or any other data entered into a form.

An HTTP response is what web clients (often browsers) receive from an Internet server in answer to an HTTP request. These responses communicate valuable information based on what was asked for in the HTTP request.

A typical HTTP response contains:

1. An HTTP status code
2. HTTP response headers
3. Optional HTTP body

HTTP status codes are 3-digit codes most often used to indicate whether an HTTP request has been successfully completed. Status codes are broken into the following 5 blocks:

• 1xx Informational
• 2xx Success
• 3xx Redirection
• 4xx Client Error
• 5xx Server Error

The “xx” refers to different numbers between 00 and 99.

Status codes starting with the number ‘2’ indicate a success. For example, after a client requests a webpage, the most commonly seen responses have a status code of ‘200 OK’, indicating that the request was properly completed.

If the response starts with a ‘4’ or a ‘5’ that means there was an error and the webpage will not be displayed. A status code that begins with a ‘4’ indicates a client-side error (it is very common to encounter a ‘404 NOT FOUND’ status code when making a typo in a URL). A status code beginning in ‘5’ means something went wrong on the server side. Status codes can also begin with a ‘1’ or a ‘3’, which indicate an informational response and a redirect, respectively.

Much like an HTTP request, an HTTP response comes with headers that convey important information such as the language and format of the data being sent in the response body.

Successful HTTP responses to ‘GET’ requests generally have a body which contains the requested information. In most web requests, this is HTML data that a web browser will translate into a webpage.

Protocols are rules that govern how data is formatted and sent over a network. TCP and UDP are two different methods for doing the same job: transferring data via the internet. They enable servers and devices to communicate so you can send emails, watch Youtube, play games, and browse web pages.

The main difference between TCP (transmission control protocol) and UDP (user datagram protocol) is that TCP is a connection-based protocol and UDP is connectionless. While TCP is more reliable, it transfers data more slowly. UDP is less reliable but works more quickly. This makes each protocol suited to different types of data transfers.

The process of DNS resolution involves converting a hostname (such as www.google.com) into a computer-friendly IP address (such as 192.168.1.1). An IP address is given to each device on the Internet, and that address is necessary to find the appropriate Internet device - like a street address is used to find a particular home. When a user wants to load a webpage, a translation must occur between what a user types into their web browser (example.com) and the machine-friendly address necessary to locate the example.com webpage.

DNS (Domain Name System) works by translating human-friendly domain names (like www.example.com) into IP addresses (like 192.168.1.1) that computers use to identify each other on the internet. Here's a simplified step-by-step process:

1. User enters a domain name in a web browser.
2. The computer first checks its local DNS cache to see if it already knows the corresponding IP address.
3. If not found, the computer sends a DNS query to a DNS resolver (usually provided by your internet service provider or a public DNS service like Google's 8.8.8.8).
4. The DNS resolver searches its cache for the IP address. If not found, it starts a recursive process: a. The resolver queries root DNS servers to find the authoritative DNS server for the top-level domain (like .com). b. The resolver then queries the top-level domain's authoritative DNS server to find the authoritative server for the specific domain (like example.com). c. Finally, the resolver queries the domain's authoritative server for the IP address of the requested domain (www.example.com).
5. The authoritative DNS server responds with the IP address, and the resolver caches this information for future use.
6. The resolver returns the IP address to the user's computer.
7. The computer can now establish a connection with the web server at the provided IP address, allowing the user to access the website associated with the domain name.

• In essence, DNS acts as the internet's phone book, translating user-friendly domain names into the numerical addresses computers need to communicate.

TLS (Transport Layer Security) is a cryptographic protocol that provides secure communication over a computer network, such as the internet. It ensures data privacy and integrity by encrypting the data transmitted between two systems, typically a web browser and a web server. TLS is commonly used to secure online transactions, like credit card payments and sensitive data transfers, by establishing a secure, encrypted connection between the client and server. This encryption helps protect against eavesdropping and data tampering during transmission.

CIDR (Classless Inter-Domain Routing) ranges are a way to represent and allocate IP addresses and subnets in a more flexible manner than traditional subnetting using classes (Class A, B, C, etc.). In CIDR notation, an IP address is followed by a slash ("/") and a number, which indicates the number of bits in the network portion of the address. Here's a simple example:

IP Address: 192.168.1.0 CIDR Notation: 192.168.1.0/24 In this example, "/24" means that the first 24 bits of the IP address are used to identify the network, leaving 8 bits for host addresses. This allows for finer control over IP address allocation and subnetting compared to the older class-based system (e.g., Class A, B, C).

CIDR notation is widely used in networking to specify IP address ranges, making it easier to manage and allocate IP addresses efficiently.

In networking and security, "ingress" and "egress" refer to the movement of data or traffic into and out of a network, system, or device:

Ingress Traffic: This is incoming traffic that enters a network or system. Ingress traffic typically originates from external sources, such as the internet, and flows into a network through a gateway, router, or firewall. Monitoring and controlling ingress traffic is important for security purposes to prevent unauthorized access or attacks.

Egress Traffic: Egress traffic, on the other hand, is outgoing traffic that exits a network or system and goes towards external destinations. Egress traffic might include data leaving a corporate network to access a website, send emails, or communicate with cloud services. Managing egress traffic is essential for monitoring data leaving a network and enforcing policies related to data transmission.

In summary, ingress traffic comes into a network, while egress traffic goes out of it. Network administrators often use firewall rules and security measures to control and secure both ingress and egress traffic to protect the network from threats and ensure proper data flow.

A switch and a hub are both networking devices used to connect multiple devices in a local area network (LAN), but they operate in fundamentally different ways:

Switch:

A switch operates at the data link layer (Layer 2) of the OSI model. It is an intelligent device that examines the MAC (Media Access Control) addresses of data packets to determine where to forward them. Switches create a dedicated, point-to-point connection between the sender and recipient, improving network efficiency by reducing collisions. They can filter and forward traffic only to the specific device that needs it, enhancing network security and performance. Switches are common in modern networks due to their efficiency and ability to handle high traffic loads.

Hub:

A hub operates at the physical layer (Layer 1) of the OSI model. It is a basic and passive device that simply broadcasts incoming data packets to all connected devices without any intelligence. Hubs do not examine MAC addresses or make decisions about where to send data; they indiscriminately send data to all connected devices. This broadcasting approach can lead to network congestion and collisions, especially in larger networks. Hubs are considered outdated and inefficient for modern networks, and they are rarely used today. In summary, switches are more advanced and efficient networking devices that intelligently forward data packets to the appropriate recipient, while hubs are basic and outdated devices that broadcast data to all connected devices, leading to less efficient network communication. Switches are the preferred choice for building modern, high-performance LANs.

Switch:

A switch operates at the data link layer (Layer 2) of the OSI model. It is used to connect devices within a local area network (LAN). Switches make forwarding decisions based on MAC (Media Access Control) addresses and create efficient, dedicated connections between devices within the same LAN. They are primarily used for local traffic management and do not have a role in routing traffic between different networks.

Router:

A router operates at the network layer (Layer 3) of the OSI model. It connects different networks together and directs traffic between them. Routers use IP addresses to make routing decisions, determining the most appropriate path for data packets to reach their destination, whether that destination is within the same local network or in a different network (e.g., the internet). Routers are essential for interconnecting multiple LANs and facilitating communication between devices on different networks. In summary, switches are used for local network traffic management within a single LAN, while routers are used to connect and route traffic between different networks, including routing traffic between LANs and the broader internet. Both devices play critical roles in network communication and connectivity.

HTTPS and WebSockets are both protocols used for web communication, but they serve different purposes and operate in distinct ways:

HTTPS (HyperText Transfer Protocol Secure):

• HTTPS is an extension of the HTTP protocol used for secure communication over the internet. It encrypts the data transmitted between a web browser and a web server, providing data confidentiality and integrity.
• HTTPS uses SSL/TLS (Secure Sockets Layer/Transport Layer Security) to establish a secure, encrypted connection between the client and server.
• It is commonly used for secure web browsing, online transactions, and protecting sensitive data, such as login credentials and personal information.
• HTTPS is a request-response protocol, meaning that the client sends a request to the server, and the server responds with the requested data.

WebSockets:

• WebSockets is a protocol that provides full-duplex communication channels over a single TCP connection. Unlike HTTP(S), which is request-response-based and stateless, WebSockets allow for two-way, real-time communication between a client (e.g., a web browser) and a server.
• WebSockets are often used in applications that require real-time updates, such as chat applications, online gaming, collaborative tools, and live data feeds.
• They are more efficient for scenarios where continuous communication is needed, as they eliminate the need for repeatedly establishing new connections.
• WebSockets allow data to be pushed from the server to the client and vice versa without the overhead of frequent HTTP requests.

In summary, HTTPS is a protocol for securing web communication, while WebSockets provide a framework for real-time, bidirectional communication over a single, long-lived connection. They are used for different purposes but can complement each other in web applications, where secure and real-time communication is required.

A three-way handshake is a method used in a TCP/IP network to create a connection between a host and a client. It’s called a three-way handshake because it is a three-step method in which the client and server exchanges packets. The three steps are as follows: The client sends a SYN(Synchronize) packet to the server check if the server is up or has open ports. The server sends SYN-ACK packet to the client if it has open ports. The client acknowledges this and sends an ACK(Acknowledgment) packet back to the server.

Stateless and stateful firewalls are two types of network security devices that filter and control incoming and outgoing network traffic, but they do so in different ways:

Stateless Firewall:

• Stateless firewalls filter traffic based solely on the source and destination IP addresses, as well as port numbers. They do not maintain any information about the state of ongoing network connections.
• Stateless firewalls are simpler and faster but lack the ability to make decisions based on the context or state of a connection.
• Each packet is evaluated in isolation, without considering whether it's part of an established connection or whether it's a legitimate response to an outbound request.
• Stateless firewalls are often used in basic network security setups and are suitable for scenarios where a basic level of security is sufficient.

Stateful Firewall:

• Stateful firewalls, also known as dynamic packet filtering firewalls, maintain a table of the state of active network connections.
• They keep track of the state of TCP and UDP sessions, including the state of each connection (e.g., established, related, new) and their associated ports.
• Stateful firewalls make decisions based on the context of network traffic, allowing them to permit or deny packets based on whether they are part of a legitimate, established connection.
• This context-awareness makes stateful firewalls more effective at protecting against various types of attacks, such as port scanning and certain forms of packet-level attacks.
• They are commonly used in enterprise networks and provide a higher level of security compared to stateless firewalls.

In summary, stateless firewalls filter traffic based solely on basic information like IP addresses and port numbers, while stateful firewalls maintain information about the state of active connections and make decisions based on the context of the traffic. Stateful firewalls are generally more advanced and provide better security for modern network environments.

VPC stands for Virtual Private Cloud. It is a fundamental component of cloud computing infrastructure, particularly in services like Amazon Web Services (AWS) and Microsoft Azure.

VPC (Virtual Private Cloud):

• A VPC is a logically isolated section of a cloud provider's network where you can launch and manage your virtual resources like virtual machines (VMs), databases, and storage.
• It allows you to create your own private network within the cloud, complete with private IP addresses, subnets, route tables, and security groups.
• VPCs provide control over network configurations, security, and communication between resources, making it possible to build secure and scalable cloud-based applications.
• You can also connect your VPC to your on-premises data centers or other VPCs, creating a hybrid or multi-cloud network.
• VPCs are essential for ensuring network isolation, security, and resource organization in cloud environments.

Subnetting is the process of dividing a larger IP network into smaller, more manageable subnetworks, or "subnets." This practice is commonly used in networking to:

• Improve Network Efficiency: Subnetting allows you to create smaller segments within a larger network. This can help reduce broadcast traffic and improve overall network performance by isolating traffic to specific subnets.

• Enhance Security: By dividing a network into subnets, you can implement access control lists (ACLs) and firewall rules more effectively. This helps control and secure traffic between different parts of the network.

• IP Address Management: Subnetting aids in efficient IP address allocation. Each subnet can have its own range of IP addresses, making it easier to manage and allocate IP addresses within an organization.

• Isolation and Segmentation: Subnets can isolate different types of devices or services from each other. For example, you can place servers in one subnet and user devices in another to improve security and management.

Subnetting involves dividing an IP address range into smaller, contiguous blocks, each with its own network address and a range of host addresses. This is typically done by modifying the subnet mask associated with the IP address range. The subnet mask designates which portion of the IP address is the network part and which part is the host part.

For example, if you have the IP address range 192.168.0.0/24 (where "/24" indicates a subnet mask of 255.255.255.0), you can subnet it into smaller subnets like 192.168.0.0/25 and 192.168.0.128/25, each with half of the original IP address range's available host addresses.

DHCP stands for Dynamic Host Configuration Protocol. It is a network protocol used to automate and simplify the process of assigning IP addresses and other network configuration settings to devices on a local network.

DHCP (Dynamic Host Configuration Protocol):

• DHCP is a client-server protocol commonly used in local area networks (LANs) and on the internet.
• It eliminates the need for manual IP address configuration on each device in a network.
• When a device (client) connects to a network, it sends a DHCP request to a DHCP server, typically a router or dedicated DHCP server.
• The DHCP server responds with an available IP address, subnet mask, default gateway, DNS server addresses, and other configuration parameters.
• The client then configures itself with the provided information, making it ready to communicate on the network.

When you type "google.com" into your web browser's address bar and hit Enter, several steps occur behind the scenes to display the Google homepage. Here's a simple breakdown of what happens:

DNS Resolution:

• Your web browser first checks its local cache to see if it already knows the IP address associated with "google.com." If it does, it skips the next steps.
• If not found in the cache, your browser sends a DNS (Domain Name System) resolution request to a DNS resolver. This is usually provided by your internet service provider (ISP) or a public DNS service like Google's 8.8.8.8.
• The DNS resolver checks its cache to see if it has the IP address for "google.com." If not, it initiates the DNS resolution process.

DNS Resolution Process:

• The DNS resolver queries root DNS servers to find the authoritative DNS server for the top-level domain (TLD), which is "com" in this case.
• The root DNS server responds with the IP address of the authoritative DNS server for the "com" TLD.
• The resolver then queries the authoritative DNS server for the "com" TLD to find the authoritative DNS server for "google.com."
• The authoritative DNS server for "google.com" responds with the IP address associated with "google.com."

IP Address Retrieval:

• The DNS resolver returns the IP address of "google.com" to your web browser.

HTTP Request:

• Your browser initiates an HTTP (Hypertext Transfer Protocol) request to the IP address it received for "google.com."
• The request includes additional information like the specific web page you're trying to access (e.g., "/", which typically represents the homepage).

Server Processing:

• Google's web server, located at the provided IP address, receives the HTTP request.
• The server processes the request and generates an appropriate response.

Response Transmission:

• The web server sends back an HTTP response, which includes the HTML, CSS, JavaScript, and other resources needed to render the Google homepage.

Rendering the Web Page:

Your browser receives the HTTP response and begins rendering the Google homepage on your screen. It may also make additional requests for images, stylesheets, and scripts referenced in the HTML to fully load and display the page.

Page Display:

Once all resources are loaded, your web browser displays the Google homepage on your screen, and you can interact with it. In summary, when you type "google.com" into your browser, a complex series of steps involving DNS resolution, HTTP requests, and server responses occurs to retrieve and display the webpage you requested. This process ensures that you can access websites using human-readable domain names while the internet works behind the scenes using IP addresses to route and deliver content.

Check Network Connectivity:

• Ensure your Linux machine has a working internet connection. Try pinging a reliable website or an IP address (e.g., ping google.com or ping 8.8.8.8 for Google's DNS).

DNS Resolution:

• Verify that DNS resolution is working correctly. Try to resolve the website's IP address using nslookup or dig (e.g., nslookup website.com or dig website.com).
• Check your DNS server configuration in /etc/resolv.conf. Ensure it points to a valid DNS server (e.g., nameserver 8.8.8.8 for Google's DNS).

Check Hosts File:

• Make sure the website is not blocked by entries in the /etc/hosts file. Check for any entries that may be redirecting the website.

Firewall Rules:

• Check if a firewall is blocking outgoing or incoming traffic. Use the iptables or firewall-cmd command to inspect firewall rules.

Web Proxy:

• If you are behind a proxy server, ensure that proxy settings are correctly configured in your environment, including HTTP_PROXY and HTTPS_PROXY environment variables.

Browser Issues:

• Try accessing the website from a different web browser or an incognito/private browsing window to rule out browser-related problems.

SSL/TLS Issues:

• If you are getting SSL/TLS-related errors, ensure your system has up-to-date CA certificates installed. You can also check for SSL/TLS issues using the openssl command (e.g., openssl s_client -connect website.com:443).

Check DNS Cache:

• If you've made changes to DNS configurations, clear your DNS cache using systemctl restart systemd-resolved (on systems using systemd-resolved) or sudo /etc/init.d/nscd restart (on systems using nscd).

Trace Route (Traceroute):

• Use the traceroute or tracepath command to trace the network path to the website (e.g., traceroute website.com or tracepath website.com).

Check System Logs:

• Inspect system logs in /var/log (e.g., /var/log/syslog, /var/log/messages, /var/log/auth.log) for any network-related errors or issues.

Check DNS Server Status:

• Verify the availability and responsiveness of your DNS servers by pinging them or using tools like dig.

Check Website Status:

It's possible that the website itself is down. Check its status on a service like "DownDetector" or "Is It Down Right Now?".

Packet Capture (Optional):

• As a last resort, you can use packet capture tools like tcpdump or wireshark to capture network traffic and analyze it for issues.

The OSI (Open Systems Interconnection) model is a conceptual framework that standardizes and defines the functions of a telecommunication or networking system. It consists of seven distinct layers, each responsible for specific tasks in the communication process. Here's a breakdown of the OSI model and what each layer signifies:

Physical Layer (Layer 1):

Significance: This layer deals with the physical medium and transmission of raw binary data over a physical network. Responsibilities: It defines the physical characteristics of the network, such as cables, connectors, electrical voltages, and transmission speeds. It also specifies how bits are represented, encoded, and transmitted over the network medium.

Data Link Layer (Layer 2):

Significance: This layer focuses on reliable data transfer between directly connected devices on a local network. Responsibilities: It manages the framing of data into frames, error detection and correction, and flow control. Ethernet and Wi-Fi operate at this layer. MAC (Media Access Control) addresses are used for device identification.

Network Layer (Layer 3):

Significance: The network layer is responsible for routing packets across different networks to reach their destination. Responsibilities: It handles logical addressing, routing, and packet forwarding. The Internet Protocol (IP) operates at this layer, and IP addresses are used to identify devices on different networks.

Transport Layer (Layer 4):

Significance: This layer ensures end-to-end communication and data reliability between devices on different networks. Responsibilities: It manages data segmentation, flow control, error detection, and retransmission. TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are commonly used transport layer protocols.

Session Layer (Layer 5):

Significance: The session layer establishes, manages, and terminates communication sessions between two devices. Responsibilities: It handles session setup, maintenance, and teardown, including synchronization, checkpointing, and recovery of data in case of interruptions.

Presentation Layer (Layer 6):

Significance: This layer ensures that data is presented in a readable format for the application layer. Responsibilities: It handles data translation, encryption, compression, and character encoding to ensure that data sent by one device can be understood by another.

Application Layer (Layer 7):

Significance: The application layer is the top layer and represents the actual software applications that users interact with. Responsibilities: It provides a platform-independent interface for application software to communicate with the lower layers. This layer includes protocols like HTTP, FTP, SMTP, and DNS, which enable specific application-level functions.

mTLS (mutual Transport Layer Security) is an extension of the traditional TLS (Transport Layer Security) protocol. Both TLS and mTLS are cryptographic protocols used to secure data transmission over a network, but they differ in how they authenticate and secure the communication.

TLS (Transport Layer Security):

• TLS is used to establish secure, encrypted communication between a client (such as a web browser) and a server (such as a web server).
• In a typical TLS handshake, the server presents its digital certificate to prove its identity to the client.
• The client verifies the server's certificate against a trusted certificate authority (CA) to ensure it's valid.
• Once the server's identity is verified, a symmetric encryption key is exchanged, and encrypted communication begins.
• TLS is primarily used for server authentication and encryption of data in transit between a client and a server.

mTLS (Mutual Transport Layer Security):

• mTLS, also known as two-way TLS or client-side TLS, extends TLS by requiring both the client and the server to present digital certificates and authenticate each other.
• In an mTLS handshake, the client and server exchange certificates and verify each other's identities.
• The client verifies the server's certificate, just like in traditional TLS.
• The server, in turn, verifies the client's certificate to ensure it's valid and belongs to an authorized client.
• Once both parties are authenticated, a symmetric encryption key is exchanged, and encrypted communication begins.
• mTLS is used when both parties (client and server) need to be authenticated and data encryption is required. It's often used in scenarios like secure API communication and IoT device authentication.

In summary, TLS and mTLS are both cryptographic protocols for securing data transmission, but mTLS goes a step further by requiring mutual authentication, where both the client and server authenticate each other using digital certificates. This added layer of security is useful in scenarios where bidirectional trust is essential, such as in securing APIs, web services, or IoT device communication.

The TCP/IP (Transmission Control Protocol/Internet Protocol) connection process involves several steps that occur when two devices communicate over a network. Key steps include:

1. Initialization:

The client initiates the connection by sending a TCP segment with the SYN (synchronize) flag set to the server. This initiates the "three-way handshake" process.

2. Three-Way Handshake:

SYN (Synchronize): The client sends a TCP segment with the SYN flag set, indicating its intent to establish a connection. It also selects an initial sequence number. SYN-ACK (Synchronize-Acknowledgment): The server responds with a TCP segment that has the SYN and ACK (acknowledge) flags set. It acknowledges the client's sequence number and selects its own initial sequence number. ACK (Acknowledgment): The client sends an acknowledgment back to the server, acknowledging the server's sequence number. At this point, the connection is established, and both parties are synchronized.

3. Data Transfer:

Once the connection is established, data can be transmitted in both directions. Data is divided into segments, each with a sequence number for tracking and reordering.

4. Termination:

When one party wishes to close the connection, it sends a TCP segment with the FIN (finish) flag set. The other party acknowledges the FIN and may also send its own FIN. This initiates a "four-way handshake" to ensure that both sides agree to close the connection gracefully.

5. Four-Way Handshake (Connection Termination):

FIN (Finish): One party sends a TCP segment with the FIN flag set to indicate the intent to close the connection. ACK (Acknowledgment): The other party acknowledges the FIN. FIN: The acknowledging party may also send its own FIN to close the connection from its side. ACK: The initial party acknowledges the FIN from the other side, completing the termination process.

6. Connection Closed:

After the four-way handshake, the connection is closed, and no further data can be exchanged.

TCP (Transmission Control Protocol) and UDP (User Datagram Protocol) are two transport layer protocols used in networking, and each has its own strengths and weaknesses. The choice between TCP and UDP depends on the specific requirements of the application or service being used. Here's when and why you might choose TCP over UDP:

Use TCP When:

• Reliability is Critical: TCP provides a reliable and error-checked connection. It ensures that data is delivered accurately and in the correct order. This makes it suitable for applications where data integrity is crucial, such as file transfers, email, and web browsing.

• Ordered Data Delivery: If your application requires data to be delivered in the same order it was sent, TCP is the better choice. It maintains a sequencing mechanism to guarantee ordered data delivery.

• Flow Control: TCP includes flow control mechanisms to prevent overwhelming the receiver with too much data too quickly. This is essential for applications that require rate limiting, like streaming video or real-time communication apps.

• Error Recovery: TCP can detect and recover from errors that may occur during transmission. It retransmits lost or corrupted packets to ensure data reliability.

• Connection-Oriented: TCP establishes a connection before data transfer begins and releases it after the transfer is complete. This connection-oriented nature is suitable for applications that require a reliable, well-defined start and end to communication sessions.

Use UDP When:

• Low Latency is Critical: UDP is faster than TCP due to its minimal overhead. It's suitable for applications that prioritize low latency, such as online gaming, live streaming, and VoIP (Voice over IP).

• Loss Tolerance: UDP does not guarantee data delivery or order, so it's a good choice for applications where occasional packet loss is acceptable, such as real-time data feeds, video conferencing, and some IoT applications.

• Reduced Network Overhead: UDP has less overhead than TCP because it doesn't involve establishing connections, maintaining sequencing, or performing extensive error checking. This can be advantageous for applications with limited bandwidth or high data rates.

• Broadcast or Multicast: UDP supports broadcast and multicast communication, which allows data to be sent to multiple recipients simultaneously. This is useful for applications like online gaming and video streaming.

• Simple Implementation: UDP is easier to implement because it doesn't have the complexities of connection establishment and error recovery. This makes it a good choice for lightweight applications and protocols.

In summary, use TCP when data reliability, ordered delivery, and error recovery are critical. Choose UDP when low latency, reduced overhead, and loss tolerance are more important, and you can handle potential data loss or out-of-order delivery at the application level. The decision depends on the specific needs of your application and the trade-offs you are willing to make between reliability and performance.

Check Network Connectivity:

Verify that both hosts have a stable and functioning network connection. Ensure that cables, switches, and routers are working correctly.

Test Other Network Services:

Determine if the slowness is specific to data transfer or if it affects other network services as well. Try accessing websites, pinging other hosts, or testing other network applications to see if the issue is widespread or isolated.

Check Host Resource Utilization:

Monitor the CPU, memory, and disk utilization on both hosts. High resource usage can lead to slow data transfer. Identify any resource-intensive processes or applications that may be affecting performance.

Review Network Configuration:

Verify that the network configurations on both hosts are correct, including IP addresses, subnet masks, gateways, and DNS settings. Ensure there are no conflicts or misconfigurations.

Check for Network Congestion:

Network congestion can slow down data transfer. Monitor network traffic and identify any bottlenecks or excessive usage on the network segments between the two hosts.

Test Connectivity to Other Hosts:

Try transferring data between each host and other devices on the network to determine if the issue is specific to the connection between these two hosts.

Most widely used modern version control system in the world today. It is used to gather code contributions from multiple users in a single place (repository). Provides full history, workflow and allows for rollback of code and patching.

SVN and Git are both powerful version control systems that each use a different approach to managing and merging code changes. Git uses a distributed model, whereas SVN uses a centralized model.

SVN’s centralized repository model makes it easier to manage contributions and contributors. Git does not support codebase access restrictions — a contributor who has access to the repository has access to the entire repository. SVN, by contrast, provides granular control, allowing for limits on particular contributors down to the directory, and file levels.

The ability to work locally and offline is one major advantage to Git. SVN requires contributors to be connected to the main repository server, which essentially eliminates working offline.

Git also outperforms SVN when it comes to merging and conflict resolution. Git has been designed for an open-source setting where numerous contributors may be working on the same parts of a codebase. To allow for this type of collaboration, Git has built up a robust system for resolving merge conflicts that makes the process smoother, and more manageable.

Working directory > staging area > local repo > remote repo git add git commit git push

The key difference between git fetch and pull is that git pull copies changes from a remote repository directly into your working directory, while git fetch does not. The git fetch command only copies changes into your local Git repo. The git pull command does both.

Benefit of git pull: The local Git repo is now in sync with the remote repo. The local filesystem has the latest, most up to date files.

Benefit of git fetch: If you are actively working on files tracked by Git, but you still want to update your local repository with the latest changes from a remote repository, use the git fetch command.

git cherry-pick is a Git command used to apply a specific commit (or a range of commits) from one branch to another. It allows you to select and "cherry-pick" individual commits from one branch's history and apply them onto another branch. This can be useful when you want to bring specific changes or fixes from one branch into another without merging the entire branch.

The basic syntax of git cherry-pick is as follows:

git cherry-pick <commit-hash>

<commit-hash> is the unique identifier (SHA-1 hash) of the commit you want to apply.

In Git, HEAD is a pointer to the latest commit in the currently checked-out branch. It represents the current state of the branch and is used for navigating the commit history and tracking changes. When in a "detached" state, HEAD points directly to a specific commit.

You use git stash in Git when you need to temporarily save changes in your working directory without committing them. This is typically done in scenarios where you want to switch to a different branch, pull changes from a remote repository, or perform some other operation that requires a clean working directory

Here are common situations when you should use git stash:

Switching Branches: When you're working on one branch and need to switch to another, but you have uncommitted changes in your working directory. Using git stash allows you to save those changes, switch branches, and then later apply the changes to the new branch.

git stash        # Save changes
git checkout another-branch   # Switch branches
git stash apply  # Apply saved changes to the new branch

Pulling or Fetching Changes: Before pulling or fetching changes from a remote repository, you can stash your local changes to ensure a clean working directory. This helps prevent conflicts that might arise when Git tries to merge the incoming changes with your local modifications.

git stash        # Save changes
git pull origin main   # Pull changes from the remote
git stash apply  # Apply saved changes to your working directory

Temporary Changes: If you're working on a feature but need to make a quick fix or test something unrelated, you can stash your current changes before making the temporary changes. Afterward, you can apply the stashed changes back.

git stash        # Save feature changes
# Make and test quick fix or unrelated changes
git stash apply  # Apply saved feature changes back

Resolving Conflicts: When resolving merge or rebase conflicts, git stash can help. You can stash your changes, then perform the merge or rebase. After resolving conflicts, you can apply your stashed changes again.

git stash        # Save changes
# Resolve conflicts during merge or rebase
git stash apply  # Apply saved changes after conflicts are resolved

git reset is a Git command used to move the HEAD and optionally the index (staging area) to a specified commit. It has different modes, including soft (moves HEAD only), mixed (default, moves HEAD and unstages changes), and hard (moves HEAD, unstages changes, and discards changes in the working directory). You can use it to unstage changes, move the branch pointer, undo commits, and amend the last commit. Use it carefully as it can affect commit history.

Here are the primary functions of git reset:

• Unstaging Changes
• Moving the HEAD
• Undoing Commits: git reset
• Mixed-Mode for Amend

• Git Fork: Creating a copy of a repository on a Git hosting platform, often for collaborative contributions.
• Git Clone: Creating a local copy of a Git repository from a remote, enabling local development.
• Git Branch: Creating separate lines of development within a repository, typically for features or bug fixes.

• git stash pop applies and removes the most recent stash.
• git stash apply applies the most recent stash but leaves it in the stash list for future use or reference.git stash pop applies and removes the most recent stash.

• Use git fetch to retrieve remote changes.
• Choose to merge with git merge or rebase with git rebase.
• Resolve conflicts if any.
• Optionally, push local changes with git push to update the remote repository.

• git reset --hard <commit>

• Use git rebase -i <commit>~1 to start an interactive rebase.
• Change "pick" to "edit" for the commit you want to amend.
• Make your changes and stage them with git add .
• Use git commit --amend to update the commit.
• Continue the rebase with git rebase --continue

git diff <commit1> <commit2>

• Use git rebase instead of git merge when you want to create a cleaner, linear commit history, squash commits, or integrate changes from one branch into another. Use git merge when preserving the branch's history is more important, especially in collaborative scenarios.

• Use git reflog to find the commit hash before the rebase.
• Run git reset --hard <commit-hash> to reset your branch to that commit.
• Optionally, force push to update the remote branch if necessary.

• Use git checkout <branch-name> to switch to your local branch.
• Run git fetch to get the latest changes from the remote repository.
• Choose either git merge main or git rebase main to integrate the updates (pick one based on your workflow).
• Resolve any conflicts if they arise during the merge or rebase.
• Test your branch thoroughly to ensure it works with the latest changes.
• Commit and push your changes if necessary (git commit and git push origin <branch-name>).

AWS (Amazon Web Services) is a cloud computing platform provided by Amazon. It offers a wide range of on-demand computing services and resources, such as servers, storage, databases, networking, and more, over the internet. AWS allows businesses and individuals to access and utilize these services without the need to own and manage physical hardware. It's commonly used for hosting websites, running applications, and storing data, offering scalability and flexibility to meet various computing needs.

Two AWS services for storing secrets securely are:

• AWS Secrets Manager: A service specifically designed for managing and rotating sensitive information like database passwords, API keys, and other credentials. It provides encryption, automated rotation, and access control for secrets.

• AWS Parameter Store: A service that allows you to store and manage configuration data, including secrets, in a hierarchical structure. It's often used for storing application configuration parameters and secrets in a secure manner.

• A Region is a geographical area that consists of multiple, isolated Availability Zones. AWS Regions are entirely separate from one another and are spread across the world to provide geographic diversity and redundancy.

• An Availability Zone (AZ) is a data center or facility within an AWS Region. Each Availability Zone is physically separate from the others and is designed to be isolated from failures in other Availability Zones within the same Region. This isolation ensures high availability and fault tolerance.

In summary, AWS Regions are composed of multiple Availability Zones. When you choose a Region for your resources, you're selecting a specific geographical location with multiple isolated data centers (Availability Zones) to host your services and data. This setup enables redundancy, scalability, and resilience for your applications and infrastructure.

• Auto-scaling is a cloud computing feature that automatically adjusts the number of resources (such as servers) allocated to your application based on real-time demand. It helps ensure that your application can handle varying levels of traffic efficiently by adding or removing resources as needed, thereby improving performance and cost-efficiency.

To minimize a Distributed Denial of Service (DDoS) attack on your infrastructure, you can use services like:

• AWS Shield: AWS Shield is a managed DDoS protection service that safeguards your applications against large-scale, sophisticated attacks.

• An AMI (Amazon Machine Image) is a pre-configured and templated virtual machine image used to create virtual servers (EC2 instances) in Amazon Web Services (AWS). It contains an operating system, software applications, and any custom configurations needed for your cloud-based servers. AMIs enable you to quickly launch and replicate server instances, making it easier to scale your infrastructure and deploy consistent computing environments.

There are three main types of load balancers:

• Application Load Balancer (ALB): ALBs operate at the application layer (Layer 7) and are ideal for routing HTTP and HTTPS traffic. They are capable of content-based routing, SSL termination, and support for container-based applications.

• Network Load Balancer (NLB): NLBs function at the transport layer (Layer 4) and are designed for handling TCP, UDP, and TLS traffic. They are highly performant and suitable for low-latency and high-throughput workloads.

• Classic Load Balancer (CLB): CLBs are the legacy load balancers in AWS, offering basic Layer 4 and Layer 7 load balancing capabilities. They are typically used for simple traffic distribution requirements.

Each type of load balancer has specific use cases and features, allowing you to choose the one that best suits your application's needs.

A VPC (Virtual Private Cloud) is a virtual network environment provided by Amazon Web Services (AWS). It allows you to create and configure a logically isolated section of the AWS cloud where you can launch AWS resources like virtual servers (EC2 instances), databases, and more.

Key features of a VPC include:

• Isolation: VPCs provide network isolation, allowing you to create private and public subnets to control access to resources.

• Custom IP Address Ranges: You can define your IP address range for the VPC, enabling you to design your network architecture.

• Security Groups and Network ACLs: These allow you to control inbound and outbound traffic to and from resources within the VPC.

• Connectivity Options: VPCs can be connected to other VPCs, on-premises networks, and the internet using various networking options.

• Subnets: VPCs are divided into subnets, each associated with a specific Availability Zone. Subnets are used to distribute resources and provide high availability.

In summary, a VPC is a fundamental networking component in AWS that lets you create a virtual network environment to host and manage your cloud-based resources with control over network architecture and security.

• Subnets are like separate neighborhoods within your cloud network. Each subnet has its own area of IP addresses and is isolated from the others. They're often placed in different parts of the cloud for extra safety, and you can control how traffic flows in and out of each subnet. This helps keep your cloud resources organized and secure.

• To allow a server to receive incoming traffic from the internet, you typically need to configure a security group (in AWS) or a firewall rule aka NACL (in general networking terms) to permit incoming traffic on the specific ports or protocols you want to allow. This enables your server to accept requests from the internet while still maintaining security by specifying which traffic is allowed.

To allow resources in your VPC to access the internet, you need to set up the following:

• Internet Gateway (IGW): Attach an Internet Gateway to your VPC. It acts as a bridge between your VPC and the internet.

• Route Table: Modify the route table associated with your subnets to include a route (0.0.0.0/0) pointing to the Internet Gateway.

• Elastic IP (EIP): For resources like EC2 instances that need a static public IP, allocate and associate an Elastic IP address.

With these configurations, resources in your VPC can send and receive traffic to and from the internet through the Internet Gateway while maintaining network security through security groups and network ACLs.

1. Presentation Layer (Web):

Step 1: Launch an Amazon EC2 instance for your web server. This instance will host your website or web application. Step 2: Configure security groups to allow incoming web traffic (HTTP/HTTPS) to the web server. Step 3: Optionally, attach an Elastic IP (EIP) for a static public IP address.

2. Application Layer (App):

Step 4: Launch another EC2 instance for your application server(s). This instance runs the business logic of your application. Step 5: Configure security groups to allow incoming traffic from the web server to the application server on the necessary ports. Step 6: Install and configure any middleware or application software required for your application.

3. Data Layer (Database):

Step 7: Create an Amazon RDS (Relational Database Service) instance or set up a database server (e.g., on EC2) for your database layer. Step 8: Configure security groups to allow incoming database connections only from the application server(s). Step 9: Create your database schema and tables, and configure database access and permissions.

• In a VPC with both private and public subnets, database servers should ideally be launched into the private subnets. Placing database servers in private subnets ensures that they are not directly accessible from the internet, which enhances security. Public subnets are typically used for resources that need to be accessible from the internet, like web servers.

• Use Security Groups: Configure security groups to control incoming and outgoing traffic to your EC2 instances. Only allow necessary ports and sources.

• Use Key Pairs: Authenticate access to your EC2 instances using key pairs (SSH keys for Linux or RDP keys for Windows) instead of passwords.

• Regular Updates: Keep your EC2 instances and their software up to date with security patches and updates.

• Use IAM Roles: Assign IAM roles to EC2 instances to grant them specific permissions, reducing the need for storing access keys on the instance.

• Enable Monitoring: Use Amazon CloudWatch to monitor performance and set up alarms for unusual activity or resource exhaustion.

• Data Encryption: Encrypt data at rest using services like Amazon EBS encryption and in-transit using SSL/TLS.

• Snapshot Backups: Create EBS snapshots and AMIs regularly to back up your instances, ensuring data recovery in case of failures.

• Instance Isolation: Separate instances into public and private subnets within a Virtual Private Cloud (VPC) for network isolation.

• Disable Root Access: Disable remote root login on Linux instances and use a sudo user for administrative tasks.

IAM Policies: Use fine-grained IAM policies to restrict access based on the principle of least privilege.

• Use Bastion Hosts: If necessary, employ a bastion host (jump server) to access private instances securely.

• Monitor Access: Monitor and audit access to your EC2 instances, including login attempts and user actions.

• Automate Security: Implement automation tools like AWS Systems Manager and AWS Config to enforce security policies.

To handle scaling for your web application with high traffic on Wednesdays and Fridays between 9 AM and 7 PM, you can:

• Schedule-Based Auto Scaling: Use AWS Auto Scaling's scheduled scaling feature. Set up a schedule to increase the desired number of instances during the peak hours on Wednesdays and Fridays and decrease it during off-peak hours.

• Target Tracking Scaling Policy: Create a target tracking scaling policy based on a metric like CPU utilization or request count per instance. Set the target to automatically adjust the number of instances to maintain a specific metric value. This can help handle traffic fluctuations efficiently.

By combining these approaches, your application can automatically adjust its capacity to meet demand, ensuring it scales up during peak times and scales down during quieter periods, optimizing cost and performance.

To automatically reduce the load on your Amazon EC2 instance when CPU utilization reaches 100 percent, follow these steps:

• Create an Auto Scaling Group: Set up an Auto Scaling Group for your EC2 instance if you haven't already.

• Create a Target Tracking Scaling Policy: Within the Auto Scaling Group configuration, create a Target Tracking Scaling Policy.

• Select CPU Utilization as the Metric: Choose CPU utilization as the metric to track.

• Set the Target Value: Specify the target CPU utilization level at which you want to take action, such as 80 or 90 percent, not 100 percent, to avoid any performance issues. AWS Auto Scaling will automatically adjust the number of instances to maintain this target value.

• Define Scaling Actions: Configure scaling actions for when the CPU utilization exceeds the target value. You can specify actions to increase or decrease the number of instances based on your requirements.

• Apply the Policy: Apply the Target Tracking Scaling Policy to your Auto Scaling Group.

Infrastructure as Code, or IaC, is the practice of automating the provisioning of your cloud resources through code, rather than manually on the console. It facilitates for better tracking of resources, and allows for infrastructure configurations to be replicated over various projects.

Terraform is one of many tools that fall under IaC. It'a used by engineers across the board as it's reusable, cloud agnostic and idempotent.

• Terraform is cloud-agnostic (it can be used with multiple cloud providers)
• CloudFormation is AWS-propietary
• Azure ARM is Azure-propietary

Terraform allows you to define what infrastructure you want. Ansible allows you to configure your infrastructure.

An example would be, using Terraform to create a VM, and using Ansible to install and run services within it.

In general terms, the Terraform state is a real-time description of all cloud infrastructure that has been created by terraform. The Terraform state however, branches into two:

• Current state: Description of all infrastructure created by Terrafrom in the present. Usually stored in .tfstate files.
• Desired state: Description of what you want to be created in the cloud. Stored in .tf files

Terraform will always match the current state to the desired state.

A local state is a state that is stored in your machine, whereas a remote state is a state that is stored somewhere in the cloud, like S3 Buckets on AWS or Azure Blob Storage on Azure.

• Use a local state when you're working independently on infrastructure.
• Use a remote state when collaborating as part of a team.

• terraform init: Initialises Terraform in our directory, installs provider plugins and configures our backend. This allows us to start working with Terraform.
• terraform plan: Compares our current & desired states and shows us what changes need to be made to match them
• terraform apply: Makes the changes to our current state to meet our desired state

The Terraform backend is effectively where our Terraform statefile (.tfstate is stored). The backend can either be local (on your local machine), or remote (S3, Azure blob .etc).

Terraform modules are resuable blocks of Terraform resources that are usually grouped by the services that they fall under. For example, when working with AWS, all of your networking-related resources may be created within a module named 'vpc' and all of your storage-related resources may be placed in an 's3' module.

Terraform providers are plugins that enable Terraform to make API calls to other services, such as AWS, Azure, GCP and CloudFlare.

• Create an import block with the resource id (for later versions of terraform, you can use the 'identity' attribute)
• Run terraform import <resource> (you can just run terraform apply for later versions of terraform)

terraform validate

terraform fmt --recursive

Terragrunt is a tool that falls under the umbrella of Terraform. It's purpose is to keep our Terraform code DRY, and is best-used when reusing Terraform configurations across multiple environments, such as desired states and backends.

Configure a remote backend with state-locking enabled.

You need to store your state remotely. Pipelines are ephemeral, so with a local state, each runner would have their own state, causing collisions and corruption due to re-creation attempts.

When a terraform plan or a terraform apply is run, terraform first acquires a state lock before reading and comparing state, which stops other engineers from making changes to the state. As soon as the plan/apply is done, the state lock is released and the state is free to be changed again.

Chekov is a security scanning tool that scans your desired state and checks for compliance with security best-practices.

Create output variables in the module you want to export data from, and define them in other modules.

Import our resources by either:

• Creating an import block with the resource id (for later versions, you can use the 'identity' attribute)
• Running terraform import <resource> (you can just run terraform apply for later versions of terraform)

Store all sensitive data in .tfvars files, and place them in .gitignore.

• Keep code DRY (Don't Repeat Yourself)
• Break up your Terraform configuration into reusable modules
• Keep statefiles hidden (.tfstate)

A container is a lightweight, portable way to package an application along with everything it needs to run, such as its code, libraries, and dependencies. Containers share the host operating system’s kernel but run in isolated environments, which makes them faster and more efficient than virtual machines. Key fundamentals of containers include isolation, portability, consistency across environments, and the ability to start and stop quickly.

A namespace wraps a global system resource in an abstraction that makes it appear to the processes within the namespace that they have their own isolated instance of the global resource. Changes to the global resource are visible to other processes that are members of the namespace, but are invisible to other processes. One use of namespaces is to implement containers.

Docker Compose is used for running and managing multi-container applications on a single machine, mainly for local development and testing. Docker Swarm and Kubernetes are used for orchestrating containers across multiple machines in production, handling scaling, load balancing, and high availability. Swarm is simpler to set up, while Kubernetes is more powerful and widely used for complex, large-scale systems.

A Dockerfile is used to define the steps needed to build a Docker image in a clear and repeatable way. It contains instructions such as which base image to use, how to install dependencies, copy application files, and configure how the container runs. This ensures the same image can be built consistently across different environments.

A Dockerfile is made up of instructions that describe how a Docker image should be built. Common components include FROM to define the base image, WORKDIR to set the working directory, COPY or ADD to include files, RUN to execute build commands, EXPOSE to document ports, and CMD or ENTRYPOINT to define how the container starts.

A container shares the host operating system’s kernel and runs as an isolated process, making it lightweight and fast to start. A virtual machine includes a full guest operating system on top of a hypervisor, which makes it heavier and slower to boot. Containers are more efficient for running applications, while virtual machines provide stronger isolation.

A container can be run by using a container image and starting it with a container runtime such as Docker. For example, the docker run command is used to create and start a container from an image, optionally exposing ports, setting environment variables, and mounting volumes. This allows the application inside the container to run in an isolated and controlled environment.

A running container can be stopped using the docker stop command, which safely shuts it down. Once stopped, the container can be removed with the docker rm command. This cleans up the container while leaving the original image unchanged.

You can attach a shell to a running container using the docker exec command. For example, docker exec -it < container_name_or_id > /bin/bash opens an interactive terminal inside the container. This allows you to inspect the container’s environment and run commands while it is running.

A dangling image is a Docker image that is no longer tagged and is not referenced by any container. These images are usually created during image rebuilds when old layers are left behind. They take up disk space and can be safely removed if they are no longer needed.

Docker Compose is a tool used to define and run multi-container applications using a single configuration file. It is mainly used for local development and testing, where you need multiple services, such as an application and a database, to run together. Docker Compose makes it easy to start, stop, and manage these containers as one unit.

Both COPY and ADD are used to add files into a Docker image, but COPY is simpler and more predictable. COPY only copies files and directories from the local filesystem into the image. ADD has extra features, such as extracting local tar files and downloading files from URLs, which can make behaviour less explicit, so COPY is generally recommended unless those extra features are needed.

At a lower level, containers work by using Linux kernel features to isolate and manage processes. Namespaces give containers their own view of system resources, such as processes, networking, and filesystems, while c-groups limit and control resource usage like CPU and memory. A container runtime then uses these features to run applications in isolated environments on the same host operating system.

In Docker, EXPOSE is used in a Dockerfile to document which ports the application listens on inside the container. It does not make the port accessible from outside the container by itself. Publish refers to mapping a container port to a host port using options like -p with docker run, which actually makes the service accessible externally.

RUN, CMD, and ENTRYPOINT serve different purposes in a Dockerfile. RUN executes commands at build time to create image layers, such as installing packages. CMD defines the default command that runs when a container starts and can be overridden. ENTRYPOINT sets the main executable for the container and is usually not overridden, making it useful for defining a fixed container behaviour.

No, limiting memory for a container does not reserve that memory by default. It sets a maximum amount the container is allowed to use, but the memory is only consumed when the application actually needs it. This helps prevent a container from using too much memory without wasting unused resources.

An orphaned volume is a Docker volume that is no longer used by any container but still exists on the host. These volumes can remain after containers are removed and continue to take up disk space. They can be removed manually with docker volume rm or cleaned up in bulk using docker volume prune.

Virtualisation works by using a hypervisor to create and manage virtual machines on a physical host. The hypervisor abstracts the underlying hardware, allowing each virtual machine to run its own full operating system as if it had dedicated resources. Hardware support, such as CPU virtualisation extensions, helps provide isolation and efficient resource sharing.

$ docker history --no-trunc <IMAGE_ID>

It is generally not ideal to run stateful applications in containers because containers are ephemeral and can be stopped or removed at any time. If stateful data is stored inside the container, it can be lost. Instead, it is best to use external storage, such as volumes or managed databases, to persist data while keeping the application container stateless.

Containers are lightweight but have some limitations compared with virtual machines. They share the host OS kernel, so they cannot run a different operating system. Containers offer weaker isolation, making them less secure in multi-tenant environments. They also rely on the host OS for compatibility and may not be suitable for applications requiring full OS features or legacy software.

When running containers in production, it’s best to keep them small and focused on a single service, use official or trusted images, and avoid running as root. Always manage secrets securely, use resource limits, and monitor container health. Regularly update images to patch vulnerabilities and consider orchestration tools like Kubernetes for scaling, load balancing, and high availability.

The difference is in when they execute. RUN executes commands at build time to create layers in the image, such as installing software. CMD defines the default command that runs when a container starts from the image and can be overridden at runtime. RUN affects the image; CMD affects the container.

Kubernetes is an open-source container orchestration platform used to manage, scale, and deploy containerised applications across multiple hosts. It automates tasks like scheduling, load balancing, rolling updates, and self-healing, ensuring applications run reliably and efficiently in production environments.

Kubernetes solves the challenges of running containerised applications at scale. It handles automated deployment, scaling, and management of containers across multiple hosts, provides load balancing, self-healing for failed containers, and simplifies networking and storage. This ensures applications remain available, resilient, and easy to maintain in production.

Docker is a platform for building, running, and managing individual containers, while Kubernetes (K8s) is an orchestration system for deploying and managing many containers across multiple hosts. Docker focuses on containerisation itself, whereas Kubernetes handles scaling, load balancing, and maintaining containerised applications in production.

In Kubernetes, the control plane manages the cluster and makes global decisions. Its core components include the API server (handles requests), etcd (stores cluster state), scheduler (assigns workloads to nodes), and controller manager (maintains desired state). The data plane runs workloads on nodes and includes the kubelet (ensures containers run), kube-proxy (handles networking), and the container runtime. The control plane directs the cluster, while the data plane executes workloads.

A Pod is the smallest deployable unit in Kubernetes and represents one or more containers that share the same network, storage, and lifecycle. Pods allow containers to communicate easily and manage resources together. They provide isolation, scheduling, and scaling, and are the basic building blocks for running applications in a Kubernetes cluster.

Containers within a pod communicate with each other using localhost networking because they share the same network namespace. They can also share volumes for file-based communication. This allows containers in the same pod to easily exchange data and coordinate their tasks.

A Kubernetes cluster is a set of machines (nodes) that run containerised applications under the control of the Kubernetes control plane. It includes master components that manage the cluster and worker nodes that run application workloads. The cluster provides scalability, load balancing, and high availability for applications.

A Deployment in Kubernetes is a resource that manages a set of Pods and ensures the desired number of replicas are running. It handles rolling updates, rollbacks, and scaling, making it easier to deploy and maintain applications reliably in a cluster.

A StatefulSet in Kubernetes manages stateful applications that require stable, unique network identities and persistent storage. Unlike Deployments, StatefulSets ensure Pods are created and deleted in a defined order and maintain their data across restarts, making them suitable for databases and other stateful services.

Pod-to-pod communication in a Kubernetes cluster can be restricted using Network Policies. These define rules specifying which Pods can communicate with each other or with external endpoints. By default, all Pods can communicate, so applying network policies allows you to enforce isolation and control traffic between Pods for security.

You can rollback a Kubernetes deployment using the kubectl rollout undo command. This restores the deployment to a previous revision, allowing you to quickly recover from failed updates or errors while keeping the desired number of Pods running.

Namespaces in Kubernetes are virtual clusters within a single physical cluster. They help organise and isolate resources, allowing multiple teams or applications to share the same cluster without interfering with each other. Namespaces also enable resource quotas and access control.

The kube-apiserver is the central component of the Kubernetes control plane. It exposes the Kubernetes API, validates and processes requests, and serves as the gateway for all interactions with the cluster. Other control plane components and users communicate with the cluster through the API server.

A full Kubernetes app deployment starts with writing the application code and building a container image, usually with Docker. The image is pushed to a container registry. Next, you create Kubernetes manifests, such as a Deployment and Service, defining how many Pods to run and how they are exposed. Using kubectl apply, the manifests are sent to the API server. The scheduler assigns Pods to nodes, kubelets pull the container image, and the containers start running. The Service exposes the app, allowing users or other Pods to access it. The Deployment ensures the desired state is maintained, handling scaling and updates automatically.

A simple Kubernetes cluster has a control plane and worker nodes. The control plane includes the API server (handles requests), etcd (stores cluster state), scheduler (assigns Pods to nodes), and controller manager (maintains desired state). Worker nodes run the application workloads and include the kubelet (manages containers), kube-proxy (handles networking), and the container runtime (like Docker or containerd). The control plane manages the cluster, while worker nodes execute the workloads.

If a master node fails in Kubernetes, the cluster’s control plane becomes unavailable, meaning no new Pods can be scheduled, and management operations cannot be processed. However, existing workloads on worker nodes continue to run. To prevent downtime, clusters often have high-availability setups with multiple master nodes so that if one fails, others can take over.

An Ingress controller in Kubernetes is a component that manages external access to services in a cluster, usually via HTTP or HTTPS. It watches Ingress resources and configures a load balancer or reverse proxy to route traffic to the correct service, enabling features like path-based routing, SSL termination, and virtual hosting.

A highly available (HA) Kubernetes cluster is built by running multiple master nodes across different failure zones. Each master node runs components like the API server, scheduler, and controller manager, often behind a load balancer to distribute requests. Etcd is also configured in a clustered, replicated setup. Worker nodes are spread across zones, ensuring workloads continue running if a node or zone fails.

etcd is a distributed key-value store used by Kubernetes to store all cluster state and configuration data. It holds information about Pods, Services, ConfigMaps, and more. The control plane reads from and writes to etcd to ensure the desired state of the cluster is maintained, making it a critical component for reliability and consistency.

Taints and tolerations in Kubernetes control which Pods can be scheduled on which nodes. A taint is applied to a node to repel certain Pods, while a toleration is applied to a Pod to allow it to be scheduled on nodes with matching taints. This helps isolate workloads, reserve nodes for specific purposes, and manage cluster resources effectively.

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

CI/CD solves the problem of unreliable and slow software delivery. In traditional development, teams integrate code late, rely heavily on manual testing, and treat releases as high-risk events. This often leads to last-minute failures, rollbacks, and delayed business value.

CI/CD introduces an automated and repeatable process where code changes are integrated early, validated through automated checks, and prepared for release continuously. This reduces integration issues, improves release confidence, and allows organisations to deliver features and fixes to customers faster while maintaining quality and stability.

Continuous Integration is the practice of frequently merging code changes into a shared version control system, usually several times a day. Each change triggers an automated process that builds the application and runs a defined set of tests.

The goal is to validate that the codebase remains in a working state at all times. By enforcing consistent formatting, build rules, and test execution through pipeline configuration, teams catch errors early and avoid large, difficult integrations later in the cycle.

Continuous Delivery means that every code change which passes the pipeline is automatically prepared for release. The application is packaged, tested, and deployed to environments such as staging in a consistent and repeatable way.

Releases become a business decision rather than a technical challenge. The codebase is always in a deployable state, and deploying to production is a controlled action, often triggered by an approval step rather than additional development work.

Continuous Deployment is an extension of Continuous Delivery where changes that pass all pipeline stages are deployed to production automatically.

This relies on strong test coverage, reliable pipeline syntax, clear environment configuration, and monitoring. Because deployments are frequent and incremental, failures are easier to detect and isolate. This approach is common in mature systems where rapid feedback and fast iteration are critical.

Automated testing provides the confidence required to release software frequently. Each test validates a specific aspect of the system, such as business logic, integration between services, or user workflows.

Tests are executed automatically as part of the pipeline using predefined scripts and configuration files. This ensures consistency, removes manual bottlenecks, and prevents regressions from reaching production. From a business standpoint, it reduces the risk of outages, protects customer trust, and lowers the cost of fixing defects.

A build is the process of converting source code into a deployable format. This may include compiling, resolving dependencies, running build scripts, and applying configuration.

A build artefact is the output of this process, such as a compiled binary, a package file, or a container image. Artefacts are versioned and stored so the same package can be promoted across environments, ensuring consistency between testing and production.

A CI/CD pipeline is an automated, repeatable workflow that takes source code from version control and delivers it into a running environment. It is usually defined as code using configuration files, commonly YAML, which allows the pipeline itself to be versioned, reviewed, and reused.

Typical stages include:

• Source: code checkout triggered by a commit or pull request
• Build: compilation and dependency resolution
• Static analysis: linting, formatting, and security or quality checks
• Test: automated unit, integration, and sometimes end-to-end tests
• Package: creation and versioning of build artefacts such as binaries or container images
• Deploy: automated deployment to staging or production environments
• Post-deployment: smoke tests, health checks, and monitoring validation

CI/CD pipelines enforce consistency, reduce manual errors, and provide visibility and traceability across the software delivery lifecycle.

When a pipeline fails, execution stops immediately and the failure is reported. This prevents invalid or unstable code from progressing to later stages such as deployment.

Failures are logged with clear output, allowing developers to identify issues such as test failures, syntax errors, misconfigured environment variables, or broken dependencies. Early failure is intentional and protects production systems while encouraging fast correction.

Git acts as the entry point for CI/CD. Events such as commits, pull requests, or merges trigger the pipeline automatically.

Branching strategies, commit history, and pull request reviews integrate directly with pipeline rules. This ensures that only code that meets defined quality checks and formatting standards can be merged and released. Git also provides traceability, making it easy to link deployments back to specific changes.

CI/CD reduces manual work and waiting time by automating validation and deployment steps. Code changes are small, well-tested, and consistently packaged, which makes them easier to release.

Because pipelines run on every change, feedback is immediate. Teams spend less time fixing late-stage issues and more time delivering value. Faster releases also mean quicker responses to customer feedback and changing business requirements.

CI/CD commonly uses multiple environments such as development, test, staging, and production. Each environment has its own configuration and purpose.

This separation allows teams to validate behaviour, configuration, and performance safely before exposing changes to users. It also ensures that environment-specific settings such as secrets, URLs, and scaling rules are managed correctly.

A deployment strategy defines how new application versions are rolled out to users. It focuses on availability, rollback capability, and risk control.

Different strategies balance speed and safety in different ways, allowing teams to align deployment behaviour with business priorities and system criticality.

Blue-green deployment uses two identical production environments. One serves live traffic while the other hosts the new version.

After validation, traffic is switched using a load balancer or routing rule. If issues arise, traffic can be switched back immediately. This approach minimises downtime and simplifies rollback.

A canary deployment releases a new version to a small portion of users first. Metrics such as error rates and performance are monitored before expanding the rollout.

This approach limits risk while providing real production feedback. If problems are detected, the rollout can be halted without affecting most users.

A rolling deployment updates instances gradually rather than all at once. Old and new versions run side by side during the rollout.

This avoids downtime and allows the system to remain available throughout the deployment. It is widely used because it balances simplicity, availability, and control.

From code commit to production, the CI/CD pipeline starts when a developer pushes code to the remote repository or opens a pull request, which automatically triggers the continuous integration (CI) process.

The pipeline first runs in the development environment, where the code is checked out, dependencies are resolved, and the application is built. Static checks such as linting and formatting are executed, followed by fast-running unit tests to validate the code in a development context.

If this stage succeeds, the pipeline packages the application into a versioned artefact, such as a binary or container image, and stores it in an artefact repository. This artefact is built once and then promoted unchanged through subsequent environments.

Next, as part of continuous delivery (CD), the artefact is deployed to the staging environment, which mirrors production as closely as possible. In staging, integration tests, smoke tests, and health checks are run to verify system behaviour and interactions with external services. Deployment strategies such as rolling or blue–green deployments are commonly used to reduce risk.

After successful validation in staging, and often following a manual approval step, the same artefact is deployed to the production environment. The deployment is monitored using logs, metrics, and alerts, and automated rollback mechanisms are in place if any issues are detected.

This pipeline enforces a clear separation between development, staging, and production environments while ensuring consistency, traceability, and a controlled release process from code commit to production.

When a CI pipeline fails during automated testing, the first step is to review the pipeline logs to identify which tests failed and understand the error messages. I would check whether the failure is due to a genuine code regression, a flaky test, or an environmental issue. Reproducing the failure locally or in a controlled test environment helps confirm the root cause. From a CI perspective, this situation demonstrates the value of early feedback and that the pipeline is doing its job by preventing defective code from progressing further in the delivery process. Rather than seeing the failure as a blocker, it should be treated as a safety mechanism that protects the shared codebase and reduces downstream risk. Once the issue is fixed, rerunning the pipeline ensures confidence that the change is safe to merge.

In a high-commit environment, an unstable main branch usually means changes are being integrated without enough automated validation. To address this, I would use CI/CD to introduce strong quality gates before code reaches the main branch. This starts with running automated builds and tests on every pull request so that issues are detected early, before merging.

I would also enforce branch protection rules that require the CI pipeline to pass and, if applicable, require peer reviews before merging. This prevents broken or incomplete changes from being integrated. Encouraging small, frequent commits helps reduce the risk of conflicts and makes failures easier to identify and fix.

From a collaboration standpoint, fast and reliable CI feedback is critical. Developers quickly see whether their change is safe, take ownership of fixing failures, and avoid blocking others. Overall, CI/CD helps keep the main branch in a continuously deployable state while improving team confidence and development velocity.

When a pipeline passes in CI but fails in staging, it usually indicates a difference between environments rather than a problem with the code itself. Common causes include missing or incorrect environment variables, misconfigured secrets, infrastructure differences, or deployment scripts that behave differently outside the CI environment.

To handle this, I would start by reviewing deployment and application logs in staging, then verify configuration values and infrastructure dependencies. I would also compare staging and CI environments to identify mismatches. This situation highlights why environment parity is important in CI/CD — staging should closely resemble production so issues are caught earlier. Improving configuration management and standardizing environments helps reduce these failures over time.

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

*Answer coming soon!

Data modeling is the process of creating a visual representation of either a whole information system or parts of it to communicate connections between data. Data modeling concepts create a blueprint for how data is organized and managed in your organization. Data models give developers and non-technical stakeholders a simplified way to have meaningful conversations about the needs of the business and how data insights can fuel better decision making.

• Star Schema
• Snowflake Schema
• Galaxy Schema

Entity models, relational and dimensional

A row in a database table is an entity. A column header of a database table is an attribute.

Normalization is the technique of dividing the data into multiple tables to reduce data redundancy and inconsistency and to achieve data integrity. On the other hand, Denormalization is the technique of combining the data into a single table to make data retrieval faster.

one to one, one to many and many to many

Snowflake and star are two different types of design schemas used in data warehousing. In a snowflake schema, the data is organized into a hierarchy of tables, with each table having multiple child tables. In a star schema, the data is organized into a central fact table and several dimension tables that connect to it.

A data mart is a subset of a larger data warehouse that is designed to serve a specific business function or department. It contains a smaller subset of the data found in the overall data warehouse.

Granularity refers to the level of detail or specificity of data. It describes how finely the data is divided and recorded.

Data sparcity can impact the aggregation of data sets/sources by making it more difficult to obtain accurate and meaningful results. Sparse data can result in incomplete or inaccurate analyses, as well as a loss of insights and trends.

Strong knowledge of data modelling and database design Expertise in database management systems (DBMS) and database administration Experience with data warehousing and business intelligence Proficiency in data integration, ETL (extract, transform, load) processes, and data migration Familiarity with programming languages and software development methodologies Excellent analytical and problem-solving skills Strong communication and collaboration abilities

Spark is another open-source software framework that is designed to handle big data processing tasks in real-time. Spark is built on top of Hadoop and provides a more flexible and efficient processing engine than MapReduce. It supports various data processing tasks, including batch processing, stream processing, machine learning, and graph processing. Spark is particularly useful for handling large datasets that require real-time analysis, such as financial trading data, social media data, and sensor data.

Relational database management systems (RDBMS) such as Oracle and SQL Server. NoSQL databases such as MongoDB and Cassandra. Data integration tools such as Informatica and Talend. Data visualization and business intelligence tools such as Tableau and Power BI. Design patterns such as the star schema and snowflake schema for data warehousing.

Explaining the reasons behind choosing data engineering... Data engineering means the process of designing, building, maintaining, and managing data architecture and infrastructure. It involves transforming data from different sources into a format that can be easily analyzed, processed, and stored.

Set up the new node with the same version of Hadoop as the existing nodes in the cluster.

Configure the Hadoop environment variables and networking settings on the new node to match the existing nodes.

Add the new node to the cluster's hosts file and update the DNS settings as needed.

Start the Hadoop services on the new node and ensure that it can communicate with the other nodes in the cluster.

Use the Hadoop command-line tools to add the new node to the cluster's configuration files, such as hdfs-site.xml and mapred-site.xml.

Restart the Hadoop services on the existing nodes in the cluster to ensure that they recognize the new node.

If the NameNode crashes or becomes unavailable, the HDFS becomes read-only until the NameNode is restored or replaced. During this time, no new data can be written to the HDFS, but existing data can still be read. To recover from a NameNode failure, the administrator can either restart the failed NameNode or replace it with a new one. In either case, the new NameNode must be initialized with a backup of the metadata stored in the secondary NameNode, which acts as a hot standby for the primary NameNode. Once the new NameNode is operational, it takes over the responsibility of managing the metadata of the HDFS, and the cluster can resume normal operations.

Kerberos authentication: Hadoop can integrate with Kerberos to provide secure authentication for users and services in the cluster. This ensures that only authorized users can access sensitive data and services.

Access control lists (ACLs): Hadoop supports ACLs, which allow administrators to control access to files and directories in the HDFS. ACLs can be used to grant or deny specific permissions to individual users or groups.

Encryption: Hadoop supports data encryption at rest and in transit. Data can be encrypted using industry-standard encryption algorithms like AES, and keys can be managed using key management services like Key Management Service (KMS).

Firewall and network security: Hadoop clusters should be protected by firewalls to prevent unauthorized access from outside the cluster. Network security measures like Virtual Private Network (VPN) can also be used to secure data transmission across the cluster.

Auditing and monitoring: Hadoop provides tools for auditing and monitoring cluster activities, which can help identify security breaches and anomalies in the system.

SELECT *

FROM customers

WHERE contact_name LIKE '%John%';

UNION: returns the combined results of two or more SELECT statements, removing duplicates. The number of columns and their data types must be the same in all SELECT statements.

MINUS (also known as EXCEPT in some versions of SQL): returns the rows from the first SELECT statement that are not present in the second SELECT statement.

INTERSECT: returns only the rows that are common to both SELECT statements.

These set operators can be useful in situations where you need to combine, subtract or compare data from multiple tables or queries.

INSERT INTO table_name (column1, column2, column3, ...)

VALUES (value1, value2, value3, ...);

In this syntax, "table_name" is the name of the table where data needs to be inserted, and "column1, column2, column3, ..." are the names of the columns where data needs to be inserted. "value1, value2, value3, ..." are the values that need to be inserted in the respective columns.

CONCAT: Used to concatenate two or more strings.

UPPER and LOWER: Used to convert a string to uppercase or lowercase respectively.

SUBSTRING: Used to extract a substring from a given string.

LENGTH: Used to get the length of a string.

TRIM: Used to remove leading or trailing spaces from a string.

REPLACE: Used to replace a substring within a string with a new substring.

The RANK() and DENSE_RANK() functions are used to assign a rank to each row in a result set based on the values in one or more columns. The main difference between the two functions is how they handle ties.

The RANK() function assigns the same rank to tied rows, and leaves gaps in the ranking sequence. For example, if two rows have the same value and are assigned rank 2, the next row will be assigned rank 4.

The DENSE_RANK() function, on the other hand, assigns the same rank to tied rows, but does not leave gaps in the ranking sequence. For example, if two rows have the same value and are assigned rank 2, the next row will be assigned rank 3.

Fields, also known as columns, are the individual pieces of data stored in a table. Each field has a name, a data type, and a value.

CREATE TABLE my_table (

column_1 datatype,

column_2 datatype,

column_3 datatype,

column_4 datatype

);

CASE

WHEN condition_1 THEN result_1

WHEN condition_2 THEN result_2

...

ELSE result_n

END

SQL databases are relational databases that store data in tables with fixed schemas. They use SQL as the query language to perform operations like CRUD (Create, Read, Update, Delete) on the data. SQL databases are known for their ability to handle complex queries and transactions, and for their strong consistency and ACID (Atomicity, Consistency, Isolation, Durability) properties. Examples of SQL databases include MySQL, Oracle, and PostgreSQL.

On the other hand, NoSQL databases are non-relational databases that store data in flexible schemas, such as key-value pairs, documents, or graphs. They typically use a query language other than SQL, such as JSON or MongoDB's query language, to retrieve and manipulate data. NoSQL databases are known for their scalability, high availability, and ability to handle unstructured and semi-structured data. However, they may sacrifice consistency and durability for performance and scalability. Examples of NoSQL databases include MongoDB, Cassandra, and Couchbase.