Improve devops questions formatting (#8015)

* refractor complete

* fix url

src/data/question-groups/devops/content/cicd-setup.md

@@ -1,7 +1,7 @@
 Setting up a CI/CD pipeline from scratch involves several steps. Assuming you’ve already set up your project on a version control system, and everyone in your team has proper access to it, then the next steps would help:
 
 1. **Set up the Continuous Integration (CI)**:
-- Select a continuous integration tool (there are many, like Jenkins, GitLab CI, CircleCI, pick one).
+- Select a continuous integration tool (there are many, like [Jenkins](https://jenkins.io), [GitLab CI](https://about.gitlab.com), [CircleCI](https://circleci.com), pick one).
 - Connect the CI tool to your version control system.
 - Write a build script that defines the build process, including steps like code checkout, dependency installation, compiling the code, and running tests.
 - Set up automated testing to run on every code commit or pull request.
@@ -18,7 +18,7 @@ Define deployment scripts that specify how to deploy your application to differe
 Remember that this system should be able to pull the artifacts from the continuous integration pipeline, so set up that access as well.
 
 4. **Infrastructure Setup**:
-- Provision infrastructure using IaC tools (e.g., Terraform, CloudFormation).
+- Provision infrastructure using IaC tools (e.g., [Terraform](https://terraform.io), [CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)).
 - Ensure environments are consistent and reproducible to reduce times if there is a need to create new ones or destroy and recreate existing ones. This should be as easy as executing a command without any human intervention.
 
 5. **Set up your monitoring and logging solutions**:

src/data/question-groups/devops/content/docker-compose.md

@@ -1,4 +1,4 @@
-Docker Compose is, in fact, a tool designed to simplify the definition and management of multi-container Docker applications. It allows you to define, configure, and run multiple containers as a single service using a single YAML file.
+[Docker Compose](https://docs.docker.com/compose/) is, in fact, a tool designed to simplify the definition and management of multi-container Docker applications. It allows you to define, configure, and run multiple containers as a single service using a single YAML file.
 
 In a multi-container application, Compose provides the following key roles:
 

src/data/question-groups/devops/content/health-monitor.md

@@ -5,5 +5,5 @@ Each DevOps team should define this list within the context of their own project
 3. **Deployment Frequency**: How often deployments occur. Frequent deployments indicate a smooth pipeline, while long gaps may signal issues with your CI/CD or with the actual dev workflow.
 4. **Lead Time for Changes**: The time from code commit to production deployment. Shorter lead times are preferable, indicating an efficient pipeline.
 5. **Mean Time to Recovery (MTTR)**: The average time it takes to recover from a failure. A lower MTTR indicates a resilient pipeline that can quickly address and fix issues.
-6. **Test Coverage and Success Rate**: The percentage of code covered by automated tests and the success rate of those tests. High coverage and success rates are good indicators of better quality and reliability. 
+6. **Test Coverage and Success Rate**: The percentage of code covered by automated tests and the success rate of those tests. High coverage and success rates are good indicators of better quality and reliability.
 7. **Change Failure Rate**: The percentage of deployments that result in failures. A lower change failure rate indicates a stable and reliable deployment process.

src/data/question-groups/devops/content/microservice-challenges.md

@@ -1,10 +1,10 @@
-While in theory microservices can solve all platform problems, in practice there are several challenges that you might encounter along the way. 
+While in theory microservices can solve all platform problems, in practice there are several challenges that you might encounter along the way.
 
 Some examples are:
 
 1. **Complexity**: Managing multiple services increases the overall system complexity, making development, deployment, and monitoring more challenging (as there are more “moving parts”).
 2. **Service Communication**: Ensuring reliable communication between services, handling network latency, and dealing with issues like service discovery and API versioning can be difficult. There are of course alternatives to deal with all of these issues, but they’re not evident right off the bat nor the same for everyone.
-3. **Data Management**: It’s all about trade-offs in the world of distributed computing. Managing data consistency and transactions across distributed services is complex, often requiring techniques like eventual consistency and distributed databases. 
+3. **Data Management**: It’s all about trade-offs in the world of distributed computing. Managing data consistency and transactions across distributed services is complex, often requiring techniques like eventual consistency and distributed databases.
 4. **Deployment Overhead**: Coordinating the deployment of multiple services, especially when they have interdependencies, can lead to more complex CI/CD pipelines.
 5. **Monitoring and Debugging**: Troubleshooting issues is harder in a microservices architecture due to the distributed nature of the system. Trying to figure out where the information goes and which services are involved in a single request can be quite a challenge for large platforms. This makes debugging microservices architecture a real headache.
 6. **Security**: Securing microservices involves managing authentication, authorization, and data protection across multiple services, often with varying security requirements.

src/data/question-groups/devops/content/popular-cicd-tools.md

@@ -14,6 +14,7 @@ These tools allow you to install them on your own infrastructure and don’t req
 On the other hand, these tools either require you to use them from the cloud or are only accessible in SaaS format, which means they provide the infrastructure, and you just use their services.
 
 Some examples of these tools are:
+
 - CircleCI
 - Travis CI
 - GitLab CI/CD (cloud version)

src/data/question-groups/devops/devops.md

@@ -232,13 +232,15 @@ Either way, DevOps engineers work between the development and operations teams,
 
 Because of this strange situation, while detailed roadmaps (be sure to check out our [DevOps roadmap](https://roadmap.sh/devops)!) help a lot, getting ready for a DevOps interview requires a lot of work.
 
+Lastly, Checkout our Devops [Projects](https://roadmap.sh/devops/projects) to test your real world knowledge.
+
 Here are the most relevant DevOps interview questions you’ll likely get asked during a DevOps interview, plus a few more that will push your skills to the next level.
 
 ## Preparing for your DevOps interview
 
 Before diving into your DevOps technical interview, keep these key points in mind:
 
-1.  **Understand the core concepts**: Familiarize yourself with the essentials of DevOps practices, including continuous integration/continuous deployment (CI/CD), infrastructure as code (IaC), the software development lifecycle, and containerization. Understand how these concepts contribute to the overall development lifecycle.
+1. **Understand the core concepts**: Familiarize yourself with the essentials of DevOps practices, including continuous integration/continuous deployment (CI/CD), infrastructure as code (IaC), the software development lifecycle, and containerization. Understand how these concepts contribute to the overall development lifecycle.
 2. **Practice hands-on skills**: There is a lot of practical knowledge involved in the DevOps practice, so make sure you try what you read about. Set up some CI/CD pipelines for your pet projects, understand containerization, and pick a tool to get started. The more you practice, the more prepared you’ll be for real-world problems.
 3. **Study software architecture**: While you may not have the responsibilities of an architect, having a solid understanding of software architecture principles can be a huge help. Being able to discuss the different components of a system with architects would make you a huge asset to any team.
 4. **Research the Company**: In general, it’s always a great idea to research the company you’re interviewing for. In this case, investigate the company’s DevOps practices, the technologies they use, and their overall approach to software development. This will help you demonstrate a genuine interest in their operations and come prepared with thoughtful questions.