Unit 4 - Practice Quiz

DevOps aims to unite Development (Dev) and Operations (Ops) to automate and integrate the processes between them, leading to faster and more reliable software delivery.

The Waterfall model is sequential with distinct phases (e.g., requirements, design, implementation, testing), whereas DevOps promotes a continuous, collaborative, and iterative approach.

Git is a distributed version control system (VCS) used for tracking changes in source code during software development. It is fundamental for collaboration and managing code history.

Docker allows developers to package an application with all of its dependencies into a standardized unit called a container. This ensures the application runs consistently across different environments.

Selenium is a popular open-source tool used for automating tests for web applications. It allows testers to write scripts that interact with a web browser just like a user would.

The DevOps lifecycle is a continuous loop of phases including Plan, Code, Build, Test, Release, Deploy, Operate, and Monitor. Continuous Integration (part of Build/Test) is a core practice within this lifecycle.

Automation is crucial in DevOps to eliminate repetitive manual tasks, reduce the chance of human error, and accelerate the process of building, testing, and deploying software.

CI stands for Continuous Integration, which is the development practice of frequently merging code changes into a central repository, after which automated builds and tests are run.

At its core, software testing is an investigation conducted to provide stakeholders with information about the quality of the software, primarily by finding defects or bugs.

A major goal of testing is to find defects (bugs) so they can be fixed before the software is released to users. It is practically impossible to prove that software is 100% bug-free.

Non-functional testing checks the non-functional aspects of a software application, such as its performance, reliability, security, and usability, rather than its specific features.

Unit testing is the first level of software testing where individual units or components of a software are tested. The purpose is to validate that each unit of the software performs as designed.

Manual testing involves a human tester who manually executes test cases, interacts with the application's user interface, and verifies the results against the expected outcome, all without the help of automation scripts.

A test case is a document that specifies inputs, actions, and expected outcomes to test a specific feature or functionality of a software application.

When a tester finds a new bug and logs it in a defect tracking system, its initial status is set to "New" to indicate it has been reported and is awaiting review.

A DevOps Engineer is a key role responsible for managing the software development lifecycle, including building, maintaining, and automating the CI/CD pipeline and other operational tasks.

Kubernetes is a container orchestration platform that automates the deployment, scaling, and operation of application containers, like those created with Docker.

CD can stand for either Continuous Delivery (automating the release of tested code to a repository) or Continuous Deployment (automatically deploying every valid change to production).

Ansible is an open-source tool used for automating tasks such as configuration management, application deployment, and provisioning of IT infrastructure.

IT companies perform rigorous software testing to identify and fix defects, ensuring the product is reliable, functional, and meets the quality standards and requirements of the end-users.

The core principle of DevOps, in contrast to Waterfall, is to break down silos and integrate development, testing, and operations into a continuous process. This is achieved through rapid, iterative cycles (smaller, frequent releases) and constant feedback, which directly addresses the rigidity and late feedback issues of the Waterfall model.

A fundamental principle of Continuous Integration (CI) is to 'fail fast'. If any automated stage like unit or integration testing fails, the pipeline should stop immediately to prevent faulty code from progressing further. The team responsible for the commit is then notified to fix the issue promptly, maintaining the integrity of the main branch.

While Docker is used to create containers, Kubernetes is a container orchestration platform. Its core features are specifically designed to manage the lifecycle of containerized applications, including self-healing (restarting failed containers), service discovery, load balancing, and automated scaling, which perfectly match the described needs.

Integration Testing focuses on testing the interfaces and interactions between different software modules or components. In this scenario, the team is specifically testing how the 'payment gateway' and 'order management' modules work together, which is a classic example of integration testing.

Continuous Monitoring is the phase where the performance of the deployed application is actively tracked. Tools like Nagios or Prometheus are used to collect metrics, log errors, and alert the team about any issues in production. This feedback is crucial for maintaining stability and informing the next planning phase.

Tasks like usability testing, exploratory testing, and assessing the look and feel of an application heavily rely on human perception, intuition, and subjective feedback. While automation is excellent for repetitive, data-driven tests, manual testing is superior for evaluating the qualitative aspects of user experience.

Load Testing is a type of performance testing that evaluates a system's behavior under a specific, expected load. The scenario describes a need to check the application's performance with a high number of concurrent users, which is the exact purpose of load testing.

Boundary Value Analysis (BVA) is a test design technique that focuses on testing values at the edges or boundaries of an input domain. For a valid range of [8, 16], the key values to test are the minimum (8), the maximum (16), just below the minimum (7), and just above the maximum (17). This set is the most efficient for finding boundary-related defects.

Ansible is a configuration management tool designed for automating tasks like software provisioning, configuration, and application deployment. Its key features—being agentless (connecting via SSH) and using simple, human-readable YAML files (playbooks)—make it ideal for consistently applying changes like a security patch across many servers.

In the defect life cycle, a 'Deferred' status means the project stakeholders have acknowledged the bug's validity but have decided not to fix it in the current release. This could be due to low priority, high complexity of the fix, or tight deadlines. The fix is scheduled for a later version of the software.

Infrastructure as Code (IaC) is a core practice in DevOps automation. It involves defining infrastructure (servers, networks, databases) in configuration files. This approach ensures that every environment (development, staging, production) is created in a consistent, automated, and repeatable manner, which reduces configuration drift and manual errors.

A key objective of testing is not just to find bugs, but to build confidence in the software's quality. By verifying that the system works as expected and meets the specified requirements, testing provides stakeholders (like clients, managers, and users) with the assurance needed to release and use the product. It is practically impossible to prove the absence of all errors.

Selenium is a powerful suite of tools specifically designed for automating web browsers. It allows testers to write scripts in various programming languages to automate UI tests, validate functionality, and ensure cross-browser compatibility, making it the perfect fit for the described scenario.

To update a feature branch with the latest changes from another branch (like main), the developer must first be on their feature branch (git checkout feature-x). Then, running git merge main will take the commits from main and integrate them into feature-x, ensuring the developer is working with the most up-to-date codebase.

The core responsibility of a DevOps Engineer is to build and maintain the automated pipeline that enables rapid and reliable software delivery. This requires a deep understanding of Continuous Integration/Continuous Deployment (CI/CD) concepts and hands-on experience with foundational tools like Docker for containerizing applications and Kubernetes for managing them at scale.

User Acceptance Testing (UAT) is the final phase of testing where the actual end-users (or the client) test the software to see if it meets their business requirements and can handle real-world scenarios. It's the last check before the software is officially accepted and goes live.

Maven (or Mavin) is a build automation and project management tool primarily used for Java projects. Its core functions include managing project dependencies (downloading required libraries from repositories), compiling source code, and packaging the build artifact, all defined within a pom.xml file.

Regression Testing is the process of re-testing existing functionalities of an application after modifications (like bug fixes or new features) have been made. Its purpose is to ensure that the changes have not introduced new defects or broken previously working parts of the system.

Nagios is an open-source monitoring tool. Its primary function is to monitor infrastructure (servers, network devices) and services (HTTP, FTP, etc.). It can be configured to send alerts to the operations team when predefined thresholds are breached or when a service fails, making it ideal for the scenario described.

In modern IT practices, especially Agile and DevOps, testing is not a separate phase at the end but an integral part of the development process. By testing continuously throughout each sprint, teams can identify and fix bugs early when they are cheapest and easiest to resolve. This leads to higher quality software, more predictable releases, and reduced long-term costs.

An ImagePullBackOff error in Kubernetes specifically means the Kubelet on a node cannot pull the specified container image. Since the build/push stage is successful, the image exists in the private registry. The most likely issue is authentication. In Kubernetes, pulling from private registries is typically handled by creating a secret with registry credentials and attaching it to the Service Account of the pod/deployment via the imagePullSecrets field. A failure at this specific stage points directly to a misconfiguration of pull credentials within the target Kubernetes cluster, not an issue with the CI runner, the network in general, or the image itself.

The key issue is traffic being sent to pods that have started but are not ready. A livenessProbe restarts a failed container, but a readinessProbe determines if a container is ready to accept traffic. The Kubernetes Service endpoint controller uses the readiness probe's status to decide whether to include a pod's IP address in the list of available backends. Without a proper readiness probe, a pod is considered 'ready' as soon as its container starts, even if the application inside it is still initializing. Implementing a readiness probe (e.g., an HTTP check on a /health endpoint) solves this problem by delaying traffic routing until the application explicitly signals it's ready.

Boundary Value Analysis (BVA) focuses on testing the 'edges' of an equivalence partition. For a valid range of [1000, 50000], 3-point BVA tests the minimum value, the value just below the minimum (invalid), and the value just above the minimum (valid). It does the same for the maximum. Therefore, the points are: min-1 (1000), min+1 (49999), max (50001). This set is the most comprehensive for checking how the system handles values precisely at and immediately around the specified boundaries.

This question tests the concept of idempotency in Ansible. On the first run, the system state does not match the desired state (httpd-2.4.5 is installed, but httpd-2.4.6 is desired). Ansible will therefore perform an action (upgrade the package) and report the task's state as 'changed'. On the second run, Ansible checks the system again. This time, the desired state (httpd-2.4.6 is present) already exists. Because no action is needed to reach the desired state, Ansible will do nothing and report the state as 'ok'. This idempotent behavior is a core principle of configuration management tools.

This scenario tests the understanding of a practical, efficient defect management process. Simply re-opening the new defect loses the history of the original one. Creating a third defect adds unnecessary overhead. The most efficient and standard process is to consolidate all useful information into the single, original ticket. The valuable logs and steps from the 'duplicate' ticket should be copied/merged into the original ticket (#123), making it more actionable. After the information transfer, the new ticket can be correctly closed with the status 'Duplicate', maintaining a clear and consolidated history for the actual issue.

This question requires analyzing the trade-offs between manual and automation testing in a specific context. For a constantly changing UI, creating and maintaining UI automation scripts is extremely expensive and yields a low return on investment (ROI) due to frequent breakage. Manual exploratory and usability testing are far more effective for assessing subjective qualities like user experience. The most strategic approach is a hybrid one: use human testers for the volatile UI and focus automation efforts on the stable backend APIs, which are less likely to change and form the core application logic. This provides a stable regression safety net without the high cost of flaky UI test maintenance.

'Shifting Left' is a core DevOps principle that refers to moving quality assurance and testing activities earlier (to the 'left') in the software development lifecycle. Instead of a distinct testing phase at the end, testing becomes a continuous, integrated activity. This includes developers writing unit and integration tests, QA engineers participating in design and requirement reviews, and automated tests running with every code commit. The goal is to find and fix defects as early as possible when they are cheapest and easiest to resolve, rather than discovering them just before release.

This question tests a deep understanding of Git branching strategies. The key requirements are 'incorporate updates' and 'maintain a clean, linear history without a merge commit'.

• git merge explicitly creates a merge commit, which violates the second requirement.
• git pull origin main is a shortcut for git fetch and git merge, so it also creates a merge commit.
• git cherry-pick is used for picking individual commits, not for updating a whole branch.
• git rebase is the correct tool. git fetch origin updates the local copy of the remote repository. git rebase origin/main then takes all the commits from feature-A and replays them on top of the latest origin/main. This rewrites the history of feature-A to be linear and avoids a merge commit, satisfying both requirements.

This scenario is a prime example of System Testing. While it involves integration between components, the scope is broader.

• Unit Testing would test individual functions within a single microservice.
• Integration Testing typically focuses on the interface between two or more specific components (e.g., testing only the interaction between the API Gateway and the Cart Service).
• System Testing evaluates the complete, integrated system as a whole to verify it meets the specified requirements. The scenario describes testing the entire user workflow across all tiers (UI, API, Services, Database), which is the definition of System Testing.
• Acceptance Testing is similar in scope but is focused on user/customer validation, which is not specified here.

Effective negative test cases aim to isolate failures. The principle is to change only one input from a valid state to an invalid one to ensure that the resulting failure can be attributed directly to that specific change.

• Option A changes two conditions (username and password), which is bad practice as you wouldn't know which invalid input caused the failure.
• Option C is another positive test case.
• Option D is a security test case, which is a different category.
• Option B is the best choice because it keeps the username and checkbox in their valid state from the original test case but changes only the password to violate a single rule (missing a number). This precisely tests the password validation logic for that specific constraint.

While IaC does automate provisioning, its deeper, more transformative role in DevOps is to treat infrastructure as a software artifact. This means infrastructure definitions (e.g., Terraform .tf files) can be stored in a version control system (like Git), peer-reviewed through pull requests, tested in a CI pipeline (e.g., using terraform plan), and deployed automatically. This brings the same level of rigor, repeatability, and auditability to infrastructure management that CI/CD brings to application code, which is a fundamental goal of DevOps automation.

The core purpose of a multi-stage Docker build is to separate the build environment from the runtime environment. The 'builder' stage can be large and full of tools (compilers, build systems like Maven/npm, development headers, source code), which are necessary to build the application but are not needed to run it. The final stage starts from a clean, small base image and copies only the compiled artifacts (e.g., executables, Python virtual environment). This results in a minimal production image, which is smaller (faster to pull, less storage) and more secure (fewer tools and libraries for an attacker to exploit).

This question addresses the evolution of the role of testing. A fundamental principle of modern quality assurance is that quality cannot be 'tested in' at the end. It's impossible to prove a non-trivial program is defect-free (the 'absence of errors' fallacy). A more mature objective is defect prevention. This is achieved when QA professionals get involved early (part of 'Shift Left') to review requirements for ambiguity, analyze designs for potential flaws, and promote testable architecture. Finding a flaw in a requirements document is orders of magnitude cheaper to fix than finding the resulting bug in production. Therefore, preventing defects is a key objective, not just finding them.

Monitoring internal system metrics like CPU, memory, or disk space is known as white-box monitoring because it looks inside the system's state. While extremely useful for diagnostics, its primary limitation is that these metrics may not correlate directly with user-perceived performance or availability. For example, a server could have 95% CPU utilization but still be serving all user requests with low latency (e.g., during a heavy but efficient batch job). Conversely, the CPU could be low, but the application could be failing due to a bug. This is why white-box monitoring should be complemented with black-box monitoring (testing external, user-facing endpoints) to get a complete picture of system health.

The SRE discipline, as pioneered by Google, is fundamentally about using software engineering principles to automate and improve infrastructure and operations. The core of this practice is a quantitative, data-driven approach to reliability. SREs define explicit reliability targets (SLOs), measure them with metrics (SLIs), and then use the 'error budget' (the acceptable level of unreliability) to balance the pace of new feature releases with the need for stability. This data-driven mindset is the key differentiator for an SRE role compared to a traditional operations or even a general DevOps role.

This is a classic race condition in UI automation. The Selenium script is faster than the web application.

• Thread.sleep() is the worst practice; it's unreliable (might not be long enough, or too long, slowing down tests) and brittle.
• An implicit wait is better, but it's a global setting that applies to all findElement calls, which can unintentionally slow down the entire test suite and may not be suitable for elements that take longer than the global timeout to appear.
• Ignoring the exception is incorrect as it would lead to a false positive test result.
• An ExplicitWait is the best practice. It is applied to a specific element for a specific condition (e.g., being visible, clickable) with a dedicated timeout. It polls the DOM until the condition is met or the timeout expires, making the test robust and efficient.

This question differentiates between advanced deployment strategies. The defining characteristic of a Canary Release is exposing a new version to a small subset of real users. This is achieved by running both old and new versions simultaneously and using a load balancer or service mesh to control traffic distribution. Its primary benefit is risk mitigation: it allows the team to test the new version with live production traffic on a limited scale. If monitoring reveals increased errors or latency in the canary, traffic can be instantly routed back to the old version, impacting only a small percentage of users. This contrasts with Blue-Green (switches all traffic at once) and Big Bang/Recreate (replaces everything).

This scenario requires differentiating between types of performance testing.

• Load Testing verifies if the system can handle the expected load (e.g., testing at 1000 users).
• Spike Testing subjects the system to a sudden, extreme increase in load.
• Soak Testing checks for issues like memory leaks by running a sustained load over a long period.
• Stress Testing is designed to find the system's breaking point. It pushes the system beyond its expected capacity to see how and when it fails. The description of increasing the load far beyond the expected 1000 users to find the failure point is the definition of Stress Testing.

This question tests a critical concept in Maven's dependency management: dependency mediation. When multiple versions of the same artifact are encountered in the dependency tree, Maven uses the 'nearest definition' strategy. This means the version of the dependency that is closest to the root of the dependency tree (i.e., your project's pom.xml) wins. A direct dependency in your own pom.xml is at a distance of 1. A transitive dependency (B brought in via A) is at a distance of 2. Therefore, the directly declared version 2.0 will be chosen over the transitively included version 1.0.

The 'Sharing' pillar of CALMS is about breaking down silos and fostering collaboration.

• Automation relates to the 'A'.
• Lean principles relate to the 'L'.
• Tracking metrics relates to the 'M'.
• The scenario describing shared ownership of monitoring and collaborative, blameless problem-solving (post-mortems) is the quintessential example of 'Sharing'. It fosters a shared sense of responsibility for the product, encourages knowledge transfer between teams (Dev learns Ops, Ops learns Dev), and builds trust, which are the core goals of this pillar.