What is the main problem of this analytical model? - Requirements are formulated unclearly and pose risks of misunderstanding and incorrect implementation - Requirements ignore digital standards - Insufficient technical details in requirements - Lack of performance metrics - Requirements do not use templates - Communication problems of requirements
The data hierarchy is too complex for the client Lack of validation of returned data Lack of request authentication No indication of return field types The request returns redundant data that does not meet the client's requirements Lack of server-side filtering support
What is the main problem with this implementation BEGIN; CREATE TABLE sneakers ( id SERIAL PRIMARY KEY, design JSON NOT NULL ); CREATE OR REPLACE FUNCTION process_sneaker_order(sneaker_id INTEGER) RETURNS VOID AS $$ BEGIN UPDATE sneakers SET design = jsonb_set(design, '{status}', '"Processed"') WHERE id = sneaker_id; END; $$ LANGUAGE plpgsql; INSERT INTO sneakers (design) VALUES ('{"colors":"red,blue", "status":"Pending"}'); PERFORM process_sneaker_order(1); -- COMMIT;
What is the main problem in structuring requirements in this case? - No clear performance metrics - Requirements should be clearly separated for easier analysis and implementation - Data analysis does not consider all scenarios - Encryption methods are not defined - Security requirements are not highlighted separately - No structure for styling requirements
What side effect occurs when using UNION DISTINCT - Data type mismatch leads to an error - TOP is used without global sorting - Lack of indexes slows down UNION execution - Removing duplicates can unexpectedly reduce the number of returned rows - UNION creates more load than UNION ALL - Aggregate functions in subqueries can distort data
Which principle is violated in the structure of the SRS document - The process of requirement changes in the SRS is not defined - Responsible persons for functional blocks are absent - There are no sections for future modifications of the SRS - Vague formulations in the SRS requirements - The principle of clear separation of functional and non-functional requirements is violated - Non-compliance of the SRS with the IEEE 830 standard
What is the main problem of the chosen solution structure? - Storage logic does not provide data rotation - Architecture scalability violation - Insufficient flexibility for new requirements - Data flow restriction not implemented - Centralized architecture as a point of failure - Incorrect use of storage architecture leads to a bottleneck in performance
What is the main problem with this implementation? - Data hierarchy is too complex for the client - No validation of returned data - No request authentication - No indication of return field types - The request returns redundant data that does not meet the client's requirements Query code: query GetPublicTransportInfo { vehicles { id type route { id name stops { id location duration } } driver { id name licenseNumber phone } stats { totalTrips fuelConsumption averageSpeed } maintenance { lastInspection issuesReported } } }
What is the main problem with the current approach to code management? - Lack of XP practices leads to frequent errors and low code quality - Debugging only in production - No change management - No centralized configuration management - Insufficient test automation - Inefficient module integration
What is the main problem of the architecture in this case - The flexibility of the team is limited by the monopoly of decisions - Assigning responsible functions to one person limits adaptation - Centralization of information in one person creates a bottleneck - Rigid structure hinders quick adaptation - Centralization of decisions prevents team self-organization - Lack of autonomy reduces team engagement
What is the main problem with the system description structure - Incorrect separation of functions - System requirements are incomplete - System boundaries are not described clearly enough - Requirements description is unclear - Requirements for functions are described unclearly - System functions are described incompletely
What is the main problem of the chosen solution structure - Lack of semantic tags reduces accessibility and SEO effectiveness - No <h1> header on the page - Absence of <section> tag for block logic - Lack of structure in page sections - Buttons are not semantically grouped - Excessive nesting of <div> elements
What is the main problem of this analytical model - Team velocity is not tracked, which complicates planning - Geopolitical risks are not considered - Profit forecasts are not taken into account - No metrics for evaluating effectiveness - Insufficient stakeholder engagement - No clear distribution of responsibilities
What is the main problem with using HTTP methods in this case - Incorrect use of HTTP methods violates RESTful architecture and API readability - Errors are returned not in JSON format - Non-standard headers in GET requests - GET requests are not cached - Conflicts due to incorrect semantics of methods - Routing violates RESTful principles
What is the main problem of this implementation - Conflicting topic data cleanup policies - Potential collisions in broker identifiers - Mismatch in the number of partitions in the topic configuration - Broker ports are not unique, possible conflicts - Incorrect max.connections setting in MissionControl - Error in topic identifier uniqueness causing conflicts in data distribution
What is the main problem with this implementation - The thread is not closed in finally - The connection is not explicitly closed - Incorrect exception logging - HTTP headers are not set - HTTP status error handling is missing - Using an inappropriate HTTP method
Describe the main problem of this implementation - Server is bound to localhost and port 8080 - Infinite loop in store_design - Incorrect connection closing logic - Wrong handshake handling - No change control in designs - Security check and handshake are not separated
What is the main problem of the chosen service interaction structure - No caching to speed up data processing - No retry mechanism in case of failure - No adaptation to changes in preferences - Synchronous calls increase delays due to response time dependency - Authorization check issues in API - Error in processing responses from API
What is the main problem of the chosen solution structure - Module isolation without meta-information exchange - Logic duplication issues in modules - Violation of consistency between modules - Errors in financial report generation - Lack of a centralized deduplication system and related architectural complexities - Issues with accounting for delivery time aspects
Choose the most appropriate answer - Incorrect dependency direction - Services are connected by a common database, increasing coupling - No error handling in the auction service - No database backup - No API gateway monitoring - No caching in the wallet service
