Software Engineering — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 2726 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2726 questions
2581
EN + हिं Easy
GB What is 'printf debugging' and what is its key limitation that debugger-based debugging overcomes?
IN 'प्रिंटफ डिबगिंग' क्या है और इसकी प्रमुख सीमा क्या है जिसे डिबगर-आधारित डिबगिंग खत्म कर देती है?
A
Printf debugging is a deprecated technique never used by professional software engineers प्रिंटफ़ डिबगिंग एक अप्रचलित तकनीक है जिसका उपयोग पेशेवर सॉफ़्टवेयर इंजीनियरों द्वारा कभी नहीं किया जाता है
B
Printf debugging inserts print statements to observe execution state — its key limitation is that it requires code modification and recompilation for each investigation step and cannot interactively explore state at runtime; debuggers allow inspection without code changes प्रिंटफ डिबगिंग निष्पादन स्थिति का निरीक्षण करने के लिए प्रिंट स्टेटमेंट सम्मिलित करता है - इसकी मुख्य सीमा यह है कि इसमें प्रत्येक जांच चरण के लिए कोड संशोधन और पुनर्संकलन की आवश्यकता होती है और रनटाइम पर इंटरैक्टिव रूप से स्थिति का पता नहीं लगाया जा सकता है; डिबगर्स कोड परिवर्तन के बिना निरीक्षण की अनुमति देते हैं
C
Printf debugging is superior to debuggers for multithreaded programs because it is non-intrusive प्रिंटफ डिबगिंग मल्टीथ्रेडेड प्रोग्राम के लिए डिबगर्स से बेहतर है क्योंकि यह गैर-घुसपैठकारी है
D
Printf debugging is only possible in languages with a built-in print function Printf डिबगिंग केवल अंतर्निहित प्रिंट फ़ंक्शन वाली भाषाओं में ही संभव है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Printf debugging is actually widely used even by experienced engineers — especially in distributed systems where attaching a debugger is impractical. Its limitation: each new piece of information requires a code change, rebuild, and redeploy cycle. Debuggers allow interactive inspection of any variable, stack frame, or memory address without touching the code — enabling much faster investigation cycles for local bugs.
व्याख्या (हिन्दी) प्रिंटफ डिबगिंग वास्तव में अनुभवी इंजीनियरों द्वारा भी व्यापक रूप से उपयोग किया जाता है - विशेष रूप से वितरित सिस्टम में जहां डिबगर संलग्न करना अव्यावहारिक है। इसकी सीमा: प्रत्येक नई जानकारी के लिए कोड परिवर्तन, पुनर्निर्माण और पुन: तैनाती चक्र की आवश्यकता होती है। डिबगर्स कोड को छुए बिना किसी भी वेरिएबल, स्टैक फ्रेम या मेमोरी एड्रेस के इंटरैक्टिव निरीक्षण की अनुमति देते हैं - स्थानीय बग के लिए बहुत तेज़ जांच चक्र सक्षम करते हैं।
2582
EN + हिं Medium
GB What is 'snapshot debugging' and how does it differ from traditional live debugging?
IN 'स्नैपशॉट डिबगिंग' क्या है और यह पारंपरिक लाइव डिबगिंग से कैसे भिन्न है?
A
Snapshot debugging creates database backups at regular intervals during development स्नैपशॉट डिबगिंग विकास के दौरान नियमित अंतराल पर डेटाबेस बैकअप बनाता है
B
Snapshot debugging captures a complete program state snapshot at the point of failure (variables, call stack, heap) without pausing execution — allowing post-hoc investigation without interrupting service; traditional debugging pauses execution interactively but requires the process to be running स्नैपशॉट डिबगिंग निष्पादन को रोके बिना विफलता के बिंदु (वेरिएबल, कॉल स्टैक, हीप) पर एक पूर्ण प्रोग्राम स्थिति स्नैपशॉट कैप्चर करता है - सेवा में बाधा डाले बिना पोस्ट-हॉक जांच की अनुमति देता है; पारंपरिक डिबगिंग अंतःक्रियात्मक रूप से निष्पादन को रोकती है लेकिन प्रक्रिया को चालू रखने की आवश्यकता होती है
C
Snapshot debugging is identical to core dump analysis and both terms describe the same technique स्नैपशॉट डिबगिंग कोर डंप विश्लेषण के समान है और दोनों शब्द एक ही तकनीक का वर्णन करते हैं
D
Snapshot debugging is only available in cloud platforms like Azure and AWS स्नैपशॉट डिबगिंग केवल Azure और AWS जैसे क्लाउड प्लेटफ़ॉर्म में उपलब्ध है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Tools like Visual Studio Snapshot Debugger (Azure), Lightrun, and Rookout enable production debugging by capturing full execution context when a specific line is hit — without stopping the process. This solves the production debugging paradox: traditional debuggers interrupt service; logging lacks detail; snapshot debugging captures complete state non-intrusively. Developers can inspect any variable value at the failure point hours after it occurred.
व्याख्या (हिन्दी) विज़ुअल स्टूडियो स्नैपशॉट डिबगर (एज़्योर), लाइटरन और रूकआउट जैसे उपकरण प्रक्रिया को रोके बिना, एक विशिष्ट लाइन हिट होने पर पूर्ण निष्पादन संदर्भ को कैप्चर करके उत्पादन डिबगिंग को सक्षम करते हैं। यह उत्पादन डिबगिंग विरोधाभास को हल करता है: पारंपरिक डिबगर्स सेवा को बाधित करते हैं; लॉगिंग में विवरण का अभाव है; स्नैपशॉट डिबगिंग पूरी स्थिति को बिना किसी हस्तक्षेप के कैप्चर करता है। डेवलपर्स किसी भी वैरिएबल मान का उसके घटित होने के कुछ घंटों बाद विफलता बिंदु पर निरीक्षण कर सकते हैं।
2583
EN + हिं Easy
GB What is 'differential debugging' and when is it most effectively applied?
IN 'डिफ़रेंशियल डिबगिंग' क्या है और इसे सबसे प्रभावी ढंग से कब लागू किया जाता है?
A
Differential debugging compares two developers' implementations of the same function डिफरेंशियल डिबगिंग एक ही फ़ंक्शन के दो डेवलपर्स के कार्यान्वयन की तुलना करती है
B
Differential debugging compares two configurations that exhibit different behaviour (buggy vs working, version A vs version B) — systematically varying one factor at a time to identify which difference causes the fault; most effective when a regression is known to exist between two states डिफरेंशियल डिबगिंग दो कॉन्फ़िगरेशन की तुलना करती है जो अलग-अलग व्यवहार प्रदर्शित करती है (छोटी गाड़ी बनाम काम करना, संस्करण ए बनाम संस्करण बी) - यह पहचानने के लिए कि कौन सा अंतर गलती का कारण बनता है, एक समय में व्यवस्थित रूप से एक कारक को बदलता है; सबसे प्रभावी तब होता है जब दो राज्यों के बीच एक प्रतिगमन मौजूद होता है
C
Differential debugging is a formal verification technique requiring mathematical proofs डिफरेंशियल डिबगिंग एक औपचारिक सत्यापन तकनीक है जिसके लिए गणितीय प्रमाण की आवश्यकता होती है
D
Differential debugging can only be applied to database query performance problems विभेदक डिबगिंग केवल डेटाबेस क्वेरी प्रदर्शन समस्याओं पर लागू की जा सकती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) 'It worked yesterday, it doesn't today' — differential debugging is perfect here. git bisect performs differential debugging across commits. Environmental differential: 'works on my machine, fails on staging' — systematically compare OS, JVM version, library versions, environment variables, network configuration until the differing factor is found. The hypothesis: 'if X is the same in both environments, X is not the cause.'
व्याख्या (हिन्दी) 'इसने कल काम किया, आज नहीं किया' - यहां डिफरेंशियल डिबगिंग एकदम सही है। git bisect पूरे कमिट में डिफरेंशियल डिबगिंग करता है। पर्यावरणीय अंतर: 'मेरी मशीन पर काम करता है, स्टेजिंग पर विफल रहता है' - भिन्न कारक मिलने तक व्यवस्थित रूप से ओएस, जेवीएम संस्करण, लाइब्रेरी संस्करण, पर्यावरण चर, नेटवर्क कॉन्फ़िगरेशन की तुलना करें। परिकल्पना: 'यदि X दोनों वातावरणों में समान है, तो X इसका कारण नहीं है।'
2584
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) एक विशिष्ट त्रुटि संदेश प्रदान करता है जो जांच के समय को समाप्त कर देता है। यह एक बार के फिक्स को स्थायी गार्ड में बदल देता है।
2585
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 पर क्रैश हो जाती है। पारंपरिक डिबगिंग: क्रैश ढूंढें, मैन्युअल रूप से पीछे की ओर कदम बढ़ाएं। समय-यात्रा: दूषित मेमोरी पते पर वॉचपॉइंट सेट करें और पीछे की ओर चलाएं - भ्रष्टाचार होने पर डिबगर ठीक से बंद हो जाता है। यह डिबगिंग की सबसे कठिन समस्याओं में से एक को समाप्त करता है: बड़े निष्पादन अंतरालों के कारण प्रभावों का पता लगाना।
2586
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.
व्याख्या (हिन्दी) डिबगबिलिटी एक डिज़ाइन गुणवत्ता है जिसके लिए योजना बनाई जानी चाहिए, बाद में नहीं जोड़ी जानी चाहिए। निर्णय जो डिबगबिलिटी को नुकसान पहुंचाते हैं: अपवादों को चुपचाप निगलना, सामान्य त्रुटि संदेशों ('एक त्रुटि हुई') का उपयोग करना, सहसंबंध आईडी के बिना एसिंक ऑपरेशंस को आग लगाना और भूल जाना, बिना लॉगिंग के गहराई से नेस्टेड कॉल चेन। प्रत्येक उस निशान को हटाता है जो गलती की ओर ले जाता है। नेटफ्लिक्स, गूगल और अमेज़ॅन स्पष्ट रूप से एक सिस्टम प्रॉपर्टी के रूप में डिबगबिलिटी के लिए डिज़ाइन करते हैं।
2587
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वीं कॉल पर ट्रिगर), और लॉगप्वाइंट (बिना रुके लॉग) का समर्थन करते हैं - ये कई अवलोकन बिंदुओं को प्रबंधित करने के संज्ञानात्मक भार को कम करते हैं।
2588
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.
व्याख्या (हिन्दी) शॉटगन डिबगिंग: सब कुछ एक बार में बदलें और देखें कि क्या यह काम करता है - यह कारण को बरकरार रखते हुए लक्षण को ठीक कर सकता है, या संबंधित दोष को छिपाते हुए भाग्य से ठीक कर सकता है। वैज्ञानिक डिबगिंग: 'मेरी परिकल्पना: बग एक्स के कारण होता है। मैं केवल एक्स को बदलूंगा और निरीक्षण करूंगा। नतीजा: अभी भी टूटा हुआ. नई परिकल्पना: वाई.' प्रत्येक प्रयोग न्यूनतम और पृथक है, साक्ष्य को संरक्षित करता है और गलती के स्थान को व्यवस्थित रूप से सीमित करता है।
2589
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 के लिए सभी लॉग फ़िल्टर कर सकते हैं। ओपनटेलीमेट्री इस प्रसार को मानकीकृत करती है।
2590
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++ कोड गुणवत्ता के लिए आवश्यक उपकरण हैं।
2591
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 तक पहुंचता है और कोई डिबगर संलग्न नहीं है, तो यह क्रैश हो जाता है (एंटी-सैंडबॉक्स); यदि कोई डिबगर इसे पकड़ लेता है, तो मैलवेयर व्यवहार बदल देता है (एंटी-एनालिसिस)। उत्पादन परिनियोजन से पहले डिबग कलाकृतियों के लिए सुरक्षा-संवेदनशील कोड का ऑडिट किया जाना चाहिए।
2592
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 का चौथा रखरखाव प्रकार, बाद में जोड़ा गया) विफलताओं का कारण बनने से पहले ज्ञात रखरखाव जोखिमों को संबोधित करता है: स्पेगेटी कोड का पुनर्गठन, अप्रचलित निर्भरता को अपडेट करना, उच्च जोखिम वाले मॉड्यूल में परीक्षण कवरेज में सुधार करना। परफेक्ट रखरखाव नई सुविधाओं या प्रदर्शन में सुधार के लिए उपयोगकर्ता के अनुरोधों का जवाब देता है। निवारक सक्रिय आंतरिक गुणवत्ता निवेश है; परफेक्ट प्रतिक्रियाशील बाह्य मूल्य वितरण है।
2593
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.
व्याख्या (हिन्दी) बीएसए (बिजनेस सॉफ्टवेयर एलायंस) ऑडिट के परिणामस्वरूप बिना लाइसेंस वाले सॉफ्टवेयर चलाने वाली कंपनियों के लिए कई मिलियन डॉलर का निपटान हुआ है। इसके विपरीत, संगठन नियमित रूप से उपयोग की तुलना में 30% अधिक लाइसेंस के लिए भुगतान करते हैं। सॉफ़्टवेयर परिसंपत्ति प्रबंधन (आईएसओ 19770) लाइसेंस व्यय को अनुकूलित करने, अनुपालन सुनिश्चित करने और एक पैच किए गए, समर्थित सॉफ़्टवेयर संपदा को बनाए रखने के लिए आवश्यक सूची, पात्रता और उपयोग डेटा प्रदान करता है।
2594
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.
व्याख्या (हिन्दी) रिलीज प्रबंधन तात्कालिकता और दायरे के आधार पर अंतर करता है। हॉटफ़िक्स: उत्पादन कम है या गंभीर रूप से ख़राब है - घंटों में तैनात करें, केवल महत्वपूर्ण पथ का परीक्षण करें, जोखिम स्वीकार किया गया है। पैच: नियमित दोष संग्रहण - साप्ताहिक/मासिक ताल, पूर्ण प्रतिगमन सुइट। लघु: नियोजित सुविधा परिवर्धन - पूर्ण परीक्षण चक्र, रिलीज़ नोट्स, एपीआई उपभोक्ताओं के लिए माइग्रेशन गाइड। सिमेंटिक वर्जनिंग इन भेदों को MAJOR.MINOR.PATCH के रूप में एन्कोड करता है।
2595
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) ने विरासती सिस्टम को असमर्थित दुभाषियों के साथ चलाया। ईओएल योजना के लिए आवश्यक है: उपयोगकर्ताओं के लिए अग्रिम सूचना, माइग्रेशन गाइड, ओवरलैप अवधि जहां पुराने और नए संस्करण सह-अस्तित्व में हैं, और पुराने संस्करण के समर्थन की समाप्ति। ईओएल सॉफ़्टवेयर का उपभोग करने वाले संगठनों को ईओएल तिथियों से पहले माइग्रेशन की योजना बनानी चाहिए, उसके बाद नहीं।
2581–2595 of 2726