526

EN + हिं Easy

GB What is the 'shift-left' testing philosophy and what measurable quality improvement does it deliver?

IN 'शिफ्ट-लेफ्ट' परीक्षण दर्शन क्या है और यह किस मापनीय गुणवत्ता में सुधार प्रदान करता है?

A

Shift-left testing means moving all testing activities to a dedicated test team at project start शिफ्ट-लेफ्ट परीक्षण का अर्थ है प्रोजेक्ट प्रारंभ में सभी परीक्षण गतिविधियों को एक समर्पित परीक्षण टीम में ले जाना

B

Shift-left moves testing activities earlier in the development lifecycle — starting testing at requirements (inspections, test planning) and design (design reviews, testability assessment) rather than after implementation, reducing defect cost by catching them at their cheapest fix point शिफ्ट-लेफ्ट परीक्षण गतिविधियों को विकास जीवनचक्र में पहले ले जाता है - कार्यान्वयन के बजाय आवश्यकताओं (निरीक्षण, परीक्षण योजना) और डिज़ाइन (डिज़ाइन समीक्षा, परीक्षण क्षमता मूल्यांकन) पर परीक्षण शुरू करना, दोष लागत को उनके सबसे सस्ते फिक्स बिंदु पर पकड़कर कम करना

C

Shift-left testing eliminates the need for dedicated QA teams by making developers responsible for all quality शिफ्ट-लेफ्ट परीक्षण डेवलपर्स को सभी गुणवत्ता के लिए जिम्मेदार बनाकर समर्पित क्यूए टीमों की आवश्यकता को समाप्त कर देता है

D

Shift-left only applies to unit testing; system and acceptance testing cannot be shifted left शिफ्ट-लेफ्ट केवल यूनिट परीक्षण पर लागू होता है; सिस्टम और स्वीकृति परीक्षण को बाईं ओर स्थानांतरित नहीं किया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Boehm's cost-of-change curve makes the ROI clear: defects found in requirements cost 1x; in testing cost 40-100x; in production cost 100-200x. Shift-left practices (requirements inspections, design reviews, static analysis, TDD) systematically move detection to the left side of the curve. IBM, HP, and NASA studies all show 10:1+ ROI from early defect detection versus late.

व्याख्या (हिन्दी) बोहेम का परिवर्तन लागत वक्र आरओआई को स्पष्ट करता है: आवश्यकताओं में पाए गए दोषों की लागत 1x है; परीक्षण लागत में 40-100x; उत्पादन लागत में 100-200x. शिफ्ट-लेफ्ट प्रथाएं (आवश्यकताओं का निरीक्षण, डिजाइन समीक्षा, स्थैतिक विश्लेषण, टीडीडी) व्यवस्थित रूप से पता लगाने को वक्र के बाईं ओर ले जाती हैं। आईबीएम, एचपी और नासा के सभी अध्ययन दोष का जल्दी पता लगाने की तुलना में देर से पता लगाने से 10:1+ आरओआई दर्शाते हैं।

527

EN + हिं Easy

GB What is 'testing in production' (TiP) and what risk controls make it safe?

IN 'उत्पादन में परीक्षण' (टीआईपी) क्या है और कौन से जोखिम नियंत्रण इसे सुरक्षित बनाते हैं?

A

Testing in production means deliberately deploying buggy code to observe real user failures उत्पादन में परीक्षण का अर्थ है वास्तविक उपयोगकर्ता विफलताओं का निरीक्षण करने के लिए जानबूझकर बग्गी कोड को तैनात करना

B

TiP runs tests/experiments against real production traffic using real user data — safe through: canary releases (1% traffic first), feature flags (instant rollback), dark launches (run new code without returning its results), and monitoring/alerting to detect anomalies before full rollout TiP वास्तविक उपयोगकर्ता डेटा का उपयोग करके वास्तविक उत्पादन ट्रैफ़िक के विरुद्ध परीक्षण/प्रयोग चलाता है - इसके माध्यम से सुरक्षित: कैनरी रिलीज़ (पहले 1% ट्रैफ़िक), फ़ीचर फ़्लैग (तत्काल रोलबैक), डार्क लॉन्च (इसके परिणाम लौटाए बिना नया कोड चलाना), और पूर्ण रोलआउट से पहले विसंगतियों का पता लगाने के लिए निगरानी/चेतावनी

C

Testing in production is universally prohibited because it risks data corruption for real users उत्पादन में परीक्षण सार्वभौमिक रूप से निषिद्ध है क्योंकि इससे वास्तविक उपयोगकर्ताओं के लिए डेटा भ्रष्टाचार का जोखिम होता है

D

TiP only works for read-only operations; write operations can never be tested in production TiP केवल रीड-ओनली ऑपरेशंस के लिए काम करता है; लेखन संचालन का उत्पादन में कभी भी परीक्षण नहीं किया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Pre-production environments can never perfectly replicate production: real data volumes, real usage patterns, real hardware failures. Netflix, Facebook, and LinkedIn deliberately test in production because that's where reality is. Safety controls: canary release gradually exposes new code; feature flags enable instant disable; dark launches run code without serving results; observability catches anomalies before widespread impact.

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

528

EN + हिं Medium

GB What is 'test impact analysis' and how does it use code change information to optimise CI test selection?

IN 'परीक्षण प्रभाव विश्लेषण' क्या है और यह सीआई परीक्षण चयन को अनुकूलित करने के लिए कोड परिवर्तन जानकारी का उपयोग कैसे करता है?

A

Test impact analysis evaluates the business impact of defects found during testing परीक्षण प्रभाव विश्लेषण परीक्षण के दौरान पाए गए दोषों के व्यावसायिक प्रभाव का मूल्यांकन करता है

B

Test impact analysis instruments the test suite to record which source files each test exercises, then on each commit selects only tests whose coverage intersects with changed files — running only tests that could possibly be affected by the specific code changes परीक्षण प्रभाव विश्लेषण उपकरण परीक्षण सूट को रिकॉर्ड करता है कि कौन सा स्रोत प्रत्येक परीक्षण अभ्यास को फाइल करता है, फिर प्रत्येक कमिट पर केवल उन परीक्षणों का चयन करता है जिनकी कवरेज बदली हुई फाइलों के साथ प्रतिच्छेद करती है - केवल ऐसे परीक्षण चला रहे हैं जो संभवतः विशिष्ट कोड परिवर्तनों से प्रभावित हो सकते हैं

C

Test impact analysis is only possible in compiled languages; dynamic languages cannot support it परीक्षण प्रभाव विश्लेषण केवल संकलित भाषाओं में ही संभव है; गतिशील भाषाएँ इसका समर्थन नहीं कर सकतीं

D

Test impact analysis always runs fewer tests but provides lower confidence than running all tests परीक्षण प्रभाव विश्लेषण हमेशा कम परीक्षण चलाता है लेकिन सभी परीक्षण चलाने की तुलना में कम आत्मविश्वास प्रदान करता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Microsoft's research on test impact analysis (TABIA) showed 95%+ reduction in tests run per commit while maintaining near-identical defect detection rates for Microsoft Office. By mapping each test to its covered source files, when only File A changes, only tests that touch File A need to run. This makes CI feedback 10-100x faster without sacrificing safety.

व्याख्या (हिन्दी) परीक्षण प्रभाव विश्लेषण (टीएबीआईए) पर माइक्रोसॉफ्ट के शोध ने माइक्रोसॉफ्ट ऑफिस के लिए लगभग समान दोष पहचान दरों को बनाए रखते हुए प्रति कमिट किए गए परीक्षणों में 95%+ की कमी दिखाई। प्रत्येक परीक्षण को उसकी कवर की गई स्रोत फ़ाइलों में मैप करके, जब केवल फ़ाइल ए बदलती है, तो केवल फ़ाइल ए को छूने वाले परीक्षणों को चलाने की आवश्यकता होती है। यह सुरक्षा से समझौता किए बिना सीआई फीडबैक को 10-100 गुना तेज बनाता है।

529

EN + हिं Medium

GB What is 'flaky test' and why is it considered more damaging to CI effectiveness than a simply failing test?

IN 'परतदार परीक्षण' क्या है और इसे केवल असफल परीक्षण की तुलना में सीआई प्रभावशीलता के लिए अधिक हानिकारक क्यों माना जाता है?

A

Flaky tests are tests written by junior developers that have poor assertions फ़्लैकी परीक्षण जूनियर डेवलपर्स द्वारा लिखे गए परीक्षण हैं जिनका दावा ख़राब है

B

A flaky test non-deterministically passes or fails for the same code — more damaging than a consistently failing test because it trains developers to ignore CI failures ('it's probably flaky') rather than investigate, eroding the entire team's trust in the CI safety net एक परतदार परीक्षण गैर-नियतात्मक रूप से एक ही कोड के लिए पास या विफल हो जाता है - लगातार विफल होने वाले परीक्षण से अधिक हानिकारक क्योंकि यह डेवलपर्स को जांच करने के बजाय सीआई विफलताओं ('यह शायद परतदार है') को नजरअंदाज करने के लिए प्रशिक्षित करता है, जिससे सीआई सुरक्षा जाल में पूरी टीम का भरोसा खत्म हो जाता है।

C

Flaky tests are only a problem in JavaScript test frameworks like Jest and Mocha परतदार परीक्षण केवल जेस्ट और मोचा जैसे जावास्क्रिप्ट परीक्षण ढांचे में एक समस्या है

D

Flaky tests can be safely ignored if they pass more than 90% of the time statistically यदि परतदार परीक्षण सांख्यिकीय रूप से 90% से अधिक समय पास कर लेते हैं, तो उन्हें सुरक्षित रूप से अनदेखा किया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Google identified flaky tests as one of the biggest threats to CI effectiveness. When tests fail randomly, developers stop rerunning them to verify — they just rerun hoping it passes, or ignore failures. This 'cry wolf' effect means real regressions are ignored alongside flaky false alarms. Google quarantines flaky tests (removes from blocking CI) and requires immediate fix — treating flakiness as a P1 defect.

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

530

EN + हिं Medium

GB What is 'test-driven infrastructure' (TDI) in DevOps and how does it extend the TDD principle?

IN DevOps में 'परीक्षण-संचालित बुनियादी ढांचा' (TDI) क्या है और यह TDD सिद्धांत का विस्तार कैसे करता है?

A

TDI means writing unit tests for infrastructure deployment scripts only टीडीआई का मतलब केवल बुनियादी ढांचा परिनियोजन स्क्रिप्ट के लिए यूनिट परीक्षण लिखना है

B

TDI applies TDD to infrastructure code: tests for server configuration, network policies, and deployment scripts are written first (using tools like ServerSpec, InSpec, Terraform test) — verifying infrastructure behaves as specified before and after changes, exactly as TDD verifies application code टीडीआई इन्फ्रास्ट्रक्चर कोड पर टीडीडी लागू करता है: सर्वर कॉन्फ़िगरेशन, नेटवर्क नीतियों और परिनियोजन स्क्रिप्ट के लिए परीक्षण पहले लिखे जाते हैं (सर्वरस्पेक, इनस्पेक, टेराफॉर्म टेस्ट जैसे टूल का उपयोग करके) - इन्फ्रास्ट्रक्चर की पुष्टि करना परिवर्तनों से पहले और बाद में निर्दिष्ट व्यवहार करता है, ठीक उसी तरह जैसे टीडीडी एप्लिकेशन कोड को सत्यापित करता है

C

TDI replaces all monitoring and alerting in production with pre-deployment tests टीडीआई उत्पादन में सभी निगरानी और चेतावनी को पूर्व-परिनियोजन परीक्षणों से बदल देता है

D

TDI only applies to containerised environments using Kubernetes and Docker टीडीआई केवल कुबेरनेट्स और डॉकर का उपयोग करके कंटेनरीकृत वातावरण पर लागू होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Infrastructure as Code (Terraform, Ansible, Puppet) is real code and shares application code's failure modes: untested changes break production. TDI writes tests like 'port 443 must be open', 'service X must be running', 'this file must have permissions 600' before changing infrastructure. The CI pipeline runs these tests against actual (test environment) infrastructure, catching misconfigurations before production deployment.

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

531

EN + हिं

GB What is 'core dump analysis' and what specific class of production bugs can only be diagnosed this way?

IN 'कोर डंप विश्लेषण' क्या है और उत्पादन बग के किस विशिष्ट वर्ग का निदान केवल इस तरह से किया जा सकता है?

A

Core dump analysis reconstructs the project requirements from binary deployment artifacts कोर डंप विश्लेषण बाइनरी परिनियोजन कलाकृतियों से परियोजना आवश्यकताओं का पुनर्निर्माण करता है

B

Core dump analysis examines the saved memory state at the moment of a crash — uniquely diagnosing bugs that only manifest in production under specific data/load conditions and disappear when a debugger is attached (Heisenbugs) or the environment is changed कोर डंप विश्लेषण क्रैश के समय सहेजी गई मेमोरी स्थिति की जांच करता है - विशिष्ट रूप से बग का निदान करता है जो केवल विशिष्ट डेटा/लोड स्थितियों के तहत उत्पादन में प्रकट होते हैं और डिबगर संलग्न होने पर गायब हो जाते हैं (हेइज़नबग्स) या पर्यावरण बदल जाता है

C

Core dump analysis only works for programs written in C and C++ कोर डंप विश्लेषण केवल C और C++ में लिखे गए प्रोग्रामों के लिए काम करता है

D

Core dumps are too large to be practically useful; log analysis is always superior कोर डंप व्यावहारिक रूप से उपयोगी होने के लिए बहुत बड़े हैं; लॉग विश्लेषण हमेशा बेहतर होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) GDB, LLDB, and WinDbg can load core dumps to inspect the exact memory state: call stack at crash, values of all variables, heap contents. This diagnoses: null pointer dereferences (what was the null pointer? which object should it have pointed to?), stack overflows (what is the call chain that caused the stack exhaustion?), and data corruption (what value was written where it shouldn't have been?).

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

532

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.

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

533

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वीं कॉल पर ट्रिगर), और लॉगप्वाइंट (बिना रुके लॉग) का समर्थन करते हैं - ये कई अवलोकन बिंदुओं को प्रबंधित करने के संज्ञानात्मक भार को कम करते हैं।

534

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 तक पहुंचता है और कोई डिबगर संलग्न नहीं है, तो यह क्रैश हो जाता है (एंटी-सैंडबॉक्स); यदि कोई डिबगर इसे पकड़ लेता है, तो मैलवेयर व्यवहार बदल देता है (एंटी-एनालिसिस)। उत्पादन परिनियोजन से पहले डिबग कलाकृतियों के लिए सुरक्षा-संवेदनशील कोड का ऑडिट किया जाना चाहिए।

535

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) लाइसेंस व्यय को अनुकूलित करने, अनुपालन सुनिश्चित करने और एक पैच किए गए, समर्थित सॉफ़्टवेयर संपदा को बनाए रखने के लिए आवश्यक सूची, पात्रता और उपयोग डेटा प्रदान करता है।

536

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

537

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.

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

538

EN + हिं Easy

GB What is 'technical obsolescence' and what three strategic responses are available to organisations facing it?

IN 'तकनीकी अप्रचलन' क्या है और इसका सामना करने वाले संगठनों के लिए कौन सी तीन रणनीतिक प्रतिक्रियाएँ उपलब्ध हैं?

A

Technical obsolescence is when a software system is no longer needed by its users तकनीकी अप्रचलन तब होता है जब किसी सॉफ़्टवेयर सिस्टम की उसके उपयोगकर्ताओं को आवश्यकता नहीं रह जाती है

B

Technical obsolescence occurs when a system's technology stack (OS, language, framework) reaches EOL with no vendor support — responses: 1) wrapping (add API layer, extend lifespan), 2) migration (port to modern platform), 3) replacement (rewrite or buy replacement system) तकनीकी अप्रचलन तब होता है जब किसी सिस्टम का प्रौद्योगिकी स्टैक (ओएस, भाषा, ढांचा) बिना किसी विक्रेता समर्थन के ईओएल तक पहुंच जाता है - प्रतिक्रियाएं: 1) रैपिंग (एपीआई परत जोड़ें, जीवनकाल बढ़ाएं), 2) माइग्रेशन (आधुनिक प्लेटफॉर्म पर पोर्ट), 3) प्रतिस्थापन (प्रतिस्थापन सिस्टम को फिर से लिखें या खरीदें)

C

Technical obsolescence always requires immediate system replacement — no other response is viable तकनीकी अप्रचलन के लिए हमेशा तत्काल सिस्टम प्रतिस्थापन की आवश्यकता होती है - कोई अन्य प्रतिक्रिया व्यवहार्य नहीं है

D

Technical obsolescence is solved automatically by containerisation technologies like Docker तकनीकी अप्रचलन को डॉकर जैसी कंटेनरीकरण प्रौद्योगिकियों द्वारा स्वचालित रूप से हल किया जाता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Wrapping: expose a REST API over a legacy COBOL system — the internals stay unchanged but modern consumers can integrate. Migration: port .NET Framework 4.5 to .NET 6 — same language, major platform modernisation. Replacement: the mainframe is strategically replaced with a cloud-native system over 5 years using strangler fig. Each has different cost, risk, and timeline profiles — the choice depends on business value of the system, available skills, and risk tolerance.

व्याख्या (हिन्दी) रैपिंग: एक पुराने COBOL सिस्टम पर REST API को उजागर करें - आंतरिक अपरिवर्तित रहते हैं लेकिन आधुनिक उपभोक्ता एकीकृत कर सकते हैं। माइग्रेशन: पोर्ट .NET फ्रेमवर्क 4.5 से .NET 6 - समान भाषा, प्रमुख प्लेटफ़ॉर्म आधुनिकीकरण। प्रतिस्थापन: स्ट्रैंगलर अंजीर का उपयोग करके 5 वर्षों में मेनफ्रेम को रणनीतिक रूप से क्लाउड-नेटिव सिस्टम से बदल दिया गया है। प्रत्येक की अलग-अलग लागत, जोखिम और समयरेखा प्रोफ़ाइल होती है - चुनाव सिस्टम के व्यावसायिक मूल्य, उपलब्ध कौशल और जोखिम सहनशीलता पर निर्भर करता है।

539

EN + हिं Medium

GB What is 'software composition analysis' (SCA) and why is it a critical maintenance practice for modern applications?

IN 'सॉफ़्टवेयर संरचना विश्लेषण' (एससीए) क्या है और यह आधुनिक अनुप्रयोगों के लिए एक महत्वपूर्ण रखरखाव अभ्यास क्यों है?

A

SCA analyses whether the software meets its functional requirements after each deployment एससीए विश्लेषण करता है कि सॉफ्टवेयर प्रत्येक तैनाती के बाद अपनी कार्यात्मक आवश्यकताओं को पूरा करता है या नहीं

B

SCA inventories all third-party open-source dependencies and checks them against vulnerability databases (CVE/NVD) — critical because modern applications are 80%+ open-source code, meaning unpatched dependencies are the primary attack vector (Log4Shell, Spring4Shell) एससीए सभी तृतीय-पक्ष ओपन-सोर्स निर्भरताओं की सूची बनाता है और उन्हें भेद्यता डेटाबेस (सीवीई/एनवीडी) के विरुद्ध जांचता है - महत्वपूर्ण है क्योंकि आधुनिक एप्लिकेशन 80%+ ओपन-सोर्स कोड हैं, जिसका अर्थ है कि अप्रकाशित निर्भरताएं प्राथमिक आक्रमण वेक्टर हैं (लॉग4शेल, स्प्रिंग4शेल)

C

SCA is only required for applications that directly handle financial transactions एससीए केवल उन अनुप्रयोगों के लिए आवश्यक है जो सीधे वित्तीय लेनदेन को संभालते हैं

D

SCA is fully replaced by unit testing and code coverage analysis in modern DevSecOps pipelines आधुनिक DevSecOps पाइपलाइनों में SCA को पूरी तरह से यूनिट परीक्षण और कोड कवरेज विश्लेषण द्वारा प्रतिस्थापित किया गया है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Log4Shell (Dec 2021, CVSS 10.0) affected virtually every Java application using Log4j 2.x. Organisations without SCA had no inventory of where Log4j was used — they couldn't even identify which systems were vulnerable. SCA tools (Snyk, OWASP Dependency-Check, GitHub Dependabot) automate this: scan manifests and binaries, cross-reference CVE databases, block builds with critical vulnerabilities, and generate alerts when new CVEs are published for used libraries.

व्याख्या (हिन्दी) Log4Shell (दिसंबर 2021, CVSS 10.0) ने Log4j 2.x का उपयोग करने वाले लगभग हर जावा एप्लिकेशन को प्रभावित किया। SCA के बिना संगठनों के पास इस बात की कोई सूची नहीं थी कि Log4j का उपयोग कहाँ किया गया था - वे यह भी नहीं पहचान सके कि कौन से सिस्टम असुरक्षित थे। एससीए उपकरण (स्निक, ओडब्ल्यूएएसपी डिपेंडेंसी-चेक, गिटहब डिपेंडेबोट) इसे स्वचालित करते हैं: मैनिफ़ेस्ट और बायनेरिज़ को स्कैन करें, क्रॉस-रेफरेंस सीवीई डेटाबेस, महत्वपूर्ण कमजोरियों के साथ ब्लॉक ब्लॉक करें, और प्रयुक्त पुस्तकालयों के लिए नए सीवीई प्रकाशित होने पर अलर्ट उत्पन्न करें।

540

EN + हिं Medium

GB What is 'maintenance release planning' and how does it balance corrective, adaptive, and perfective work?

IN 'रखरखाव रिलीज योजना' क्या है और यह सुधारात्मक, अनुकूली और पूर्ण कार्य को कैसे संतुलित करती है?

A

Maintenance release planning always prioritises corrective work over all other maintenance types रखरखाव रिलीज़ योजना हमेशा अन्य सभी प्रकार के रखरखाव की तुलना में सुधारात्मक कार्य को प्राथमिकता देती है

B

Maintenance release planning allocates capacity across maintenance types based on business priorities: critical defects addressed immediately; adaptive work driven by external deadlines (OS upgrades, regulation changes); perfective work in regular releases; the allocation ratio reflects risk tolerance and strategic investment decisions रखरखाव रिलीज योजना व्यावसायिक प्राथमिकताओं के आधार पर रखरखाव के प्रकारों में क्षमता आवंटित करती है: महत्वपूर्ण दोषों को तुरंत संबोधित किया जाता है; बाहरी समय सीमा (ओएस अपग्रेड, विनियमन परिवर्तन) द्वारा संचालित अनुकूली कार्य; नियमित रिलीज़ में उत्तम कार्य; आवंटन अनुपात जोखिम सहनशीलता और रणनीतिक निवेश निर्णयों को दर्शाता है

C

Maintenance release planning eliminates the need for a product backlog by using a maintenance-specific process रखरखाव रिलीज़ योजना रखरखाव-विशिष्ट प्रक्रिया का उपयोग करके उत्पाद बैकलॉग की आवश्यकता को समाप्त कर देती है

D

All maintenance types must be planned in equal proportions to maintain system health सिस्टम के स्वास्थ्य को बनाए रखने के लिए सभी प्रकार के रखरखाव की समान अनुपात में योजना बनाई जानी चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) A typical enterprise allocation: ~20% emergency corrective (P1/P2 bugs addressed within SLA), ~25% adaptive (compliance, infrastructure updates, third-party API changes), ~55% perfective (new features, performance improvements, UX refinements). This shifts when: a security vulnerability demands immediate corrective focus; a major OS EOL drives adaptive work; or strategic product initiatives demand more perfective capacity.

व्याख्या (हिन्दी) एक विशिष्ट उद्यम आवंटन: ~20% आपातकालीन सुधारात्मक (एसएलए के भीतर पी1/पी2 बग का समाधान), ~25% अनुकूली (अनुपालन, बुनियादी ढाँचा अपडेट, तृतीय-पक्ष एपीआई परिवर्तन), ~55% पूर्ण (नई सुविधाएँ, प्रदर्शन सुधार, यूएक्स परिशोधन)। यह तब बदलता है जब: सुरक्षा भेद्यता तत्काल सुधारात्मक फोकस की मांग करती है; एक प्रमुख OS EOL अनुकूली कार्य को संचालित करता है; या रणनीतिक उत्पाद पहल के लिए अधिक उत्तम क्षमता की आवश्यकता होती है।

Software Engineering — MCQ Practice