<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Module 2 on Ghafoor's Personal Blog</title><link>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/</link><description>Recent content in Module 2 on Ghafoor's Personal Blog</description><generator>Hugo</generator><language>en</language><managingEditor>noreply@example.com (AG Sayyed)</managingEditor><webMaster>noreply@example.com (AG Sayyed)</webMaster><copyright>Copyright © 2024-2026 AG Sayyed. All Rights Reserved.</copyright><atom:link href="http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/index.xml" rel="self" type="application/rss+xml"/><item><title>Module-2 Multiple Choice Questions</title><link>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/009-module-mcq/</link><pubDate>Sun, 30 Mar 2025 02:24:15 +0000</pubDate><author>noreply@example.com (AG Sayyed)</author><guid>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/009-module-mcq/</guid><description>&lt;h2 id="module-2-multiple-choice-questions"&gt;Module-2 Multiple Choice Questions&lt;/h2&gt;

 

&lt;div class="accordion" id="mcqAccordion"&gt;
 &lt;div class="accordion-item"&gt;
 &lt;h2 class="accordion-header" id="headingOne"&gt;
 &lt;button
 class="accordion-button collapsed"
 type="button"
 data-bs-toggle="collapse"
 data-bs-target="#collapseOne"
 aria-expanded="false"
 aria-controls="collapseOne"&gt;
 Multiple Choice Questions And Answers
 &lt;/button&gt;
 &lt;/h2&gt;
 &lt;div
 id="collapseOne"
 class="accordion-collapse collapse"
 aria-labelledby="headingOne"
 data-bs-parent="#mcqAccordion"&gt;
 &lt;div class="accordion-body"&gt;
 &lt;div class="progress"&gt;
 &lt;div
 id="progress-bar"
 class="progress-bar"
 role="progressbar"
 style="width: 0%;"
 aria-valuenow="0"
 aria-valuemin="0"
 aria-valuemax="100"&gt;&lt;/div&gt;
 &lt;/div&gt;

 &lt;div id="mcq-container"&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. To foster collaboration and code reuse by making repositories public within an organization."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best explains the primary goal of social coding?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. To restrict access to repositories within an organization.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. To foster collaboration and code reuse by making repositories public within an organization.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. To eliminate the need for code reviews.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. To replace pair programming with automated tools.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="3. Wasted resources due to reinventing solutions."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What is the most likely outcome if an organization does not adopt social coding principles?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Increased collaboration among teams.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Reduced duplication of code.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Wasted resources due to reinventing solutions.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Improved code quality through pair programming.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="4. Restricting access to repositories to maintain control."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is NOT a benefit of social coding?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Encouraging contributions from all team members.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Promoting code reuse and reducing duplication.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Allowing teams to leverage existing functionality.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Restricting access to repositories to maintain control.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Discuss the feature, open an issue, fork the repository, implement changes, and submit a pull request."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best describes the workflow in social coding?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Discuss the feature, open an issue, fork the repository, implement changes, and submit a pull request.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Directly push changes to the main branch without review.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Create a private repository for each feature and merge changes without collaboration.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Use pair programming exclusively for all development tasks.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Improved code quality and skill transfer between team members."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What is the most likely outcome of implementing pair programming in a team?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Reduced code quality due to lack of collaboration.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Improved code quality and skill transfer between team members.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Increased reliance on individual contributors.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Slower development cycles due to constant role switching.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="4. It eliminates the need for code reviews."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is incorrect about pair programming?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. It involves two programmers sharing a single workstation.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. One acts as the driver while the other acts as the navigator.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Roles are swapped periodically to ensure balanced participation.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. It eliminates the need for code reviews.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="3. Enhanced code reuse and shared responsibility."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is most likely to be a benefit of making repositories public within an organization?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Increased duplication of code.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Reduced collaboration among teams.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Enhanced code reuse and shared responsibility.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Restricted access to existing functionality.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Whether repositories are public within the organization."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following should be checked first when adopting social coding principles?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Whether repositories are public within the organization.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. The number of private repositories in use.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. The frequency of pair programming sessions.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. The availability of automated testing tools.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. To track changes in code and enable collaboration among team members."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best explains the importance of version control in DevOps?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. To track changes in code and enable collaboration among team members.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. To eliminate the need for automated testing.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. To restrict access to repositories for security purposes.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. To replace CI/CD pipelines with manual deployments.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Creating systems that can detect and recover quickly from failures."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best explains the concept of designing for failure?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Avoiding failures completely in distributed systems.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Creating systems that can detect and recover quickly from failures.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Focusing on debugging failures instead of recovery.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Eliminating the need for resilience patterns.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="3. Increased risk of cascading failures."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What is the most likely outcome if a distributed system does not implement resilience patterns?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Improved system reliability.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Faster recovery from failures.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Increased risk of cascading failures.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Reduced need for monitoring.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="4. Monolithic architecture."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is NOT a resilience pattern discussed in designing for failure?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Retry pattern.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Circuit breaker pattern.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Bulkhead pattern.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Monolithic architecture.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. It handles temporary failures by retrying operations with exponential backoff."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best describes the retry pattern?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. It prevents failures by avoiding retries.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. It handles temporary failures by retrying operations with exponential backoff.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. It isolates services to prevent cascading failures.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. It stops calling a failing service after multiple retries.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. To stop calling a failing service and prevent cascading failures."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What is the primary purpose of the circuit breaker pattern?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. To retry failed operations indefinitely.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. To stop calling a failing service and prevent cascading failures.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. To isolate services into separate containers.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. To replace failing services with new instances.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="4. It eliminates the need for retries in distributed systems."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is incorrect about the bulkhead pattern?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. It isolates services to prevent failures from spreading.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. It uses separate thread pools for different services.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. It ensures that failures in one service do not affect others.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. It eliminates the need for retries in distributed systems.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Identifying weaknesses in the system before they affect real users."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is most likely to be a benefit of chaos engineering?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Identifying weaknesses in the system before they affect real users.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Eliminating the need for resilience patterns.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Preventing all failures in distributed systems.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Reducing the need for automated recovery mechanisms.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Whether the system can recover quickly from failures."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following should be checked first when designing for failure?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Whether the system can recover quickly from failures.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. The number of retries allowed for failed operations.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. The availability of chaos engineering tools.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. The frequency of system failures.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Increased risk of deployment errors and delays."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What is the most likely outcome if a team does not use CI/CD pipelines?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Faster deployment cycles.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Increased risk of deployment errors and delays.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Improved collaboration among team members.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Reduced need for automated testing.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Applications designed as small, independent, and stateless services."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best explains the concept of cloud native microservices?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Applications built as tightly coupled components.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Applications designed as small, independent, and stateless services.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Applications that rely solely on monolithic architectures.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Applications that avoid using REST APIs for communication.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Reduced scalability and increased complexity."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What is the most likely outcome if a microservice maintains hidden state within itself?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Improved scalability and modularity.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Reduced scalability and increased complexity.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Enhanced fault tolerance and resilience.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Faster communication between services.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="3. Tight coupling between components."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is NOT a characteristic of cloud native microservices?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Stateless services.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Independent scalability.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Tight coupling between components.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Communication through lightweight mechanisms like REST APIs.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Monolithic architecture tightly couples components, while microservices are loosely coupled."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best describes the difference between monolithic and microservices architectures?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Monolithic architecture uses REST APIs for communication, while microservices do not.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Monolithic architecture tightly couples components, while microservices are loosely coupled.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Microservices require scaling the entire application, while monolithic architecture does not.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Microservices are deployed as a single unit, while monolithic architecture is deployed independently.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Ability to scale specific services based on demand."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is most likely to be a benefit of independent scalability in microservices?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Reduced resource utilization.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Ability to scale specific services based on demand.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Increased dependency between services.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Simplified deployment of the entire application.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Whether services are stateless and loosely coupled."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What should be checked first when designing a cloud native microservices architecture?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Whether services are stateless and loosely coupled.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. The number of services that share a single database.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. The use of monolithic deployment strategies.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. The absence of REST APIs for communication.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Ensuring the system&amp;#39;s behavior aligns with business goals."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best explains the primary focus of Behavior-Driven Development (BDD)?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Testing individual components in isolation.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Ensuring the system&amp;#39;s behavior aligns with business goals.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Writing code without defining acceptance criteria.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Avoiding collaboration between developers and stakeholders.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Miscommunication and misaligned expectations."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What is the most likely outcome if a team does not use a shared language in BDD?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Improved collaboration among team members.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Miscommunication and misaligned expectations.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Faster development cycles.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Clearer acceptance criteria for user stories.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="3. Writing tests after code implementation."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is NOT a key concept of BDD?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Outside-in perspective.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Collaboration among stakeholders.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Writing tests after code implementation.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Using Gherkin syntax for defining behavior.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. To define system behavior in a natural language format."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best describes the purpose of Gherkin syntax in BDD?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. To define system behavior in a natural language format.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. To replace automated testing tools.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. To eliminate the need for collaboration.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. To focus solely on technical implementation details.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Automating acceptance tests based on defined behavior."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is most likely to be a benefit of using BDD tools like Cucumber or Behave?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Automating acceptance tests based on defined behavior.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Replacing the need for stakeholder collaboration.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Avoiding the use of Gherkin syntax.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Focusing only on testing individual components.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Whether stakeholders and developers use a shared language."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What should be checked first when implementing BDD in a project?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Whether stakeholders and developers use a shared language.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. The number of automated testing tools available.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. The complexity of the system&amp;#39;s internal components.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. The absence of collaboration among team members.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Writing tests first to drive the design and development of code."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best explains the primary focus of Test-Driven Development (TDD)?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Writing code first and testing later.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Writing tests first to drive the design and development of code.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Avoiding automated testing in favor of manual testing.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Focusing on debugging after code implementation.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Accumulation of technical debt and reduced code quality."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What is the most likely outcome if a team skips the &amp;#39;Refactor&amp;#39; step in the TDD workflow?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Improved code quality and maintainability.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Accumulation of technical debt and reduced code quality.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Faster development cycles with no impact on quality.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Increased collaboration among team members.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="4. Deploy: Push the code directly to production."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is NOT a step in the TDD workflow?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Red: Write a failing test case.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Green: Write code to pass the test.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Refactor: Improve the code while keeping tests passing.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Deploy: Push the code directly to production.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. To write a failing test case that defines the desired behavior."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best describes the purpose of the &amp;#39;Red&amp;#39; step in TDD?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. To write code that passes all tests immediately.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. To write a failing test case that defines the desired behavior.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. To refactor existing code for better quality.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. To deploy the code to production.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Faster debugging and reduced maintenance costs."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is most likely to be a benefit of TDD in DevOps?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Faster debugging and reduced maintenance costs.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Avoiding the need for automated CI/CD pipelines.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Eliminating the need for test automation.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Reducing collaboration between developers and testers.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Whether the team understands the Red, Green, Refactor workflow."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What should be checked first when implementing TDD in a project?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Whether the team understands the Red, Green, Refactor workflow.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. The number of automated testing tools available.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. The complexity of the system&amp;#39;s internal components.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. The absence of collaboration among team members.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. To test a value hypothesis with minimal effort and gather feedback."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best explains the purpose of a Minimum Viable Product (MVP)?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. To deliver a complete product in the first iteration.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. To test a value hypothesis with minimal effort and gather feedback.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. To replace iterative development with a single release.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. To avoid customer feedback during development.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Increased risk of delivering a product that does not meet expectations."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What is the most likely outcome if a team delivers a product without iterative feedback?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Improved alignment with customer needs.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Increased risk of delivering a product that does not meet expectations.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Faster development cycles with reduced risk.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Enhanced collaboration with stakeholders.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="3. Delivering a complete product in one iteration."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is NOT a key principle of an MVP?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Iterative learning.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Customer collaboration.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Delivering a complete product in one iteration.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Adaptability based on feedback.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Starting with a basic version and refining it based on feedback."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best describes the iterative approach to MVP development?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Delivering a complete product without customer feedback.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Starting with a basic version and refining it based on feedback.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Avoiding changes to the product after the first release.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Focusing only on technical implementation details.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Reduced risk of building features that customers do not need."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is most likely to be a benefit of using an MVP approach?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Reduced risk of building features that customers do not need.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Avoiding customer involvement during development.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Delivering a fully-featured product in the first iteration.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Eliminating the need for iterative learning.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Whether the value hypothesis is clearly defined."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What should be checked first when creating an MVP?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Whether the value hypothesis is clearly defined.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. The number of features included in the product.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. The absence of customer feedback mechanisms.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. The complexity of the final product design.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Using code to provision and manage infrastructure resources."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best explains the concept of Infrastructure as Code (IaC)?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Managing infrastructure through manual configurations.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Using code to provision and manage infrastructure resources.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Avoiding the use of version control for infrastructure.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Replacing infrastructure automation with manual processes.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Breaking down work into smaller tasks to enable faster feedback and reduce waste."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best explains the concept of working in small batches?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Completing large tasks before seeking feedback.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Breaking down work into smaller tasks to enable faster feedback and reduce waste.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Avoiding iterative development to focus on final delivery.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Delivering all features at once to minimize delays.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Delayed feedback and increased risk of misaligned features."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What is the most likely outcome if a team works in large batches instead of small batches?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Faster feedback and reduced waste.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Delayed feedback and increased risk of misaligned features.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Improved alignment with customer needs.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Reduced time spent on debugging.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="4. Delayed delivery of features to production."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is NOT a benefit of working in small batches?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Faster feedback loops.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Reduced waste by identifying issues early.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Improved alignment with customer expectations.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Delayed delivery of features to production.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Completing one task at a time to enable rapid feedback and adjustment."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best describes single piece flow in small batch processing?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Completing one task at a time to enable rapid feedback and adjustment.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Processing multiple tasks simultaneously to save time.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Avoiding feedback until all tasks are completed.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Delivering all features at once to minimize iterations.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Faster identification of defects and misaligned requirements."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is most likely to be a benefit of decomposing features into smaller tasks?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Faster identification of defects and misaligned requirements.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Increased complexity in managing tasks.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Reduced collaboration among team members.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Delayed delivery of customer value.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Whether features are broken down into manageable tasks."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What should be checked first when implementing small batch processing in DevOps?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Whether features are broken down into manageable tasks.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. The number of features being delivered in a single release.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. The absence of feedback mechanisms.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. The complexity of the final product design.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. To promote modular repositories, short-lived branches, and collaborative code reviews."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best explains the purpose of the Git Feature Branch Workflow?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. To combine multiple microservices into a single repository.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. To promote modular repositories, short-lived branches, and collaborative code reviews.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. To avoid using pull requests for code reviews.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. To replace feature branches with long-lived branches.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. Increased complexity and difficulty in merging changes."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What is the most likely outcome if a team uses long-lived branches instead of short-lived feature branches?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Improved collaboration and faster code reviews.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Increased complexity and difficulty in merging changes.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Reduced overhead in managing repositories.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Enhanced modularity of the codebase.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="4. Merging your own pull requests without review."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is NOT a recommended practice in the Git Feature Branch Workflow?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Creating a new branch for every feature or issue.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Deleting feature branches after merging.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Using pull requests for code reviews.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Merging your own pull requests without review.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="2. It ensures developers only work with relevant code, reducing unnecessary overhead."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best describes the benefit of using one repository per component?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. It reduces modularity and increases overhead.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. It ensures developers only work with relevant code, reducing unnecessary overhead.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. It combines all microservices into a single repository for simplicity.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. It eliminates the need for pull requests.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Improved code quality and alignment with project goals."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following is most likely to be a benefit of collaborative code reviews through pull requests?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Improved code quality and alignment with project goals.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. Reduced collaboration among team members.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. Faster merging of changes without review.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. Avoiding the use of feature branches.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. To reduce the time required for manual testing."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 Which of the following best explains the purpose of automated testing in DevOps?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. To reduce the time required for manual testing.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. To eliminate the need for code reviews.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. To avoid collaboration between developers and testers.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. To replace CI/CD pipelines with manual deployments.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. Whether each component has its own repository."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What should be checked first when implementing the Git Feature Branch Workflow?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. Whether each component has its own repository.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. The number of long-lived branches in the repository.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. The absence of pull requests for code reviews.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. The complexity of the repository structure.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;div
 class="card mcq-card"
 style="display: none;"
 data-answer="1. A testing technique where random inputs are provided to the system to test its behavior."&gt;
 &lt;div class="card-body"&gt;
 &lt;h5 class="card-title"&gt;
 &lt;span class="question-number"&gt;&lt;/span&gt;
 What is Monkey Testing?
 &lt;/h5&gt;
 &lt;ul class="list-group list-group-flush"&gt;
 &lt;li class="list-group-item"&gt;
 1. A testing technique where random inputs are provided to the system to test its behavior.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 2. A testing technique focused on verifying specific functionality.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 3. A testing approach that eliminates the need for automated tools.
 &lt;/li&gt;
 &lt;li class="list-group-item"&gt;
 4. A testing method that requires detailed test cases.
 &lt;/li&gt;
 &lt;/ul&gt;
 &lt;div class="feedback-box mt-3" style="display: none;"&gt;
 &lt;div class="alert alert-info"&gt;
 &lt;strong&gt;Explanation:&lt;/strong&gt;
 &lt;span class="feedback-text"&gt;&lt;/span&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;

 &lt;div class="d-flex justify-content-between align-items-center"&gt;
 &lt;button id="next-button" class="btn btn-primary"&gt;Next&lt;/button&gt;
 &lt;button
 id="start-over-button"
 class="btn btn-secondary"
 style="display: none;"&gt;
 Start Over
 &lt;/button&gt;
 &lt;/div&gt;

 &lt;div id="score" class="mt-3"&gt;
 Attempted Questions: 0 /
 57
 &lt;/div&gt;
 &lt;div id="summary-container" class="mt-4"&gt;&lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
 &lt;/div&gt;
&lt;/div&gt;



&lt;script&gt;
window.HUGO_ENVIRONMENT = "production";
&lt;/script&gt;</description></item><item><title>Design for Failure</title><link>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/008-design-for-failure/</link><pubDate>Sun, 30 Mar 2025 01:42:43 +0000</pubDate><author>noreply@example.com (AG Sayyed)</author><guid>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/008-design-for-failure/</guid><description>&lt;p class="lead text-primary"&gt;
This document explains why failures happen in cloud-native applications, how to design systems that recover quickly, and how to use strategies like retry, circuit breaker, bulkhead, and chaos engineering to build systems that can handle failures gracefully.
&lt;/p&gt;
&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;In cloud-native applications, failures are bound to happen because of the complexity of distributed systems. Designing for failure means creating systems that can bounce back quickly and keep working even when things go wrong. Instead of trying to avoid failures completely (which is impossible), the focus is on spotting them quickly and recovering efficiently.&lt;/p&gt;</description></item><item><title>Cloud Native Microservices</title><link>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/007-cloud-native-microservices/</link><pubDate>Sat, 29 Mar 2025 23:08:13 +0000</pubDate><author>noreply@example.com (AG Sayyed)</author><guid>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/007-cloud-native-microservices/</guid><description>&lt;p class="lead text-primary"&gt;
This document explains the impact of cloud native microservices on application design, the concept of stateless microservices, and the differences between monolithic and microservices architectures.
&lt;/p&gt;
&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Cloud native microservices represent a modern approach to application design, where applications are built as a collection of small, independent services. These services are designed to be stateless, scalable, and loosely coupled, communicating through lightweight mechanisms such as REST APIs. This architecture enables flexibility, resilience, and efficient resource utilization in cloud environments.&lt;/p&gt;</description></item><item><title>Behaviour Driven Development</title><link>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/006-behaviour-driven-development/</link><pubDate>Sat, 29 Mar 2025 22:38:17 +0000</pubDate><author>noreply@example.com (AG Sayyed)</author><guid>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/006-behaviour-driven-development/</guid><description>&lt;p class="lead text-primary"&gt;
This document explains the concept of Behavior-Driven Development (BDD), its focus on system behavior, the use of Gherkin syntax for defining acceptance criteria, and its benefits in improving communication, code quality, and test automation.
&lt;/p&gt;
&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Behavior-Driven Development (BDD) is a software development approach that focuses on the behavior of a system as observed from the outside. Unlike Test-Driven Development (TDD), which tests individual components, BDD ensures that all components work together to achieve desired business outcomes. It emphasizes collaboration among developers, testers, and stakeholders to define system behavior in a shared language.&lt;/p&gt;</description></item><item><title>Test Driven Development</title><link>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/005-test-driven-development/</link><pubDate>Sat, 29 Mar 2025 22:00:43 +0000</pubDate><author>noreply@example.com (AG Sayyed)</author><guid>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/005-test-driven-development/</guid><description>&lt;p class="lead text-primary"&gt;
This document explains the concept of Test-Driven Development (TDD), its benefits in producing higher-quality code, the Red, Green, Refactor workflow, and its importance in DevOps for enabling CI/CD pipelines.
&lt;/p&gt;
&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Test-Driven Development (TDD) is a software development approach where test cases drive the design and development of code. Instead of writing code first, developers write tests for the desired behavior and then create code to make those tests pass. This process ensures that the code meets its intended purpose and remains robust over time.&lt;/p&gt;</description></item><item><title>Minimum Viable Product</title><link>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/004-mvp/</link><pubDate>Sat, 29 Mar 2025 21:52:23 +0000</pubDate><author>noreply@example.com (AG Sayyed)</author><guid>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/004-mvp/</guid><description>&lt;p class="lead text-primary"&gt;
This document explains the concept of a Minimum Viable Product (MVP), its purpose in testing hypotheses, and how it helps deliver what customers truly want through iterative learning and feedback.
&lt;/p&gt;
&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;A Minimum Viable Product (MVP) is the smallest effort required to test a value hypothesis and gain insights. It is not equivalent to phase one of a project or a beta release. Instead, an MVP focuses on learning and adapting based on customer feedback, enabling teams to refine their approach and deliver value incrementally.&lt;/p&gt;</description></item><item><title>Working in Small Batches</title><link>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/003-small-batches/</link><pubDate>Sat, 29 Mar 2025 21:43:04 +0000</pubDate><author>noreply@example.com (AG Sayyed)</author><guid>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/003-small-batches/</guid><description>&lt;p class="lead text-primary"&gt;
This document explains the importance of working in small batches, how single piece flow enables faster feedback, and how these practices align with DevOps principles to improve efficiency and reduce waste.
&lt;/p&gt;
&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Working in small batches is a concept derived from Lean Manufacturing that emphasizes fast feedback and minimizing waste. It allows teams to experiment, gain insights quickly, and avoid spending time on features that do not meet customer needs. Single piece flow, a related practice, ensures faster feedback loops by completing one task at a time, enabling rapid inspection and adjustment.&lt;/p&gt;</description></item><item><title>Git Repository Guideline</title><link>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/002-git-repo-guidline/</link><pubDate>Sat, 29 Mar 2025 21:33:14 +0000</pubDate><author>noreply@example.com (AG Sayyed)</author><guid>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/002-git-repo-guidline/</guid><description>&lt;p class="lead text-primary"&gt;
This document explains how the Git Feature Branch Workflow supports social coding by encouraging modular repositories, short-lived branches, and collaborative code reviews through pull requests.
&lt;/p&gt;
&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;The Git Feature Branch Workflow is a structured approach to managing repositories and code contributions. It emphasizes creating separate repositories for each component, using lightweight feature branches for development, and leveraging pull requests for collaborative code reviews. This workflow aligns with social coding principles, fostering collaboration and code quality.&lt;/p&gt;</description></item><item><title>Social Coding Principles</title><link>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/001-social-coding-principles/</link><pubDate>Sat, 29 Mar 2025 17:07:04 +0000</pubDate><author>noreply@example.com (AG Sayyed)</author><guid>http://ghafoorsblog.com/courses/ibm/devops-content/devops-pcert/01-introduction-to-devops/02-module/001-social-coding-principles/</guid><description>&lt;p class="lead text-primary"&gt;
This document explains the principles of social coding, how it fosters collaboration and code reuse, and the benefits of pair programming in improving code quality and skill transfer.
&lt;/p&gt;
&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;Social coding brings open-source principles into enterprises, enabling teams to collaborate on internal projects through public repositories. This approach encourages code reuse, reduces duplication, and fosters a culture of shared responsibility. Pair programming, a practice derived from Extreme Programming, complements social coding by improving code quality and facilitating skill transfer between team members.&lt;/p&gt;</description></item></channel></rss>