2341

EN + हिं Medium

GB What is 'assertion-driven debugging' and how does it prevent future regression of the same bug?

IN 'अभिकथन-संचालित डिबगिंग' क्या है और यह उसी बग के भविष्य के प्रतिगमन को कैसे रोकता है?

A

Assertion-driven debugging uses assert statements to automatically fix bugs at runtime अभिकथन-संचालित डिबगिंग रनटाइम पर बग को स्वचालित रूप से ठीक करने के लिए अभिकथन कथन का उपयोग करता है

B

Assertion-driven debugging adds runtime assertions that document the discovered invariant violated by the bug — after fixing the bug the assertion remains in the code, forming an executable specification that catches the same fault if it ever recurs अभिकथन-संचालित डिबगिंग रनटाइम अभिकथन जोड़ता है जो बग द्वारा उल्लंघन किए गए खोजे गए अपरिवर्तनीय दस्तावेज को दस्तावेज करता है - बग को ठीक करने के बाद अभिकथन कोड में रहता है, एक निष्पादन योग्य विनिर्देश बनाता है जो उसी गलती को पकड़ता है यदि यह कभी भी दोहराया जाता है

C

Assertion-driven debugging is identical to TDD and both terms describe the same practice अभिकथन-संचालित डिबगिंग टीडीडी के समान है और दोनों शब्द एक ही अभ्यास का वर्णन करते हैं

D

Assertions must always be removed from production builds to avoid performance overhead प्रदर्शन ओवरहेड से बचने के लिए दावे को हमेशा उत्पादन बिल्ड से हटा दिया जाना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) When you discover that a critical function was being called with a null parameter (causing crash), add: assert(param != null, 'param must not be null — see bug #1234'). This assertion: 1) documents the invariant for future readers, 2) catches the same bug immediately if the calling code regresses, 3) provides a specific error message that eliminates investigation time. This transforms a one-time fix into a permanent guard.

व्याख्या (हिन्दी) जब आपको पता चलता है कि एक महत्वपूर्ण फ़ंक्शन को शून्य पैरामीटर (क्रैश का कारण) के साथ कॉल किया जा रहा था, तो जोड़ें: ज़ोर (परम! = शून्य, 'परम शून्य नहीं होना चाहिए - बग #1234 देखें')। यह दावा: 1) भविष्य के पाठकों के लिए अपरिवर्तनीय दस्तावेज, 2) कॉलिंग कोड वापस आने पर तुरंत उसी बग को पकड़ लेता है, 3) एक विशिष्ट त्रुटि संदेश प्रदान करता है जो जांच के समय को समाप्त कर देता है। यह एक बार के फिक्स को स्थायी गार्ड में बदल देता है।

2342

EN + हिं

GB What is 'time-travel debugging' and what class of bugs benefits most from it?

IN 'टाइम-ट्रैवल डिबगिंग' क्या है और किस वर्ग के बग इससे सबसे अधिक लाभान्वित होते हैं?

A

Time-travel debugging resets the system clock to reproduce date-dependent bugs टाइम-ट्रैवल डिबगिंग दिनांक-निर्भर बग को पुन: उत्पन्न करने के लिए सिस्टम घड़ी को रीसेट करता है

B

Time-travel debugging records a complete execution trace allowing the debugger to step backwards as well as forwards through the execution history — most beneficial for bugs where the failure point is far removed from the causal fault (corruption happens at step 1, crash at step 10000) टाइम-ट्रैवल डिबगिंग एक पूर्ण निष्पादन ट्रेस को रिकॉर्ड करता है जो डिबगर को निष्पादन इतिहास के माध्यम से पीछे और साथ ही आगे बढ़ने की इजाजत देता है - उन बगों के लिए सबसे फायदेमंद जहां विफलता बिंदु कारण दोष से बहुत दूर है (भ्रष्टाचार चरण 1 पर होता है, चरण 10000 पर दुर्घटना)

C

Time-travel debugging is only available for JavaScript applications running in Chrome DevTools टाइम-ट्रैवल डिबगिंग केवल Chrome DevTools में चल रहे जावास्क्रिप्ट अनुप्रयोगों के लिए उपलब्ध है

D

Time-travel debugging requires specialised hardware and is not available for software-only systems टाइम-ट्रैवल डिबगिंग के लिए विशेष हार्डवेयर की आवश्यकता होती है और यह केवल सॉफ़्टवेयर सिस्टम के लिए उपलब्ध नहीं है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Mozilla RR, WinDbg TTD, and UndoDB enable recording + replay with reverse stepping. Classic use: a data structure is corrupted at step 1 but the crash occurs at step 10,000. Traditional debugging: find crash, step backward manually. Time-travel: set watchpoint on the corrupted memory address and run backward — the debugger stops exactly when the corruption occurred. This eliminates one of debugging's hardest problems: tracing effects back to causes across large execution gaps.

व्याख्या (हिन्दी) मोज़िला आरआर, विनडीबीजी टीटीडी, और अनडोडीबी रिवर्स स्टेपिंग के साथ रिकॉर्डिंग + रीप्ले सक्षम करते हैं। क्लासिक उपयोग: डेटा संरचना चरण 1 पर दूषित हो जाती है लेकिन चरण 10,000 पर क्रैश हो जाती है। पारंपरिक डिबगिंग: क्रैश ढूंढें, मैन्युअल रूप से पीछे की ओर कदम बढ़ाएं। समय-यात्रा: दूषित मेमोरी पते पर वॉचपॉइंट सेट करें और पीछे की ओर चलाएं - भ्रष्टाचार होने पर डिबगर ठीक से बंद हो जाता है। यह डिबगिंग की सबसे कठिन समस्याओं में से एक को समाप्त करता है: बड़े निष्पादन अंतरालों के कारण प्रभावों का पता लगाना।

2343

EN + हिं Hard

GB What is 'debuggability' as a software quality attribute and what design decisions most improve it?

IN सॉफ़्टवेयर गुणवत्ता विशेषता के रूप में 'डिबगबिलिटी' क्या है और कौन से डिज़ाइन निर्णय इसमें सबसे अधिक सुधार करते हैं?

A

Debuggability is improved by removing all abstractions and writing flat procedural code सभी अमूर्तताओं को हटाकर और फ्लैट प्रक्रियात्मक कोड लिखकर डिबगबिलिटी में सुधार किया जाता है

B

Debuggability is the ease with which failures can be diagnosed — improved by: centralised structured logging, correlation IDs through all layers, explicit error messages with context, health endpoints, observable internal state, and minimal side effects that make execution traceable डिबगबिलिटी वह आसानी है जिसके साथ विफलताओं का निदान किया जा सकता है - इसमें सुधार किया गया है: केंद्रीकृत संरचित लॉगिंग, सभी परतों के माध्यम से सहसंबंध आईडी, संदर्भ के साथ स्पष्ट त्रुटि संदेश, स्वास्थ्य समापन बिंदु, अवलोकन योग्य आंतरिक स्थिति, और न्यूनतम दुष्प्रभाव जो निष्पादन को ट्रैक करने योग्य बनाते हैं

C

Debuggability is automatically maximised by using a strongly-typed programming language दृढ़ता से टाइप की गई प्रोग्रामिंग भाषा का उपयोग करके डिबगबिलिटी स्वचालित रूप से अधिकतम हो जाती है

D

Debuggability and performance are always in perfect alignment — improving one always improves the other डिबगबिलिटी और प्रदर्शन हमेशा सही संरेखण में होते हैं - एक में सुधार करने से हमेशा दूसरे में सुधार होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Debuggability is a design quality that must be planned for, not added after. Decisions that harm debuggability: swallowing exceptions silently, using generic error messages ('an error occurred'), fire-and-forget async operations without correlation IDs, deeply nested call chains with no logging. Each removes a trail that would lead to the fault. Netflix, Google, and Amazon design for debuggability explicitly as a system property.

व्याख्या (हिन्दी) डिबगबिलिटी एक डिज़ाइन गुणवत्ता है जिसके लिए योजना बनाई जानी चाहिए, बाद में नहीं जोड़ी जानी चाहिए। निर्णय जो डिबगबिलिटी को नुकसान पहुंचाते हैं: अपवादों को चुपचाप निगलना, सामान्य त्रुटि संदेशों ('एक त्रुटि हुई') का उपयोग करना, सहसंबंध आईडी के बिना एसिंक ऑपरेशंस को आग लगाना और भूल जाना, बिना लॉगिंग के गहराई से नेस्टेड कॉल चेन। प्रत्येक उस निशान को हटाता है जो गलती की ओर ले जाता है। नेटफ्लिक्स, गूगल और अमेज़ॅन स्पष्ट रूप से एक सिस्टम प्रॉपर्टी के रूप में डिबगबिलिटी के लिए डिज़ाइन करते हैं।

2344

EN + हिं Easy

GB What is 'breakpoint management' in large codebases and what discipline is needed to avoid breakpoint chaos?

IN बड़े कोडबेस में 'ब्रेकपॉइंट प्रबंधन' क्या है और ब्रेकपॉइंट अराजकता से बचने के लिए किस अनुशासन की आवश्यकता है?

A

Breakpoint management is a source control feature for saving and sharing breakpoints with team members ब्रेकप्वाइंट प्रबंधन टीम के सदस्यों के साथ ब्रेकप्वाइंट को सहेजने और साझा करने के लिए एक स्रोत नियंत्रण सुविधा है

B

In complex multi-session debugging, accumulated stale breakpoints in wrong files cause debuggers to stop at irrelevant points, wasting time — discipline requires: clearing all breakpoints before each debugging session, naming conditional breakpoints, and using focused logpoints instead of code-modifying prints जटिल बहु-सत्र डिबगिंग में, गलत फ़ाइलों में संचित बासी ब्रेकप्वाइंट के कारण डिबगर्स अप्रासंगिक बिंदुओं पर रुक जाते हैं, जिससे समय बर्बाद होता है - अनुशासन की आवश्यकता होती है: प्रत्येक डिबगिंग सत्र से पहले सभी ब्रेकप्वाइंट को साफ़ करना, सशर्त ब्रेकप्वाइंट का नामकरण करना, और कोड-संशोधित प्रिंट के बजाय केंद्रित लॉगप्वाइंट का उपयोग करना

C

Breakpoints have no management overhead because modern IDEs automatically track and remove them ब्रेकप्वाइंट का कोई प्रबंधन ओवरहेड नहीं है क्योंकि आधुनिक आईडीई स्वचालित रूप से उन्हें ट्रैक करते हैं और हटा देते हैं

D

More breakpoints always improve debugging efficiency by providing more observation points अधिक ब्रेकप्वाइंट हमेशा अधिक अवलोकन बिंदु प्रदान करके डिबगिंग दक्षता में सुधार करते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Experienced debuggers maintain a discipline: clear all breakpoints at session start, add only what you need for the current hypothesis. IDEs like VS Code and IntelliJ support breakpoint groups, conditional breakpoints (only trigger when x > 0), hit count breakpoints (trigger on 5th call), and logpoints (log without pausing) — these reduce the cognitive load of managing many observation points.

व्याख्या (हिन्दी) अनुभवी डिबगर्स एक अनुशासन बनाए रखते हैं: सत्र शुरू होने पर सभी ब्रेकप्वाइंट साफ़ करें, केवल वही जोड़ें जो आपको वर्तमान परिकल्पना के लिए चाहिए। वीएस कोड और इंटेलीजे जैसे आईडीई ब्रेकप्वाइंट समूहों, सशर्त ब्रेकप्वाइंट (केवल x > 0 होने पर ट्रिगर), हिट काउंट ब्रेकप्वाइंट (5वीं कॉल पर ट्रिगर), और लॉगप्वाइंट (बिना रुके लॉग) का समर्थन करते हैं - ये कई अवलोकन बिंदुओं को प्रबंधित करने के संज्ञानात्मक भार को कम करते हैं।

2345

EN + हिं Easy

GB What is the 'scientific method' applied to debugging and what specific cognitive error does it prevent?

IN डिबगिंग के लिए प्रयुक्त 'वैज्ञानिक विधि' क्या है और यह किस विशिष्ट संज्ञानात्मक त्रुटि को रोकती है?

A

Scientific method debugging requires formal mathematical proofs of every hypothesised fix वैज्ञानिक विधि डिबगिंग के लिए प्रत्येक परिकल्पित समाधान के औपचारिक गणितीय प्रमाण की आवश्यकता होती है

B

Scientific debugging forms explicit hypotheses, designs a minimal experiment to test each hypothesis, and records results before forming the next — preventing 'shotgun debugging' (making random changes hoping one fixes the bug) which destroys evidence and may mask the real fault वैज्ञानिक डिबगिंग स्पष्ट परिकल्पनाएँ बनाती है, प्रत्येक परिकल्पना का परीक्षण करने के लिए एक न्यूनतम प्रयोग डिज़ाइन करती है, और अगली परिकल्पना बनाने से पहले परिणामों को रिकॉर्ड करती है - 'शॉटगन डिबगिंग' को रोकना (इस उम्मीद में यादृच्छिक परिवर्तन करना कि कोई बग को ठीक कर देगा) जो साक्ष्य को नष्ट कर देता है और वास्तविक गलती को छिपा सकता है

C

Scientific method debugging is only taught in academic computer science courses and not used in industry वैज्ञानिक विधि डिबगिंग केवल अकादमिक कंप्यूटर विज्ञान पाठ्यक्रमों में पढ़ाई जाती है और उद्योग में इसका उपयोग नहीं किया जाता है

D

Scientific debugging requires more time than shotgun debugging and is only used for critical bugs वैज्ञानिक डिबगिंग के लिए शॉटगन डिबगिंग की तुलना में अधिक समय की आवश्यकता होती है और इसका उपयोग केवल गंभीर बग के लिए किया जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Shotgun debugging: change everything at once and see if it works — this may fix the symptom while leaving the cause intact, or fix by luck while masking a related defect. Scientific debugging: 'My hypothesis: the bug is caused by X. I'll change only X and observe. Result: still broken. New hypothesis: Y.' Each experiment is minimal and isolated, preserving evidence and systematically narrowing the fault location.

व्याख्या (हिन्दी) शॉटगन डिबगिंग: सब कुछ एक बार में बदलें और देखें कि क्या यह काम करता है - यह कारण को बरकरार रखते हुए लक्षण को ठीक कर सकता है, या संबंधित दोष को छिपाते हुए भाग्य से ठीक कर सकता है। वैज्ञानिक डिबगिंग: 'मेरी परिकल्पना: बग एक्स के कारण होता है। मैं केवल एक्स को बदलूंगा और निरीक्षण करूंगा। नतीजा: अभी भी टूटा हुआ. नई परिकल्पना: वाई.' प्रत्येक प्रयोग न्यूनतम और पृथक है, साक्ष्य को संरक्षित करता है और गलती के स्थान को व्यवस्थित रूप से सीमित करता है।

2346

EN + हिं Easy

GB What is 'logging correlation ID' pattern in microservices debugging and what distributed tracing problem does it solve?

IN माइक्रोसर्विसेज डिबगिंग में 'लॉगिंग सहसंबंध आईडी' पैटर्न क्या है और यह किस वितरित ट्रेसिंग समस्या का समाधान करता है?

A

Correlation IDs are database primary keys used to track records across multiple tables सहसंबंध आईडी डेटाबेस प्राथमिक कुंजी हैं जिनका उपयोग कई तालिकाओं में रिकॉर्ड को ट्रैक करने के लिए किया जाता है

B

A correlation ID is a unique identifier generated at request entry and propagated through all service calls — solving the problem of matching log entries from Service A, B, C, and D that all processed the same user request across thousands of concurrent requests सहसंबंध आईडी एक अद्वितीय पहचानकर्ता है जो अनुरोध प्रविष्टि पर उत्पन्न होता है और सभी सेवा कॉल के माध्यम से प्रचारित होता है - सेवा ए, बी, सी और डी से मिलान लॉग प्रविष्टियों की समस्या को हल करता है जो सभी हजारों समवर्ती अनुरोधों में एक ही उपयोगकर्ता अनुरोध को संसाधित करते हैं

C

Correlation IDs are only needed when services are deployed in different cloud regions सहसंबंध आईडी की आवश्यकता केवल तभी होती है जब सेवाएँ विभिन्न क्लाउड क्षेत्रों में तैनात की जाती हैं

D

Correlation IDs are automatically added by all cloud load balancers and require no developer action सहसंबंध आईडी सभी क्लाउड लोड बैलेंसर्स द्वारा स्वचालित रूप से जोड़े जाते हैं और किसी डेवलपर कार्रवाई की आवश्यकता नहीं होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Without correlation IDs, microservice logs look like: '[10:00:01] Service A: processing request' and '[10:00:01] Service C: database error' — which request triggered the DB error? With correlation ID 'req-7f3a': '[10:00:01][req-7f3a] Service A: processing' and '[10:00:01][req-7f3a] Service C: database error' — you can filter all logs for req-7f3a to see the complete request journey. OpenTelemetry standardises this propagation.

व्याख्या (हिन्दी) सहसंबंध आईडी के बिना, माइक्रोसर्विस लॉग इस तरह दिखते हैं: '[10:00:01] सेवा ए: प्रसंस्करण अनुरोध' और '[10:00:01] सेवा सी: डेटाबेस त्रुटि' - किस अनुरोध ने डीबी त्रुटि को ट्रिगर किया? सहसंबंध आईडी 'req-7f3a' के साथ: '[10:00:01][req-7f3a] सेवा A: प्रसंस्करण' और '[10:00:01][req-7f3a] सेवा C: डेटाबेस त्रुटि' - आप संपूर्ण अनुरोध यात्रा देखने के लिए req-7f3a के लिए सभी लॉग फ़िल्टर कर सकते हैं। ओपनटेलीमेट्री इस प्रसार को मानकीकृत करती है।

2347

EN + हिं Easy

GB What is 'memory debugging' with AddressSanitizer (ASan) and what categories of bugs does it detect that valgrind also detects?

IN एड्रेससैनिटाइज़र (एएसएएन) के साथ 'मेमोरी डिबगिंग' क्या है और यह किस श्रेणी के बग का पता लगाता है जिनका वेलग्रिंड भी पता लगाता है?

A

ASan only detects memory leaks; valgrind only detects null pointer dereferences ASan केवल मेमोरी लीक का पता लगाता है; वालग्रिंड केवल शून्य सूचक डीरेफ़रेंस का पता लगाता है

B

Both ASan and Valgrind detect: use-after-free, heap buffer overflows, stack buffer overflows, use of uninitialised memory — ASan is 2x slower than uninstrumented code; Valgrind is 10-50x slower, making ASan more practical for CI use while Valgrind offers more detailed analysis ASan और Valgrind दोनों पता लगाते हैं: उपयोग-बाद-मुक्त, हीप बफ़र ओवरफ़्लो, स्टैक बफ़र ओवरफ़्लो, अनइनिशियलाइज़्ड मेमोरी का उपयोग - ASan अनइंस्ट्रूमेंटेड कोड की तुलना में 2x धीमा है; वैलग्रिंड 10-50x धीमा है, जो सीआई उपयोग के लिए एएसएएन को अधिक व्यावहारिक बनाता है जबकि वैलग्रिंड अधिक विस्तृत विश्लेषण प्रदान करता है

C

ASan can only instrument programs compiled with GCC; Valgrind works with any executable एएसएएन केवल जीसीसी के साथ संकलित कार्यक्रमों को लिख सकता है; वालग्रिंड किसी भी निष्पादन योग्य के साथ काम करता है

D

Memory debugging tools are only needed for programs over 100,000 lines of code मेमोरी डिबगिंग टूल की आवश्यकता केवल 100,000 लाइनों से अधिक कोड वाले प्रोग्राम के लिए होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Use-after-free: access memory after free(). Heap overflow: write past end of malloc'd buffer. Stack overflow: write past end of stack array. Valgrind's Memcheck instruments at binary level (no recompile) with very detailed output but 10-50x overhead. ASan compiles instrumentation directly into the binary (2x overhead), making it feasible in CI pipelines. Both are essential tools for C/C++ code quality.

व्याख्या (हिन्दी) उपयोग-बाद-मुक्त: मुफ़्त के बाद मेमोरी तक पहुंचें()। हीप ओवरफ़्लो: मॉलोक्ड बफ़र का पिछला अंत लिखें। स्टैक ओवरफ्लो: स्टैक ऐरे का पिछला अंत लिखें। वेलग्रिंड के मेमचेक उपकरण बाइनरी स्तर पर (कोई पुन: संकलन नहीं) बहुत विस्तृत आउटपुट के साथ लेकिन 10-50x ओवरहेड। एएसएएन इंस्ट्रूमेंटेशन को सीधे बाइनरी (2x ओवरहेड) में संकलित करता है, जिससे यह सीआई पाइपलाइनों में संभव हो जाता है। दोनों C/C++ कोड गुणवत्ता के लिए आवश्यक उपकरण हैं।

2348

EN + हिं Easy

GB What is a 'debugger trap' instruction and what security implication does it have in production code?

IN 'डीबगर ट्रैप' निर्देश क्या है और उत्पादन कोड में इसका क्या सुरक्षा निहितार्थ है?

A

Debugger trap instruction terminates the program immediately regardless of attached debugger डिबगर ट्रैप निर्देश संलग्न डिबगर की परवाह किए बिना प्रोग्राम को तुरंत समाप्त कर देता है

B

A debugger trap (INT 3 on x86, BKPT on ARM) halts execution and transfers control to an attached debugger; in production code without a debugger, it causes a crash — anti-debugging techniques (debugger detection) sometimes use this to detect reverse engineering attempts एक डिबगर ट्रैप (x86 पर INT 3, ARM पर BKPT) निष्पादन रोक देता है और नियंत्रण को एक संलग्न डिबगर में स्थानांतरित कर देता है; डिबगर के बिना उत्पादन कोड में, यह क्रैश का कारण बनता है - एंटी-डिबगिंग तकनीक (डीबगर डिटेक्शन) कभी-कभी रिवर्स इंजीनियरिंग प्रयासों का पता लगाने के लिए इसका उपयोग करती है

C

Debugger trap instructions are only valid in assembly language and cannot appear in high-level compiled code डिबगर ट्रैप निर्देश केवल असेंबली भाषा में मान्य हैं और उच्च-स्तरीय संकलित कोड में प्रकट नहीं हो सकते हैं

D

Debugger trap instructions have no security implications and are safe in any production system डिबगर ट्रैप निर्देशों का कोई सुरक्षा निहितार्थ नहीं है और ये किसी भी उत्पादन प्रणाली में सुरक्षित हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) In debug builds, INT 3 inserted by breakpoints is safe — the debugger catches it. In production, accidentally shipping INT 3 (e.g., a debug build in production) crashes the process for any user. Malware uses INT 3 chains as an anti-analysis technique: if execution reaches INT 3 and no debugger is attached, it crashes (anti-sandbox); if a debugger catches it, the malware changes behaviour (anti-analysis). Security-sensitive code must be audited for debug artifacts before production deployment.

व्याख्या (हिन्दी) डिबग बिल्ड में, ब्रेकप्वाइंट द्वारा डाला गया INT 3 सुरक्षित है - डिबगर इसे पकड़ लेता है। उत्पादन में, गलती से INT 3 की शिपिंग (उदाहरण के लिए, उत्पादन में एक डिबग बिल्ड) किसी भी उपयोगकर्ता के लिए प्रक्रिया को क्रैश कर देती है। मैलवेयर एंटी-एनालिसिस तकनीक के रूप में INT 3 चेन का उपयोग करता है: यदि निष्पादन INT 3 तक पहुंचता है और कोई डिबगर संलग्न नहीं है, तो यह क्रैश हो जाता है (एंटी-सैंडबॉक्स); यदि कोई डिबगर इसे पकड़ लेता है, तो मैलवेयर व्यवहार बदल देता है (एंटी-एनालिसिस)। उत्पादन परिनियोजन से पहले डिबग कलाकृतियों के लिए सुरक्षा-संवेदनशील कोड का ऑडिट किया जाना चाहिए।

2349

EN + हिं Medium

GB What is 'preventive maintenance' in software and how does it differ from perfective maintenance?

IN सॉफ़्टवेयर में 'निवारक रखरखाव' क्या है और यह संपूर्ण रखरखाव से किस प्रकार भिन्न है?

A

Preventive maintenance fixes defects; perfective maintenance prevents defects निवारक रखरखाव दोषों को ठीक करता है; उत्तम रखरखाव दोषों को रोकता है

B

Preventive maintenance restructures or refactors code to improve future maintainability (reducing technical debt) before failures occur; perfective maintenance adds new functionality or improves performance in response to user requests विफलताएं होने से पहले भविष्य में रखरखाव (तकनीकी ऋण को कम करना) में सुधार के लिए निवारक रखरखाव पुनर्गठन या रिफैक्टर कोड; संपूर्ण रखरखाव उपयोगकर्ता के अनुरोधों के जवाब में नई कार्यक्षमता जोड़ता है या प्रदर्शन में सुधार करता है

C

Both preventive and perfective maintenance are identical activities with different scheduling निवारक और संपूर्ण रखरखाव दोनों अलग-अलग शेड्यूल के साथ समान गतिविधियाँ हैं

D

Preventive maintenance is only applicable to hardware systems, not software निवारक रखरखाव केवल हार्डवेयर सिस्टम पर लागू होता है, सॉफ़्टवेयर पर नहीं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Preventive maintenance (ISO 14764's fourth maintenance type, added later) addresses known maintainability risks before they cause failures: restructuring spaghetti code, updating deprecated dependencies, improving test coverage in high-risk modules. Perfective maintenance responds to user requests for new features or performance improvements. Preventive is proactive internal quality investment; perfective is reactive external value delivery.

व्याख्या (हिन्दी) निवारक रखरखाव (आईएसओ 14764 का चौथा रखरखाव प्रकार, बाद में जोड़ा गया) विफलताओं का कारण बनने से पहले ज्ञात रखरखाव जोखिमों को संबोधित करता है: स्पेगेटी कोड का पुनर्गठन, अप्रचलित निर्भरता को अपडेट करना, उच्च जोखिम वाले मॉड्यूल में परीक्षण कवरेज में सुधार करना। परफेक्ट रखरखाव नई सुविधाओं या प्रदर्शन में सुधार के लिए उपयोगकर्ता के अनुरोधों का जवाब देता है। निवारक सक्रिय आंतरिक गुणवत्ता निवेश है; परफेक्ट प्रतिक्रियाशील बाह्य मूल्य वितरण है।

2350

EN + हिं Easy

GB What is 'software asset management' in maintenance and what financial implication does inadequate tracking create?

IN रखरखाव में 'सॉफ़्टवेयर परिसंपत्ति प्रबंधन' क्या है और अपर्याप्त ट्रैकिंग क्या वित्तीय निहितार्थ पैदा करती है?

A

Software asset management refers to version control for source code repositories सॉफ़्टवेयर परिसंपत्ति प्रबंधन स्रोत कोड रिपॉजिटरी के लिए संस्करण नियंत्रण को संदर्भित करता है

B

Software asset management tracks all software licenses, versions, and usage across an organisation — inadequate tracking creates: license compliance violations (fines), paying for unused licenses, or running unsupported/unpatched software creating security liability सॉफ़्टवेयर परिसंपत्ति प्रबंधन किसी संगठन में सभी सॉफ़्टवेयर लाइसेंस, संस्करण और उपयोग को ट्रैक करता है - अपर्याप्त ट्रैकिंग उत्पन्न करती है: लाइसेंस अनुपालन उल्लंघन (जुर्माना), अप्रयुक्त लाइसेंस के लिए भुगतान करना, या असमर्थित/अप्रकाशित सॉफ़्टवेयर चलाने से सुरक्षा दायित्व उत्पन्न होता है

C

Software asset management is only required for organisations with more than 1000 employees सॉफ़्टवेयर परिसंपत्ति प्रबंधन केवल 1000 से अधिक कर्मचारियों वाले संगठनों के लिए आवश्यक है

D

Software asset management is entirely automated by cloud providers and requires no manual tracking सॉफ़्टवेयर परिसंपत्ति प्रबंधन क्लाउड प्रदाताओं द्वारा पूरी तरह से स्वचालित है और इसके लिए किसी मैन्युअल ट्रैकिंग की आवश्यकता नहीं होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) BSA (Business Software Alliance) audits have resulted in multi-million dollar settlements for companies running unlicensed software. Conversely, organisations routinely pay for 30% more licenses than they use. Software asset management (ISO 19770) provides the inventory, entitlements, and usage data needed to optimise license spend, ensure compliance, and maintain a patched, supported software estate.

व्याख्या (हिन्दी) BSA (Business Software Alliance) audits have resulted in multi-million dollar settlements for companies running unlicensed software. इसके विपरीत, संगठन नियमित रूप से उपयोग की तुलना में 30% अधिक लाइसेंस के लिए भुगतान करते हैं। सॉफ़्टवेयर परिसंपत्ति प्रबंधन (आईएसओ 19770) लाइसेंस व्यय को अनुकूलित करने, अनुपालन सुनिश्चित करने और एक पैच किए गए, समर्थित सॉफ़्टवेयर संपदा को बनाए रखने के लिए आवश्यक सूची, पात्रता और उपयोग डेटा प्रदान करता है।

2351

EN + हिं Easy

GB What is 'hotfix' versus 'patch release' versus 'minor release' in software maintenance release management?

IN सॉफ़्टवेयर रखरखाव रिलीज़ प्रबंधन में 'हॉटफ़िक्स' बनाम 'पैच रिलीज़' बनाम 'मामूली रिलीज़' क्या है?

A

All three terms describe the same type of release; the choice depends only on marketing preferences तीनों शब्द एक ही प्रकार की रिलीज़ का वर्णन करते हैं; चुनाव केवल विपणन प्राथमिकताओं पर निर्भर करता है

B

Hotfix: emergency fix deployed immediately for critical production issue (bypassing normal release cycle); Patch release: bundled bug fixes following normal testing cycle; Minor release: backward-compatible new features plus bug fixes with full regression testing हॉटफ़िक्स: गंभीर उत्पादन समस्या के लिए तुरंत आपातकालीन फ़िक्स तैनात किया गया (सामान्य रिलीज़ चक्र को दरकिनार करते हुए); पैच रिलीज़: सामान्य परीक्षण चक्र के बाद बंडल बग फिक्स; लघु रिलीज़: पूर्ण प्रतिगमन परीक्षण के साथ बैकवर्ड-संगत नई सुविधाएँ और बग फिक्स

C

Hotfixes are only used for security vulnerabilities; patch releases only for performance issues हॉटफिक्स का उपयोग केवल सुरक्षा कमजोरियों के लिए किया जाता है; पैच केवल प्रदर्शन समस्याओं के लिए रिलीज़ होता है

D

Minor releases always break backward compatibility and require database schema migrations छोटी रिलीज़ हमेशा बैकवर्ड संगतता को तोड़ती है और डेटाबेस स्कीमा माइग्रेशन की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Release management distinguishes by urgency and scope. Hotfix: production is down or critically impaired — deploy in hours, test only the critical path, risk accepted. Patch: regular defect collection — weekly/monthly cadence, full regression suite. Minor: planned feature additions — full test cycle, release notes, migration guides for API consumers. Semantic versioning encodes these distinctions as MAJOR.MINOR.PATCH.

व्याख्या (हिन्दी) रिलीज प्रबंधन तात्कालिकता और दायरे के आधार पर अंतर करता है। हॉटफ़िक्स: उत्पादन कम है या गंभीर रूप से ख़राब है - घंटों में तैनात करें, केवल महत्वपूर्ण पथ का परीक्षण करें, जोखिम स्वीकार किया गया है। पैच: नियमित दोष संग्रहण - साप्ताहिक/मासिक ताल, पूर्ण प्रतिगमन सुइट। Minor: planned feature additions — full test cycle, release notes, migration guides for API consumers. सिमेंटिक वर्जनिंग इन भेदों को MAJOR.MINOR.PATCH के रूप में एन्कोड करता है।

2352

EN + हिं Easy

GB What is 'end-of-life' (EOL) planning in software maintenance and what risks does inadequate planning create?

IN सॉफ्टवेयर रखरखाव में 'एंड-ऑफ-लाइफ' (ईओएल) योजना क्या है और अपर्याप्त योजना क्या जोखिम पैदा करती है?

A

EOL planning decides which programming languages to deprecate in the next development cycle ईओएल योजना यह तय करती है कि अगले विकास चक्र में कौन सी प्रोग्रामिंग भाषाओं को अप्रचलित किया जाए

B

EOL planning defines the timeline and process for retiring a software system or version — inadequate planning leaves users on unsupported versions (no security patches), organisations paying maintenance for dead systems, and no migration path — creating compounding security and operational risk ईओएल योजना एक सॉफ्टवेयर सिस्टम या संस्करण को रिटायर करने के लिए समयरेखा और प्रक्रिया को परिभाषित करती है - अपर्याप्त योजना उपयोगकर्ताओं को असमर्थित संस्करणों (कोई सुरक्षा पैच नहीं) पर छोड़ देती है, संगठन मृत सिस्टम के लिए रखरखाव का भुगतान करते हैं, और कोई माइग्रेशन पथ नहीं - जटिल सुरक्षा और परिचालन जोखिम पैदा करता है

C

EOL planning only applies to hardware products; software can always be patched indefinitely ईओएल योजना केवल हार्डवेयर उत्पादों पर लागू होती है; सॉफ़्टवेयर को हमेशा अनिश्चित काल के लिए पैच किया जा सकता है

D

EOL planning is only the vendor's responsibility and requires no action from consuming organisations ईओएल योजना केवल विक्रेता की जिम्मेदारी है और उपभोक्ता संगठनों से किसी कार्रवाई की आवश्यकता नहीं है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Windows XP EOL (2014) left millions of systems unpatched — WannaCry ransomware (2017) specifically targeted them. Python 2 EOL (2020) left legacy systems running unsupported interpreters. EOL planning requires: advance notice to users, migration guides, overlap period where old and new versions coexist, and sunset of old version support. Organisations consuming EOL software must plan migrations before EOL dates, not after.

व्याख्या (हिन्दी) Windows XP EOL (2014) ने लाखों सिस्टमों को अप्रकाशित कर दिया - WannaCry रैंसमवेयर (2017) ने विशेष रूप से उन्हें लक्षित किया। पायथन 2 ईओएल (2020) ने विरासती सिस्टम को असमर्थित दुभाषियों के साथ चलाया। ईओएल योजना के लिए आवश्यक है: उपयोगकर्ताओं के लिए अग्रिम सूचना, माइग्रेशन गाइड, ओवरलैप अवधि जहां पुराने और नए संस्करण सह-अस्तित्व में हैं, और पुराने संस्करण के समर्थन की समाप्ति। ईओएल सॉफ़्टवेयर का उपभोग करने वाले संगठनों को ईओएल तिथियों से पहले माइग्रेशन की योजना बनानी चाहिए, उसके बाद नहीं।

2353

EN + हिं Easy

GB What is 'impact analysis' in software change management and what artefacts does it require?

IN सॉफ़्टवेयर परिवर्तन प्रबंधन में 'प्रभाव विश्लेषण' क्या है और इसके लिए किन कलाकृतियों की आवश्यकता है?

A

Impact analysis measures the financial cost of a software defect after production deployment प्रभाव विश्लेषण उत्पादन परिनियोजन के बाद सॉफ़्टवेयर दोष की वित्तीय लागत को मापता है

B

Impact analysis determines which system components, tests, documents, and dependent systems will be affected by a proposed change — requiring: design documentation, traceability matrices, dependency maps, and test coverage data to accurately scope change effects प्रभाव विश्लेषण यह निर्धारित करता है कि कौन से सिस्टम घटक, परीक्षण, दस्तावेज़ और आश्रित सिस्टम प्रस्तावित परिवर्तन से प्रभावित होंगे - आवश्यकता है: डिज़ाइन दस्तावेज़, ट्रैसेबिलिटी मैट्रिसेस, निर्भरता मानचित्र, और परिवर्तन प्रभावों को सटीक रूप से लागू करने के लिए कवरेज डेटा का परीक्षण करें।

C

Impact analysis is only required for changes that touch the database schema प्रभाव विश्लेषण केवल उन परिवर्तनों के लिए आवश्यक है जो डेटाबेस स्कीमा को छूते हैं

D

Modern refactoring tools perform impact analysis automatically, eliminating the need for documentation आधुनिक रीफैक्टरिंग उपकरण स्वचालित रूप से प्रभाव विश्लेषण करते हैं, जिससे दस्तावेज़ीकरण की आवश्यकता समाप्त हो जाती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Impact analysis prevents scope blindness: changing a function signature without knowing it's called by 47 modules leads to cascading compile errors. Thorough impact analysis answers: which tests must be updated? Which documents are now inaccurate? Which downstream systems consume this API? Which data migrations are needed? Without artefacts (design docs, traceability matrices), impact analysis degrades to guesswork.

व्याख्या (हिन्दी) प्रभाव विश्लेषण स्कोप ब्लाइंडनेस को रोकता है: किसी फ़ंक्शन हस्ताक्षर को 47 मॉड्यूल द्वारा कॉल किए जाने के बिना बदलने से कैस्केडिंग संकलन त्रुटियां होती हैं। संपूर्ण प्रभाव विश्लेषण उत्तर: कौन से परीक्षण अद्यतन किए जाने चाहिए? अब कौन से दस्तावेज़ ग़लत हैं? कौन से डाउनस्ट्रीम सिस्टम इस एपीआई का उपभोग करते हैं? कौन से डेटा माइग्रेशन की आवश्यकता है? कलाकृतियों (डिज़ाइन दस्तावेज़, ट्रैसेबिलिटी मैट्रिक्स) के बिना, प्रभाव विश्लेषण अनुमान लगाने में कम हो जाता है।

2354

EN + हिं Easy

GB What is 'software forensics' and in what maintenance scenarios is it applied?

IN 'सॉफ़्टवेयर फोरेंसिक' क्या है और इसे किस रखरखाव परिदृश्य में लागू किया जाता है?

A

Software forensics is the study of software patent infringement claims in legal disputes सॉफ़्टवेयर फोरेंसिक कानूनी विवादों में सॉफ़्टवेयर पेटेंट उल्लंघन के दावों का अध्ययन है

B

Software forensics applies investigative techniques to analyse software artefacts — applied in: intellectual property disputes (who wrote this code?), security incident response (how was the system breached?), understanding undocumented legacy systems, and malware analysis सॉफ़्टवेयर फोरेंसिक सॉफ़्टवेयर कलाकृतियों का विश्लेषण करने के लिए खोजी तकनीकों को लागू करता है - इसमें लागू किया जाता है: बौद्धिक संपदा विवाद (यह कोड किसने लिखा?), सुरक्षा घटना प्रतिक्रिया (सिस्टम का उल्लंघन कैसे हुआ?), अनिर्दिष्ट विरासत प्रणालियों को समझना, और मैलवेयर विश्लेषण

C

Software forensics is only used by law enforcement and has no application in normal software maintenance सॉफ़्टवेयर फोरेंसिक का उपयोग केवल कानून प्रवर्तन द्वारा किया जाता है और सामान्य सॉफ़्टवेयर रखरखाव में इसका कोई अनुप्रयोग नहीं है

D

Software forensics is identical to code review and the terms are interchangeable सॉफ़्टवेयर फोरेंसिक कोड समीक्षा के समान है और शर्तें विनिमेय हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Software forensics techniques: authorship analysis (stylometry of code to identify authors — used in IP disputes and plagiarism cases), binary analysis (malware reverse engineering), log analysis (security incident timeline reconstruction), and archaeological reconstruction (understanding undocumented legacy systems from their artefacts alone). These skills have grown in importance as code becomes a legal and security asset.

व्याख्या (हिन्दी) सॉफ्टवेयर फोरेंसिक तकनीक: लेखकत्व विश्लेषण (लेखकों की पहचान करने के लिए कोड की स्टाइलोमेट्री - आईपी विवादों और साहित्यिक चोरी के मामलों में उपयोग किया जाता है), बाइनरी विश्लेषण (मैलवेयर रिवर्स इंजीनियरिंग), लॉग विश्लेषण (सुरक्षा घटना समयरेखा पुनर्निर्माण), और पुरातात्विक पुनर्निर्माण (अकेले उनकी कलाकृतियों से अप्रलेखित विरासत प्रणालियों को समझना)। जैसे ही कोड एक कानूनी और सुरक्षा संपत्ति बन गया है, इन कौशलों का महत्व बढ़ गया है।

2355

EN + हिं Easy

GB What is 'configuration drift' in software maintenance and what practice prevents it in cloud environments?

IN सॉफ़्टवेयर रखरखाव में 'कॉन्फ़िगरेशन बहाव' क्या है और क्लाउड वातावरण में कौन सी प्रथा इसे रोकती है?

A

Configuration drift refers to software version numbers diverging across development and production कॉन्फ़िगरेशन ड्रिफ्ट का तात्पर्य विकास और उत्पादन में भिन्न होने वाले सॉफ़्टवेयर संस्करण संख्याओं से है

B

Configuration drift occurs when infrastructure/application configuration diverges from its documented or intended state due to manual changes — prevented by Infrastructure as Code (IaC) with enforced immutable infrastructure and regular compliance scanning कॉन्फ़िगरेशन बहाव तब होता है जब बुनियादी ढांचे/एप्लिकेशन कॉन्फ़िगरेशन मैन्युअल परिवर्तनों के कारण अपने दस्तावेज़ या इच्छित स्थिति से अलग हो जाता है - लागू अपरिवर्तनीय बुनियादी ढांचे और नियमित अनुपालन स्कैनिंग के साथ इंफ्रास्ट्रक्चर एज़ कोड (IaC) द्वारा रोका जाता है

C

Configuration drift only occurs in on-premise systems; cloud environments are immune to it कॉन्फ़िगरेशन बहाव केवल ऑन-प्रिमाइसेस सिस्टम में होता है; बादल का वातावरण इसके प्रति प्रतिरक्षित है

D

Configuration drift is unavoidable and can only be managed by complete system rebuilds quarterly कॉन्फ़िगरेशन बहाव अपरिहार्य है और इसे केवल त्रैमासिक पूर्ण सिस्टम पुनर्निर्माण द्वारा ही प्रबंधित किया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Configuration drift: server A has nginx 1.14 (patched manually last year), server B has 1.18, server C has 1.12 — 'what should it be?' is unknown. Security patches may have been missed. IaC (Terraform, Ansible) defines desired state as code; CI/CD applies it consistently. Immutable infrastructure replaces rather than modifies servers, eliminating the possibility of manual drift. AWS Config and Azure Policy continuously scan for non-compliant configurations.

व्याख्या (हिन्दी) कॉन्फ़िगरेशन बहाव: सर्वर A में nginx 1.14 है (पिछले वर्ष मैन्युअल रूप से पैच किया गया), सर्वर B में 1.18 है, सर्वर C में 1.12 है - 'यह क्या होना चाहिए?' अज्ञात है. हो सकता है सुरक्षा पैच छूट गए हों. IaC (टेराफॉर्म, एन्सिबल) वांछित स्थिति को कोड के रूप में परिभाषित करता है; सीआई/सीडी इसे लगातार लागू करता है। अपरिवर्तनीय बुनियादी ढांचा सर्वर को संशोधित करने के बजाय प्रतिस्थापित करता है, जिससे मैन्युअल बहाव की संभावना समाप्त हो जाती है। AWS कॉन्फ़िगरेशन और Azure नीति गैर-अनुपालक कॉन्फ़िगरेशन के लिए लगातार स्कैन करते हैं।

Software Engineering — MCQ Practice