DevOps Most Asked Real Time Interview Question And Answer - Set 2

"In the world of DevOps, communication and collaboration are as critical as code and infrastructure."{alertInfo}

Image From FreePik

{tocify} $title={Table of Contents}

Question 26: How to migrate large data from one S3 bucket to another S3 bucket?

One efficient way to migrate large data between S3 buckets is by utilizing AWS CLI commands or SDKs. You can use commands like aws s3 sync or aws s3 cp to copy data between buckets. These commands support multi-threaded transfers, which can expedite the migration process significantly. Additionally, you can leverage AWS DataSync or third-party tools like AWS Transfer Family or AWS Snowball for large-scale data migrations with minimal downtime.

Question 27: I need one EC2 instance only for 1 hr. daily basis, so which instance types or options you will choose to give me daily basis?

For your requirement of a short-lived EC2 instance, I would suggest considering EC2 Spot Instances or utilizing AWS Lambda if your workload can be executed in a serverless environment. EC2 Spot Instances allow you to bid on unused EC2 capacity, often available at significantly lower prices compared to On-Demand instances. This can be cost-effective for short-duration workloads. Alternatively, AWS Lambda is suitable for event-driven, short-duration tasks, where you only pay for the compute time consumed. Depending on your specific workload requirements and budget considerations, either option could be suitable.

Question 28: How load balancer works? What are the algorithms?

Load balancers distribute incoming application or network traffic across multiple targets, such as EC2 instances, containers, or IP addresses, in multiple Availability Zones. This helps to ensure that no single resource becomes overwhelmed, optimizing performance and reliability. Load balancers can operate at various layers of the OSI model, including application layer (Layer 7), transport layer (Layer 4), or network layer (Layer 3), depending on the type of load balancer.

There are several load balancing algorithms used to determine how traffic is distributed:

1. Round Robin: Requests are distributed evenly across the available targets in a circular manner.
2. Least Connections: Traffic is directed to the target with the fewest active connections.
3. IP Hash: The source IP address of the client is used to determine which target receives the request, ensuring that requests from the same client are consistently routed to the same target.
4. Least Response Time: Traffic is directed to the target with the lowest average response time, based on historical data.
5. Weighted Round Robin: Similar to Round Robin, but with the ability to assign weights to targets, influencing the distribution of traffic.

These algorithms help load balancers efficiently distribute incoming traffic based on various factors, optimizing performance and resource utilization.

Question 29: What is the control tower and landing zone?

AWS Control Tower is a service that provides the easiest way to set up and govern a secure, multi-account AWS environment based on AWS best practices. It automates the setup of a new baseline multi-account AWS environment, called a Landing Zone, which includes identity and access management, federated login, network design, and security baseline configuration. Control Tower simplifies the process of creating and managing AWS accounts in a centralized manner, making it easier to enforce policies and compliance across the organization.

Question 30: How to check server logs?

Server logs can be checked using various commands and tools depending on the operating system and logging mechanism in use. In Linux-based systems, logs are typically stored in the /var/log directory. You can use commands like cat, tail, less, or grep to view and search through log files. For example, tail -f /var/log/syslog can be used to continuously monitor system log messages as they are written to the file. Additionally, tools like journalctl are available for viewing systemd journal logs.

Question 31: If server performance suddenly slows, what steps or actions do we need to follow to resolve this issue?

When server performance suddenly slows down, it's essential to troubleshoot the issue systematically. Some steps to follow include:

• Check CPU, memory, and disk utilization using monitoring tools like CloudWatch or system commands such as top, vmstat, or iostat.
• Review system logs and application logs for any errors or warning messages that could indicate the cause of performance degradation.
• Identify any recent changes or updates that may have contributed to the slowdown.
• Perform a thorough analysis of the running processes to identify any resource-intensive applications or services.
• Consider scaling up resources temporarily if the slowdown is due to resource exhaustion.
• Implement performance optimizations such as caching, indexing, or code optimizations as needed.
• Monitor the impact of changes and continue to investigate until the performance issue is resolved satisfactorily.

Question 32: Let’s say you have a Linux machine, and it has 20 GB of storage. But it’s got full as all space has been used by log files. You have deleted log files but still disk space showing full. How to fix that?

After deleting log files, if disk space is still showing full, it's likely that the files are still being held open by the processes that write to them. In such cases, you can use the lsof command to identify the processes that are holding the deleted files open and then restart or stop those processes to release the disk space. Here's how you can do it:

sudo lsof | grep deleted{codeBox}

This command will list the open files that have been deleted. Once you identify the processes, you can either restart them or use the kill command to stop them gracefully. After stopping the processes, the disk space should be released, and you should see the correct available disk space.

Question 33: How to check which installed service is running on which port using a command?

You can use the netstat command to check which services are running on which ports. Here's how you can do it:

netstat -tuln{codeBox}

This command will display a list of all listening (-l) TCP (-t) and UDP (-u) ports, along with the associated process IDs (PIDs) and the names of the programs that opened them.

Question 34: I am not able to log in to my EC2 machine. How to check what could be the reason and how to fix it?

If you're unable to log in to your EC2 instance, several reasons could be causing the issue. Here are some troubleshooting steps you can take:

• Verify that the EC2 instance is running and reachable over the network.
• Check the security group and network ACL settings to ensure that inbound traffic on the SSH (port 22) or RDP (port 3389) ports is allowed.
• Verify that you're using the correct SSH key pair (for Linux instances) or password (for Windows instances) to authenticate.
• Check the system logs (such as /var/log/messages for Linux or Event Viewer for Windows) for any errors or warnings related to the login process.
• If you suspect that the SSH daemon (sshd) or RDP service is not running, you may need to restart them or troubleshoot further.
• If necessary, you can access the instance using the EC2 Instance Connect feature or by attaching the instance's root volume to another instance for troubleshooting.

Question 35: What is the best Git branching strategy?

The best Git branching strategy often depends on the specific needs and workflows of your project. However, one commonly recommended branching strategy is the Git Flow model, which involves the following branches:

• Master: Represents the stable production-ready code.
• Develop: Integration branch where all features are merged before being released to production.
• Feature: Branches created for developing new features, which are then merged into the develop branch.
• Release: Branches created for preparing releases, where final testing and bug fixes are performed before merging into master and tagged for release.
• Hotfix: Branches created to address critical issues in the production code, which are then merged into both master and develop branches.

This model provides a structured approach to development, ensuring that new features are thoroughly tested before being released and that production code remains stable.

Question 36: Git Commands

Git offers a wide range of commands to manage version control. Some essential Git commands include:

• git init: Initialize a new Git repository.
• git clone: Clone an existing repository into a new directory.
• git add: Add file contents to the index (staging area) for the next commit.
• git commit: Record changes to the repository.
• git push: Upload local repository content to a remote repository.
• git pull: Fetch from and integrate with another repository or a local branch.
• git branch: List, create, or delete branches.
• git checkout: Switch branches or restore working tree files.
• git merge: Join two or more development histories together.
• git status: Show the status of files in the working directory.

These are just a few examples of Git commands. There are many more commands available for various version control tasks.

Question 37: How to resolve Git merge conflicts?

Git merge conflicts occur when Git cannot automatically merge changes from different branches. To resolve merge conflicts, follow these steps:

• Identify which files have conflicts using git status or a Git GUI tool.
• Open the conflicted files in a text editor and locate the conflict markers (<<<<<<<, =======, >>>>>>>).
• Edit the conflicted files to resolve the conflicting changes manually, keeping the desired changes and removing the conflict markers.
• Save the resolved files.
• Add the resolved files to the staging area using git add.
• Commit the changes to complete the merge using git commit.

After resolving merge conflicts, the merge commit will be created, and the branches will be successfully merged.

Question 38: Explain Git troubleshooting.

Git troubleshooting involves identifying and resolving common issues that may arise during version control operations. Some common Git troubleshooting scenarios include resolving merge conflicts, recovering from accidental commits or deletions, dealing with corrupted repositories, and diagnosing connectivity or authentication issues with remote repositories. Git provides various commands and techniques for troubleshooting, such as using git status, git log, git reflog, git reset, git checkout, git revert, git bisect, and more. Additionally, online resources, forums, and Git community support can be valuable sources of information for resolving complex Git problems.

Question 39: Differences between Git rebase and Git merge?

Git rebase and Git merge are two different ways of integrating changes from one branch into another:

• Git Merge: Incorporates changes from one branch into another by creating a new merge commit. It preserves the commit history of both branches but can result in a more cluttered history, especially in long-running feature branches.
• Git Rebase: Moves the entire feature branch to begin on the tip of another branch. It rewrites the commit history, resulting in a linear history without merge commits. This can create a cleaner and more linear history but may lead to conflicts if the rebased commits conflict with changes in the target branch.

In summary, Git merge preserves the original commit history and is suitable for preserving context in long-lived branches, while Git rebase creates a cleaner, linear history but can result in a more disruptive history rewrite.

Question 40: If a file is suddenly deleted in Git, how do you get it back?

If a file is accidentally deleted in Git, you can recover it using the following steps:

• Use git log -- <file_path> to identify the commit where the file was deleted.
• Checkout the commit before the deletion using git checkout <commit_hash>^ -- <file_path>, where <commit_hash> is the hash of the commit before deletion.
• After restoring the file, you can commit the changes to save the file's recovery.

Alternatively, if the file was deleted in the most recent commit and not yet pushed to a remote repository, you can use git reset HEAD~1 to undo the last commit while keeping the changes in the working directory. Then you can use git checkout -- <file_path> to restore the deleted file from the working directory.

Question 41: Differences between git pull and git fetch.

• git pull: Fetches changes from the remote repository and merges them into the current branch. It is a combination of git fetch followed by git merge. It updates the current branch with the latest changes from the remote repository and incorporates them into the working directory.
• git fetch: Fetches changes from the remote repository to the local repository without merging them into the working directory. It updates the remote tracking branches but does not affect the local branches. After fetching, you can review the changes using git log or other commands and decide how to integrate them into your local branches.

In summary, git pull automatically merges fetched changes into the current branch, while git fetch only updates the remote tracking branches and requires an additional step to integrate the changes manually.

Question 42: What is the difference between Git and GitHub?

Git is a distributed version control system (DVCS) used for tracking changes in source code during software development. It provides features for branching

Question 43: What are some of the key benefits of using Git for version control?

• Distributed Version Control: Git is a distributed version control system, allowing every developer to have a complete copy of the repository. This enables offline work and provides redundancy.
• Branching and Merging: Git makes it easy to create branches for feature development or experimentation and merge them back into the main codebase.
• Lightweight and Fast: Git is designed to be lightweight and fast, enabling quick branching, committing, and merging operations, even with large repositories.
• Data Integrity: Git uses cryptographic hashing to ensure the integrity of data, providing strong protection against data corruption and unauthorized changes.
• Collaboration: Git facilitates collaboration among developers by providing features like remote repositories, pull requests, and code reviews.
• Flexibility: Git is flexible and can be used in various workflows, from small personal projects to large enterprise-level development teams.

Question 44: What is a webhook?

A webhook is a mechanism for automatically triggering actions in response to events that occur elsewhere. In the context of software development and continuous integration/continuous deployment (CI/CD), webhooks are often used to notify external systems, such as CI servers or deployment tools, about events like code commits, pull requests, or issue updates. When a specified event occurs, the webhook sends an HTTP POST request to a predefined URL, containing information about the event. This allows external systems to respond to events in real-time, automating various tasks and integrations in the software development lifecycle.

Question 45: What is the difference between a freestyle project and a declarative pipeline?

• Freestyle Project: A freestyle project is a flexible project type in Jenkins that allows users to configure build steps and post-build actions using a graphical user interface (GUI). Users can define build steps, triggers, source code management, and other configurations using a wide range of plugins available in Jenkins. Freestyle projects offer great flexibility but may lead to complex configurations for more advanced workflows.
• Declarative Pipeline: A declarative pipeline is a more structured and script-like approach for defining Jenkins pipelines as code. It uses a simplified and opinionated syntax to define pipelines in a more concise and readable manner. Declarative pipelines follow a predefined structure and provide built-in support for defining stages, steps, post-actions, and error handling. They promote best practices and enforce stricter syntax rules, making them easier to maintain and understand, especially for teams new to Jenkins pipelines.

Question 46: What is multi-stage deployment?

Multi-stage deployment, also known as multi-environment deployment or progressive deployment, is a deployment strategy where changes to a software application are rolled out gradually across multiple environments, such as development, testing, staging, and production. Each stage represents a different environment with its own set of configurations, dependencies, and testing criteria.

This deployment strategy typically involves promoting changes from one stage to the next only after successful testing and validation in the previous stage. It allows for early detection of issues and reduces the risk of deploying faulty changes to production. Multi-stage deployment is often implemented using automated deployment pipelines, where each stage represents a sequential step in the deployment process.

Question 47: How to check deployment logs?

To check deployment logs, you typically need access to the logging infrastructure of your deployment environment. The specific method for accessing deployment logs may vary depending on the deployment platform and tools used.

In many cases, deployment tools and platforms provide built-in logging capabilities or integrate with external logging services like Elasticsearch, Logstash, and Kibana (ELK stack) or Splunk. You can access deployment logs through web interfaces, command-line tools, or APIs provided by these logging services.

Additionally, if you're using deployment automation tools like Jenkins, GitLab CI/CD, or AWS CodeDeploy, deployment logs are often accessible within the respective job or deployment execution history.

Question 48: If my deployment fails, how do I check logs and fix it?

If your deployment fails, follow these steps to check logs and troubleshoot the issue:

• Check Deployment Logs: Access the logs generated during the deployment process to identify the cause of the failure. Look for error messages, stack traces, or any other relevant information that can help diagnose the problem.
• Review Configuration: Verify the deployment configuration, including environment variables, dependencies, and settings. Ensure that all required configurations are correct and up to date.
• Analyze Error Messages: Analyze any error messages or exceptions encountered during the deployment process. Look for specific error codes or descriptions that can provide insights into the root cause of the failure.
• Rollback Changes: If necessary, consider rolling back the deployment to a previous stable version to restore service functionality while investigating the issue further.
• Debug and Test: Debug the deployment script or configuration to identify and fix the underlying issue. Test the deployment process in a controlled environment to verify that the changes are applied correctly.
• Document and Communicate: Document the troubleshooting steps taken and the resolution applied. Communicate with stakeholders, including team members and users, to provide updates on the status of the deployment and any actions taken to address the issue.

Question 49: If my Jenkins server crashes, how do I recover it?

If your Jenkins server crashes, follow these steps to recover it:

• Identify the Cause: Determine the root cause of the Jenkins server crash by analyzing system logs, error messages, and any other available diagnostic information.
• Restart Jenkins Service: Attempt to restart the Jenkins service or container to see if it can be brought back online. Use the appropriate commands or tools for your deployment environment.
• Restore from Backup: If restarting the Jenkins service does not resolve the issue or if data loss has occurred, restore Jenkins from a backup. Ensure that you have regular backups of your Jenkins configuration, jobs, and data to facilitate recovery in such situations.
• Reinstall Jenkins: As a last resort, if restoring from backup is not feasible or if the Jenkins installation is corrupted beyond repair, consider reinstalling Jenkins from scratch. Follow the installation instructions for your operating system or deployment platform to perform a fresh installation of Jenkins.
• Verify Data Integrity: After recovering Jenkins, verify the integrity of your configuration, jobs, and data to ensure that everything is restored correctly. Test critical functionality to confirm that Jenkins is functioning as expected.
• Implement Preventive Measures: Take proactive measures to prevent future Jenkins server crashes, such as monitoring system resources, applying software updates and patches, implementing redundancy and failover mechanisms, and maintaining regular backups of Jenkins data.

Question 50: What is Jenkins master-slave architecture?

Jenkins master-slave architecture, also known as Jenkins distributed build architecture, is a setup where a single Jenkins master instance delegates build tasks to multiple Jenkins slave nodes for parallel execution. In this architecture:

• Jenkins Master: The Jenkins master is the central server that manages the entire Jenkins environment, including job scheduling, monitoring, and reporting. The master node coordinates build execution, distributes build tasks to slave nodes, and collects build results.
• Jenkins Slave: Jenkins slave nodes are individual compute instances that perform build tasks delegated by the master node. Slave nodes can be physical or virtual machines, containers, or cloud instances. Each slave node connects to the master node over a network connection and runs build jobs assigned to it.

The master-slave architecture enables distributed and parallelized build execution, improving build throughput, resource utilization, and scalability. Slave nodes can be configured with different operating systems, environments, and tools to accommodate diverse build requirements. Additionally, slave nodes can be dynamically provisioned and scaled based on workload demands, providing flexibility and efficiency in resource allocation.

Read QnA Set 1  (1-25 ) -  DevOps Most Asked Real Time Interview Question And Answer - Set 1{alertSuccess}

 Read QnA Set 3  (51 - 75 )  - DevOps Most Asked Real Time Interview Question And Answer - Set 3{alertSuccess}

Read QnA Set 4  (76 - 100 ) -  DevOps Most Asked Real Time Interview Question And Answer - Set 1{alertSuccess}