Cisco 200-901 Practice Test Questions, Exam Dumps

Practice Exams:

View All

200-901 Cisco Practice Test Questions and Exam Dumps

Question No 1:

Which two concepts describe test-driven development? (Choose two.)

A User acceptance testers develop the test requirements.
B It enables code refactoring.
C Tests are created when code is ready for release.
D Implementation is driven by incremental testing of release candidates.
E Write a test before writing code.

Correct Answer: B, E

Explanation:

Test-Driven Development (TDD) is a software development methodology that emphasizes writing tests before writing the actual code to ensure that the software behaves as expected. This approach leads to cleaner, more maintainable code while providing immediate feedback on code quality. Let’s analyze the two correct concepts:

B. It enables code refactoring
This is a correct statement. One of the key benefits of TDD is that it supports and encourages code refactoring. Since tests are written first and cover all aspects of the desired functionality, developers can safely refactor the code with confidence that the tests will catch any unintended changes in behavior. Refactoring is easier because the tests provide a safety net, ensuring that the refactored code continues to meet its specifications.

E. Write a test before writing code
This is the fundamental principle of Test-Driven Development. In TDD, the process starts by writing a test case that defines the desired functionality or behavior of a small part of the system. After the test is written, developers then write just enough code to pass the test. This cycle of writing tests first, then implementing the code to pass the tests, ensures that the software is developed with proper test coverage from the beginning.

Now, let’s consider the incorrect statements:

A. User acceptance testers develop the test requirements
This is incorrect. In TDD, test cases are written by developers, not by user acceptance testers. While user acceptance testing (UAT) may be involved later in the development process, TDD focuses on writing unit tests by developers based on the requirements or functionality they are working on. Test-driven development is part of the development phase, not the user acceptance phase.

C. Tests are created when code is ready for release
This is incorrect. In TDD, tests are created before the code is written. The test-driven cycle ensures that tests are written first to define the expected behavior, followed by the code implementation to make the test pass. Waiting until the code is ready for release to create tests contradicts the principles of TDD.

D. Implementation is driven by incremental testing of release candidates
This is incorrect. In TDD, implementation is driven by the tests themselves, not by testing release candidates. The process involves writing tests incrementally as developers implement small pieces of functionality. Release candidates are tested after the development process, but they are not the primary drivers of development in TDD.

In summary, the two concepts that describe test-driven development are enabling code refactoring (B) and writing tests before writing code (E). These two concepts are at the core of TDD, ensuring that software is both reliable and maintainable by testing from the very beginning of the development cycle.

Question No 2:

Which task is performed because the test-driven development approach is being used?

A creating test scenarios based on continuous development
B writing code without committing any coding violations
C refactoring code that is covered by existing tests
D testing existing software before developing new code

Correct answer: C

Explanation:

Test-Driven Development (TDD) is a software development methodology that emphasizes writing tests before writing the actual code. In this approach, developers follow a cycle of writing a test for a small piece of functionality, implementing the functionality, and then refactoring the code while ensuring that the tests still pass. Let’s break down each option to understand which task aligns with the TDD process:

A. creating test scenarios based on continuous development: This option is not specific to TDD. While TDD involves writing tests before development, creating test scenarios based on "continuous development" doesn’t fully capture the essence of the TDD approach. In TDD, tests are written before the code, not necessarily as a reaction to ongoing development. Continuous development could refer to a variety of agile practices but doesn't specifically align with the test-first philosophy of TDD.

B. writing code without committing any coding violations: While writing clean and efficient code is important in any development process, this is not a specific task associated with TDD. TDD focuses on the order of development—writing tests first, then code—and doesn’t inherently require a focus on avoiding coding violations. Writing tests and ensuring code quality are part of broader coding best practices but are not the core principles of TDD.

C. refactoring code that is covered by existing tests: This is a key aspect of TDD. After writing tests and implementing the required functionality, TDD encourages refactoring the code to improve its structure, readability, and maintainability. The crucial point is that refactoring happens only when there are existing tests in place to verify that the functionality remains correct. In TDD, tests are written first, and as the code evolves, developers continuously refactor it while ensuring that the tests still pass. This helps maintain code quality and ensures that the code changes don’t introduce new bugs.

D. testing existing software before developing new code: This option describes a practice more aligned with traditional software testing or validation, where the focus is on testing existing software. While TDD does involve writing tests, the key focus of TDD is writing tests for new functionality before implementing the code. It’s about verifying new code through tests before the code is written, not about testing pre-existing software.

In summary, the task that is most closely associated with the TDD approach is refactoring code that is covered by existing tests (option C). TDD ensures that developers refactor and improve the code while maintaining confidence in the functionality through the use of automated tests.

Question No 3:

In test-driven development, what is the first development task?

A Write code that implements a desired function.
B Write a failing test case for a desired function.
C Reverse engineer the code for a desired function.
D Write a passing test case for existing code.

Correct Answer: B

Explanation:

In test-driven development (TDD), the first step is to write a failing test case for the desired functionality. This is a key principle of TDD and is often referred to as the "Red" phase of the TDD cycle (Red-Green-Refactor). The reason for writing a failing test first is to clearly define the expected behavior of the function before any code is written. By doing this, developers ensure that they understand the requirements of the feature they are about to implement, and they create a solid foundation for writing code that fulfills those requirements.

The TDD cycle consists of three main steps:

Red (Write a failing test): The first task in TDD is to write a test that fails because the functionality has not been implemented yet. This test should specify the expected behavior of the code and help guide the development process.
Green (Write code to pass the test): After the test is written, the next step is to implement just enough code to make the test pass. At this point, the focus is purely on passing the test, without worrying about code quality or optimization.
Refactor (Improve the code): Once the test is passing, the next step is to refactor the code. This means improving the code without changing its behavior, ensuring it is clean, efficient, and maintainable while keeping the test green (passing).

Now, let’s examine why the other options are incorrect:

A (Write code that implements a desired function): This option is the second step in TDD (the "Green" phase), not the first. Writing the code comes after the test case is written, not before.
C (Reverse engineer the code for a desired function): Reverse engineering is the process of analyzing existing code to understand how it works. This is not part of the TDD process. TDD focuses on creating tests for new features, not analyzing or modifying existing code in this way.
D (Write a passing test case for existing code): In TDD, the test should be written before the code, and it should fail initially. Writing a passing test case for existing code is a separate activity, and it does not align with the core principles of TDD, where the focus is on writing tests for new functionality that will initially fail until the code is implemented.

In summary, the first development task in test-driven development is to write a failing test case for the desired functionality, which makes B the correct answer. This approach ensures that tests guide the development process, and only necessary code is written to pass the test, leading to more reliable and maintainable code.

Question No 4:

In test-driven development, what are two of the green bar patterns? (Choose two.)

A another test
B break
C triangulate
D starter test
E fake it

Correct answer: C, E

Explanation:

Test-driven development (TDD) is a software development process where tests are written before the code is implemented. The goal is to write enough code to make the test pass, resulting in a "green bar," which signifies a successful test. There are various strategies or "patterns" that can be used to achieve a green bar quickly, particularly in the context of test cases that initially fail. Let’s review the green bar patterns and why C and E are correct:

Option A: another test
The "another test" pattern does not specifically align with the green bar pattern in TDD. The idea behind TDD is to write a test, then write just enough code to pass it. Adding "another test" might be part of the TDD process, but it isn't specifically related to getting a green bar. The primary focus is on iterating tests and code, not immediately creating multiple tests before the code works.

Option B: break
The "break" pattern refers to intentionally causing a test to fail in order to confirm that it detects failure (or to understand what happens when a failure occurs). While this is part of testing in general, it’s not a direct green bar pattern. Green bar patterns focus on quickly making tests pass, rather than intentionally failing them.

Option C: triangulate
The "triangulate" pattern is a green bar strategy in which the developer writes multiple tests that address different angles of a problem. The aim is to refine and focus the code by writing new tests that help clarify the requirements or behavior of the system. This approach helps quickly reach the green bar by adding tests to ensure the code is being written to cover all necessary aspects. This is a typical green bar strategy in TDD, ensuring the developer gets more complete test coverage while achieving success in the tests.

Option D: starter test
The "starter test" refers to creating an initial test that establishes a basic functionality that the system should perform. While this is a common practice in TDD, it’s not specifically a green bar pattern. It’s part of the broader process but does not focus on achieving the green bar quickly after writing a test.

Option E: fake it
The "fake it" pattern involves writing just enough code to make the test pass, even if the code is not the most elegant or complete solution at first. This is one of the common green bar patterns in TDD. The idea is to write simple or placeholder code that allows the test to pass, and then refine the implementation later. This gets you to a green bar quickly, while you can later improve the code.

In conclusion, C ("triangulate") and E ("fake it") are two green bar patterns commonly used in TDD to help achieve a passing test (green bar) in the shortest amount of time. These strategies allow developers to get feedback quickly and iteratively refine the solution.

Question No 5:

In the test-driven development model, what is changed after a test fails?
A schedule
B project requirements
C code
D test

Correct answer: C

Explanation:

Test-Driven Development (TDD) is a software development methodology that revolves around writing tests before writing the corresponding production code. The basic cycle in TDD follows these steps:

Write a test for the functionality that needs to be implemented.
Run the test, which will fail initially (since the functionality hasn't been implemented yet).
Write the code to make the test pass.
Refactor the code if necessary, ensuring that the test still passes.

When a test fails in the TDD cycle, the focus is on modifying the code to make it pass the test. This is the central aspect of TDD: the test helps guide the development of the functionality, and the failure of the test indicates a gap in the implementation, prompting a change or addition to the code.

Let’s review the other options:

A – schedule:
The schedule generally refers to timelines for completing tasks or project phases, and it doesn't change based on test failures in the TDD methodology. While test failures can affect the project’s timeline indirectly, the schedule itself is not altered directly after a test fails.

B – project requirements:
Project requirements typically remain fixed unless there's a formal change request from stakeholders. In TDD, you are working to fulfill existing requirements, so they don’t change in response to individual test failures. The failure indicates that the code does not yet meet the requirements, but the requirements themselves remain unchanged.

C – code:
The code is the primary element that is adjusted after a test fails. In TDD, the failure of the test signifies that the current code does not meet the desired functionality, prompting a change in the code to fix the issue and make the test pass.

D – test:
The test does not change after it fails. The test is written to check specific functionality, and its purpose is to ensure the code behaves as expected. If a test fails, the code needs to be updated to meet the criteria of the test, not the other way around.

In summary, when a test fails in the TDD process, the code needs to be modified or written to fulfill the functionality outlined by the test. This iterative process ensures that development is driven by the tests and results in reliable, functioning software. Thus, the correct answer is C.

Question No 6:

What is a benefit of test-driven development?

A strict adherence to product requirements
B faster releases that have minimal features
C early customer involvement
D increased code quality

Correct Answer: D

Explanation:

Test-driven development (TDD) is a software development methodology that emphasizes writing tests before writing the actual code. The core principle of TDD is that developers first write a test case that defines a small piece of functionality, then write the minimal amount of code needed to pass the test. Once the test is successful, the code is refactored to improve its quality, and the process repeats.

The main benefit of TDD is D. increased code quality. This is because TDD encourages the creation of high-quality, maintainable code. Here's why:

Early Testing: Writing tests before code helps identify potential issues early in the development process. Developers are forced to think about edge cases and functionality before implementing the code, leading to fewer bugs and a more robust design.
Continuous Refactoring: Because tests are already in place, developers can refactor the code with confidence, knowing that any changes made will not break existing functionality. This leads to cleaner, more modular code over time.
Documentation: The test cases themselves serve as living documentation of the system's behavior, which is especially useful for new developers or when revisiting code in the future.

Now, let’s review the other options:

A. strict adherence to product requirements: While TDD does help ensure that code meets the specified requirements by verifying that it works as intended, strict adherence to product requirements is not a unique benefit of TDD. Requirements gathering, stakeholder input, and user stories are the primary factors that influence product requirements.
B. faster releases that have minimal features: While TDD might speed up the process of debugging and maintaining code, it does not directly lead to faster releases with minimal features. In fact, the development process may be slower at first due to the extra work of writing tests upfront, but the long-term benefits in code quality typically outweigh the initial overhead.
C. early customer involvement: While TDD promotes early testing and continuous validation, it does not inherently involve customers early in the process. Customer involvement typically occurs during iterative cycles in agile methodologies or through regular feedback loops in product development, not directly through TDD itself.

Therefore, D is the correct answer because TDD's primary benefit is increased code quality due to early testing, continuous refactoring, and better overall design.

Question No 7:

Which two statements describe the advantages of using a version control system? (Choose two.)

A. It allows for branching and merging so that different tasks are worked on in isolation before they are merged into a feature or master branch.
B. It provides tooling to automate application builds and infrastructure provisioning.
C. It allows multiple engineers to work against the same code and configuration files and manage differences and conflicts.
D. It provides a system to track User Stories and allocate to backlogs.
E. It allows developers to write effective unit tests.

Correct answer: A, C

Explanation:

A version control system (VCS) is a tool that manages changes to code and configuration files over time, helping multiple developers collaborate on a project while maintaining a history of modifications. It offers several significant advantages in software development, including:

Branching and merging (option A): One of the most powerful features of a VCS is the ability to create branches. Branching allows developers to work on different tasks or features independently, without affecting the main codebase. Once the tasks or features are completed and tested in isolation, they can be merged back into the main branch (e.g., master or feature branch). This makes collaboration efficient and prevents conflicts before integration. It also ensures that experimental or risky changes don't disrupt the stability of the primary codebase.
Managing code and configuration conflicts (option C): When multiple engineers work on the same code or configuration files, differences and conflicts are inevitable. A VCS helps manage these conflicts by providing tools to compare versions of files, track changes made by different developers, and resolve issues that arise when changes overlap. This capability helps teams collaborate effectively, especially in larger projects where many people might be modifying the same resources.

The other options do not directly relate to the core advantages of using a version control system:

Tooling for build automation (option B): While version control systems may integrate with build automation tools, they do not inherently provide tooling to automate application builds or infrastructure provisioning. These functions are usually provided by continuous integration/continuous deployment (CI/CD) systems and tools like Jenkins, Ansible, or Terraform.
Tracking User Stories and allocating to backlogs (option D): This feature is more closely associated with project management tools (e.g., Jira, Trello, or Asana), which are used to manage tasks, allocate user stories, and track progress on work items. A version control system does not directly manage or track these elements.
Writing unit tests (option E): While version control systems help manage code, they do not directly influence how unit tests are written. Unit tests are part of the software development process, but writing effective tests is the responsibility of the developers, not the version control system.

Therefore, the correct advantages of using a version control system are A and C.

Question No 8:

What are two advantages of version control software? (Choose two.)

A. It supports tracking and comparison of changes in binary format files.
B. It allows new team members to access the current code and history.
C. It supports comparisons between revisions of source code files.
D. It provides wiki collaboration software for documentation.
E. It allows old versions of packaged applications to be hosted on the Internet.

Correct Answer: B,C

Explanation:

Version control software plays a critical role in managing and tracking changes to source code or other types of files. It helps teams collaborate on projects and maintain a detailed history of changes, making it easier to understand modifications and revert to earlier versions if necessary. Below, we'll explore the advantages of version control software and clarify why options B and C are correct.

A. It supports tracking and comparison of changes in binary format files.
While version control software is excellent for tracking and comparing changes in text-based files, its ability to track binary format files (e.g., images, compiled executables) is more limited. Changes in binary files aren't as easily compared in a meaningful way because they do not represent human-readable content like source code. Although some version control systems can track binary files, this is not their primary strength, so this option is not considered a core advantage.

B. It allows new team members to access the current code and history.
This is a significant advantage of version control software. When a new team member joins a project, they can easily access the current codebase, as well as the complete history of changes made by other developers. This enables them to understand the evolution of the project, which is vital for both onboarding and ongoing development. They can also access previous versions of the code if needed, making it easier to troubleshoot or understand design decisions made earlier.

C. It supports comparisons between revisions of source code files.
Version control software excels at enabling comparisons between different versions (or revisions) of source code files. Developers can see what has changed between any two versions of a file, which is essential for debugging, code review, and understanding the impact of changes. This feature is particularly useful for identifying bugs introduced in recent commits or understanding why certain design decisions were made.

D. It provides wiki collaboration software for documentation.
While some version control platforms (e.g., GitHub, GitLab) may offer integrated wiki features for documentation, the primary function of version control software is not to provide wiki collaboration. Instead, its main purpose is to manage and track code changes. The inclusion of a wiki may be a supplementary feature, but it is not one of the core advantages of version control systems.

E. It allows old versions of packaged applications to be hosted on the Internet.
This is not an inherent advantage of version control software. While version control systems track changes to files, they are not designed to host or distribute old versions of applications. However, some version control systems may work alongside other tools or platforms (like repositories or artifact storage systems) to host versions of applications, but this is not a primary function of the version control system itself.

Thus, the correct answers are B and C, as they directly reflect key benefits of using version control software, such as enabling access to historical code and allowing comparisons between different versions of source code.

Question No 9:

Before which process is code review performed when version control is used?

A. checkout of code
B. merge of code
C. committing code
D. branching code

Correct Answer: C

Explanation:

Code review is an essential part of software development that helps ensure code quality, catch bugs, and maintain consistency across the project. In a version control system (VCS), such as Git, the code review process typically happens before the code is committed to the repository.

Here’s an explanation of the options:

A. checkout of code: Checking out code refers to the process of retrieving a specific version of the code from the version control system. While this action can be part of a developer's workflow, it is not the point at which code review occurs. The review happens after changes are made to the code, and before they are committed to the repository, not when code is checked out.
B. merge of code: Merging refers to the process of combining code from different branches into a single branch. While code review can occur during a merge (especially in pull requests), the review generally happens before the merge is performed. This allows feedback to be incorporated into the code before the final merge, ensuring that the merged code adheres to quality standards.
C. committing code: Committing refers to the action of saving changes to the local repository. Code review is typically performed before the commit. Developers submit code for review after making changes but before committing those changes to the version control system. This ensures that any issues are caught and resolved before the code becomes part of the official project history.
D. branching code: Branching is the process of creating a separate line of development, usually to work on new features or bug fixes. Code review does not typically happen during branching; instead, it happens after changes are made in a branch but before those changes are committed and merged into the main branch.

Therefore, the correct process for code review to occur is before the committing of code, as the review allows for necessary revisions and improvements before finalizing changes in the version control system.

Question No 10:

What is an advantage of a version control system?

A. facilitates resolving conflicts when merging code
B. ensures that unit tests are written
C. prevents over-writing code or configuration files
D. forces the practice of trunk-based development

Correct Answer: A

Explanation:

A version control system (VCS) is a tool that helps developers manage changes to code, track different versions, and collaborate on software development projects. It provides a variety of features that make the development process more efficient and less prone to errors. Let's explore each statement to identify the correct advantage of a version control system.

A. facilitates resolving conflicts when merging code: This statement is correct. One of the primary advantages of a version control system is that it allows multiple developers to work on the same project concurrently without overwriting each other's work. When two developers make changes to the same part of a codebase, the VCS provides mechanisms for detecting conflicts and allows the developers to manually or automatically resolve them. Tools like Git, for example, provide efficient ways of merging changes and resolving conflicts when the code branches diverge and need to be brought together. This is an essential feature that helps maintain the integrity of the codebase during collaborative development.
B. ensures that unit tests are written: This statement is incorrect. While a version control system tracks changes and versions of code, it does not enforce the practice of writing unit tests. The VCS itself does not dictate what should be tested or how tests should be written. Ensuring that unit tests are written is a matter of development practice and can be enforced through other tools, such as code quality checkers or continuous integration systems, but not directly by the version control system.
C. prevents over-writing code or configuration files: This statement is partially correct but misleading. A version control system reduces the risk of overwriting code or configuration files by allowing multiple versions of a file to exist and enabling developers to manage those versions. However, it does not automatically prevent overwriting; rather, it provides mechanisms (such as commit history, branches, and conflict resolution) that allow developers to recover from or avoid overwriting each other’s work. This advantage is more about providing a safeguard than directly preventing overwriting.
D. forces the practice of trunk-based development: This statement is incorrect. A version control system does not force any specific development practice, such as trunk-based development. It simply facilitates collaboration and version management. Trunk-based development is a methodology where developers work directly in the main branch (or trunk) instead of using feature branches. While a VCS can support trunk-based development, it does not enforce it. Developers are free to choose how they structure their workflow within the system.

In conclusion, the primary advantage of a version control system is its ability to facilitate resolving conflicts when merging code, which makes A the correct answer.