A) Only the source code of the software B) Written text and illustrations describing architecture, design, functionality, and usage C) Helps new team members onboard quickly
A) Only the description of what the endpoint does B) Only the HTTP methods C) Purpose, expected behavior, URL route, and HTTP methods
A) START, STOP, PAUSE, RESUME B) GET, POST, PUT, DELETE C) OPEN, CLOSE, SAVE, LOAD
A) Using inline comments to explain complex logic B) Adding redundant comments that restate obvious code C) Avoiding any comments in the code
A) . To store data in the program B) To debug the code C) Standardized descriptions for functions, classes, or modules
A) HTML format B) PEP 257 C) Javadoc style
A) Javadoc B) Confluence C) Doxygen
A) To generate structured documentation from reStructuredText and docstrings B) To design user interfaces C) To compile code into executable files
A) Creative Commons B) Apache License 2.0 C) MIT License
A) Creative Commons B) MIT License C) Apache License 2.0
A) Software only B) Media and documents, not software C) Hardware designs
A) It is not necessary for open-source projects B) It protects intellectual property and clarifies usage rights C) It makes the software harder to use
A) The ability to be easily modified B) The ability to perform required functions under stated conditions without failure C) The ability to handle unexpected inputs without crashing
A) Error Detection & Correction B) Recovery Mechanisms C) Redundancy
A) Automated testing B) Redundancy C) Check sums, parity bits, and validation rules
A) User acceptance testing B) Automated testing C) Performance testing
A) Using parity bits B) Checkpointing and rollback in databases C) Duplicating servers
A) To avoid following any conventions B) To increase the number of tools used C) To ensure code and systems are clear, maintainable, and legally safe
A) Swagger / OpenAPI B) RAML C) Postman
A) Creating documentation websites B) API testing and documentation C) Designing API schemas
A) Redoc and MkDocs B) RAML and API Blueprint C) Swagger and OpenAPI
A) Sphinx B) Postman C) Redoc
A) parameters B) status C) message
A) daily.temp.min B) daily.temp.max C) daily.feels_like
A) Ability to handle unexpected inputs without crashing B) Optimal use of resources (time, memory, CPU) while delivering results quickly C) Ability to duplicate critical components
A) Checkpointing and rollback in databases, retry logic B) Duplicating critical components C) Using parity bits to detect errors
A) Using binary search instead of linear search for large datasets B) Using linear search instead of binary search B. Using binary search instead of linear search for larg C) Adding more servers
A) Optimal use of resources (time, memory, CPU, network) while delivering results quickly B) Ability to perform functions without failure over time C) Ability to duplicate critical components for fault tolerance
A) Algorithmic Optimization B) Database Optimization C) Caching & Memoization
A) To use multithreading B) To avoid memory leaks C) To identify performance bottlenecks using tools
A) Resource Management B) Caching & Memoization C) Caching & Memoization
A) Testing edge cases B) Avoiding memory leaks and releasing unused objects C) Handling exceptions
A) Parallelism & Concurrency B) Algorithmic Optimization C) Database Optimization
A) Indexing, query optimization, and normalization/denormalization trade-offs B) Caching all data C) Exception handling
A) Testing only the user interface B) Testing after full integration C) Testing individual units of code (functions, classes, methods) in isolation
A) Improves code maintainability and reduces regression issues B) Increases development time significantly C) Makes code harder to modify
A) Frequently integrating code into a shared repository and running automated tests B) Working on code in isolation without sharing C) Testing only once before release
A) To reduce the number of tests B) To delay integration until the end C) To ensure new code does not break existing functionality
A) Ability to use resources optimallyWhich practice involves never trusting user input and checking ranges, types, and formats? B) Ability to recover from failures automatically C) Ability to handle unexpected situations gracefully without crashing or incorrect results
A) Exception Handling B) Input Validation C) Fail-Safe Defaults
A) Using try/except blocks B) Testing only valid inputs C) Testing minimum, maximum, and out-of-range values
A) loops B) if/else C) try/except
A) Allowing any input without checks B) Showing technical errors to users C) Defaulting to secure/safe behavior if inputs are invalid
A) Anticipating and guarding against potential failures B) Avoiding any error handling C) Writing complex code to prevent errors
A) To log runtime information B) To retry failed operations C) To define preconditions, postconditions, and invariants
A) Automatically retrying operations like API calls if they fail B) Stopping the system on failure C) Ignoring failed operations
A) To speed up the code B) To collect runtime information for debugging and failure analysis C) To prevent errors from happening
A) Manually fixing errors B) Ignoring failures C) Implementing watchdogs or self-healing services
A) pytest B) Jest C) JUnit
A) A login form that handles incorrect passwords gracefully without crashing B) Code that only works with perfect inputs C) Code that does not have any error handling |