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
2716
EN + हिं Easy
GB What is 'commit message convention' (Conventional Commits) and what automation does adhering to it enable?
IN 'कमिट मैसेज कन्वेंशन' (कन्वेंशनल कमिट्स) क्या है और इसका पालन करने से कौन सा स्वचालन सक्षम होता है?
A
Commit conventions are purely cosmetic and provide no functional benefit to the development process प्रतिबद्धता सम्मेलन पूरी तरह से दिखावटी हैं और विकास प्रक्रिया को कोई कार्यात्मक लाभ नहीं देते हैं
B
Conventional Commits structures messages as type(scope): description (e.g., 'feat(auth): add OAuth support', 'fix(api): handle null response') — this structured format enables automated semantic versioning (feat = minor bump, fix = patch bump, BREAKING CHANGE = major bump) and automated changelog generation directly from commit history पारंपरिक कमिट्स संदेशों को प्रकार (स्कोप) के रूप में संरचित करता है: विवरण (उदाहरण के लिए, 'फीट (ऑथ): OAuth सपोर्ट जोड़ें', 'फिक्स (एपीआई): हैंडल नल रिस्पॉन्स') - यह संरचित प्रारूप स्वचालित सिमेंटिक वर्जनिंग (फीट = माइनर बम्प, फिक्स = पैच बम्प, ब्रेकिंग चेंज = प्रमुख बम्प) और प्रतिबद्ध इतिहास से सीधे स्वचालित चेंजलॉग पीढ़ी को सक्षम बनाता है।
C
Commit message conventions can only be enforced manually through code review and cannot be automated प्रतिबद्ध संदेश सम्मेलनों को केवल कोड समीक्षा के माध्यम से मैन्युअल रूप से लागू किया जा सकता है और स्वचालित नहीं किया जा सकता है
D
Conventional Commits requires using a specific programming language and cannot work with polyglot codebases कन्वेंशनल कमिट्स के लिए एक विशिष्ट प्रोग्रामिंग भाषा का उपयोग करने की आवश्यकता होती है और यह पॉलीग्लॉट कोडबेस के साथ काम नहीं कर सकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) semantic-release and similar tools parse commit history: 'fix: ...' commits trigger a patch version bump (1.2.3 → 1.2.4); 'feat: ...' triggers minor (1.2.3 → 1.3.0); a commit containing 'BREAKING CHANGE:' triggers major (1.2.3 → 2.0.0). Combined with automated changelog generation, this eliminates manual version number decisions and release notes writing — the commit history itself becomes the source of truth for what changed and how significantly.
व्याख्या (हिन्दी) सिमेंटिक-रिलीज़ और समान उपकरण पार्स कमिट इतिहास: 'फिक्स: ...' कमिट एक पैच संस्करण बम्प को ट्रिगर करता है (1.2.3 → 1.2.4); 'करतब:...' मामूली ट्रिगर करता है (1.2.3 → 1.3.0); 'ब्रेकिंग चेंज:' वाली एक प्रतिबद्धता प्रमुख ट्रिगर करती है (1.2.3 → 2.0.0)। स्वचालित चेंजलॉग जेनरेशन के साथ मिलकर, यह मैन्युअल संस्करण संख्या निर्णयों और नोट्स लेखन को समाप्त कर देता है - प्रतिबद्ध इतिहास स्वयं सत्य का स्रोत बन जाता है कि क्या और कितना महत्वपूर्ण परिवर्तन हुआ है।
2717
EN + हिं Easy
GB What is the 'error handling strategy' debate between exceptions and result types (Result) and what does each optimise for?
IN अपवादों और परिणाम प्रकारों (परिणाम) के बीच 'त्रुटि प्रबंधन रणनीति' बहस क्या है और प्रत्येक किसके लिए अनुकूलन करता है?
A
Exceptions and result types produce identical runtime performance with no architectural trade-offs अपवाद और परिणाम प्रकार बिना किसी आर्किटेक्चरल ट्रेड-ऑफ के समान रनटाइम प्रदर्शन उत्पन्न करते हैं
B
Exceptions optimise for the common-case happy path being unencumbered by error checking syntax (errors propagate implicitly up the call stack) but risk unhandled exceptions causing crashes if callers forget to catch; result types (Rust, functional languages) make error handling explicit in the function signature, forcing callers to handle or explicitly propagate errors at compile time, trading verbosity for compile-time safety अपवाद सामान्य-मामले के खुश पथ के लिए अनुकूलित होते हैं, जो त्रुटि जाँच सिंटैक्स द्वारा भारमुक्त होते हैं (त्रुटियाँ स्पष्ट रूप से कॉल स्टैक में फैलती हैं) लेकिन यदि कॉल करने वाले पकड़ना भूल जाते हैं, तो अनचाहे अपवादों के क्रैश होने का जोखिम होता है; परिणाम प्रकार (जंग, कार्यात्मक भाषाएं) फ़ंक्शन हस्ताक्षर में त्रुटि प्रबंधन को स्पष्ट करते हैं, कॉल करने वालों को संकलन समय पर त्रुटियों को संभालने या स्पष्ट रूप से प्रचारित करने के लिए मजबूर करते हैं, संकलन-समय सुरक्षा के लिए ट्रेडिंग वर्बोसिटी
C
Result types are always slower than exceptions and should never be used in performance-critical code परिणाम प्रकार हमेशा अपवादों की तुलना में धीमे होते हैं और प्रदर्शन-महत्वपूर्ण कोड में कभी भी इसका उपयोग नहीं किया जाना चाहिए
D
Exception-based error handling is deprecated and no longer used in any modern programming language अपवाद-आधारित त्रुटि प्रबंधन को बहिष्कृत कर दिया गया है और अब किसी भी आधुनिक प्रोग्रामिंग भाषा में इसका उपयोग नहीं किया जाता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Java/C# exceptions allow clean code: result = doSomething(); — but if doSomething() can throw and the caller doesn't catch, the program crashes at runtime, often far from the actual error source. Rust's Result forces: match doSomething() { Ok(v) => ..., Err(e) => ... } — verbose but the compiler refuses to compile code that ignores the error case entirely. This shifts error-handling bugs from runtime discovery to compile-time prevention, at the cost of more boilerplate for every fallible operation.
व्याख्या (हिन्दी) जावा/सी# अपवाद साफ़ कोड की अनुमति देते हैं: परिणाम = कुछ करें(); - लेकिन यदि doSomething() फेंक सकता है और कॉलर पकड़ नहीं पाता है, तो प्रोग्राम रनटाइम पर क्रैश हो जाता है, अक्सर वास्तविक त्रुटि स्रोत से बहुत दूर। रस्ट का परिणाम बल देता है: मैच डू ​​समथिंग() { ओके(वी) => ..., इर(ई) => ... } - वर्बोज़ लेकिन कंपाइलर कोड को संकलित करने से इंकार कर देता है जो त्रुटि मामले को पूरी तरह से अनदेखा करता है। यह प्रत्येक त्रुटिपूर्ण ऑपरेशन के लिए अधिक बॉयलरप्लेट की कीमत पर, रनटाइम खोज से संकलन-समय रोकथाम में त्रुटि-हैंडलिंग बग को स्थानांतरित करता है।
2718
EN + हिं Easy
GB What is 'immutability by default' coding standard and what category of concurrency bugs does it eliminate?
IN 'डिफ़ॉल्ट रूप से अपरिवर्तनीयता' कोडिंग मानक क्या है और यह किस श्रेणी के समवर्ती बग को समाप्त करता है?
A
Immutability by default means variables can never be declared in any programming language डिफ़ॉल्ट रूप से अपरिवर्तनीयता का अर्थ है कि किसी भी प्रोग्रामिंग भाषा में चर कभी भी घोषित नहीं किए जा सकते
B
This standard prefers immutable data structures (final/const/readonly) unless mutation is explicitly required — it eliminates entire categories of concurrency bugs because immutable data can be freely shared across threads without synchronisation (no data races possible if nothing can be written after creation) यह मानक अपरिवर्तनीय डेटा संरचनाओं (अंतिम / स्थिरांक / केवल पढ़ने के लिए) को प्राथमिकता देता है जब तक कि उत्परिवर्तन की स्पष्ट रूप से आवश्यकता न हो - यह समवर्ती बग की पूरी श्रेणियों को समाप्त कर देता है क्योंकि अपरिवर्तनीय डेटा को सिंक्रनाइज़ेशन के बिना थ्रेड्स में स्वतंत्र रूप से साझा किया जा सकता है (यदि निर्माण के बाद कुछ भी नहीं लिखा जा सकता है तो कोई डेटा दौड़ संभव नहीं है)
C
Immutability by default requires rewriting all existing mutable code before any new development can proceed डिफ़ॉल्ट रूप से अपरिवर्तनीयता के लिए किसी भी नए विकास को आगे बढ़ाने से पहले सभी मौजूदा परिवर्तनीय कोड को फिर से लिखना आवश्यक है
D
Immutable data structures always consume more memory than mutable ones with no performance trade-offs ever justified अपरिवर्तनीय डेटा संरचनाएं हमेशा परिवर्तनशील डेटा संरचनाओं की तुलना में अधिक मेमोरी का उपभोग करती हैं, जिसमें कोई प्रदर्शन समझौता कभी भी उचित नहीं होता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Data races (the most insidious concurrency bugs) require: shared memory, at least one writer, and lack of synchronisation. Immutable objects eliminate the 'writer' condition entirely — once created, the value never changes, so any number of threads can read it simultaneously with zero risk of race conditions. Functional languages (Clojure, Haskell) and modern practice in Java/C# (records, readonly structs) embrace this as a primary concurrency-safety strategy, trading some flexibility/performance for eliminated bug classes.
व्याख्या (हिन्दी) डेटा रेस (सबसे घातक समवर्ती बग) के लिए आवश्यक है: साझा मेमोरी, कम से कम एक लेखक, और सिंक्रनाइज़ेशन की कमी। अपरिवर्तनीय वस्तुएँ 'लेखक' की स्थिति को पूरी तरह से समाप्त कर देती हैं - एक बार निर्मित होने के बाद, मूल्य कभी नहीं बदलता है, इसलिए किसी भी संख्या में थ्रेड इसे दौड़ की स्थिति के शून्य जोखिम के साथ एक साथ पढ़ सकते हैं। कार्यात्मक भाषाएं (क्लोजर, हास्केल) और जावा/सी# (रिकॉर्ड, रीडओनली स्ट्रक्चर्स) में आधुनिक अभ्यास इसे प्राथमिक संगामिति-सुरक्षा रणनीति के रूप में अपनाते हैं, जो बग वर्गों को खत्म करने के लिए कुछ लचीलेपन/प्रदर्शन का व्यापार करते हैं।
2719
EN + हिं Medium
GB What is 'fail-fast principle' in coding standards and how does it differ from graceful degradation?
IN कोडिंग मानकों में 'फेल-फास्ट सिद्धांत' क्या है और यह ग्रेसफुल डिग्रेडेशन से कैसे भिन्न है?
A
Fail-fast and graceful degradation are identical strategies applied at different system layers फेल-फास्ट और ग्रेसफुल डिग्रेडेशन अलग-अलग सिस्टम परतों पर लागू की जाने वाली समान रणनीतियाँ हैं
B
Fail-fast immediately surfaces errors at the point of detection (throw on invalid state rather than continuing with corrupted data) — making bugs visible and traceable to their source; graceful degradation continues operating with reduced functionality when a component fails (show cached data if live data unavailable) — appropriate for user-facing resilience but inappropriate for catching programming errors during development फ़ेल-फ़ास्ट तुरंत पता लगाने के बिंदु पर त्रुटियों को सामने लाता है (दूषित डेटा को जारी रखने के बजाय अमान्य स्थिति पर फेंकें) - बग को दृश्यमान बनाना और उनके स्रोत का पता लगाना; जब कोई घटक विफल हो जाता है तो ग्रेसफुल डिग्रेडेशन कम कार्यक्षमता के साथ काम करना जारी रखता है (यदि लाइव डेटा अनुपलब्ध है तो कैश्ड डेटा दिखाएं) - उपयोगकर्ता-सामना के लचीलेपन के लिए उपयुक्त लेकिन विकास के दौरान प्रोग्रामिंग त्रुटियों को पकड़ने के लिए अनुपयुक्त
C
Fail-fast should never be used in production systems; only graceful degradation is acceptable फेल-फास्ट का उपयोग उत्पादन प्रणालियों में कभी नहीं किया जाना चाहिए; केवल शालीन अवनति ही स्वीकार्य है
D
Graceful degradation always produces worse user experience than fail-fast in all scenarios ग्रेसफुल डिग्रेडेशन हमेशा सभी परिदृश्यों में फेल-फास्ट से भी बदतर उपयोगकर्ता अनुभव उत्पन्न करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) During development, fail-fast (assertions, strict validation) ensures bugs surface immediately with full context rather than silently corrupting data that fails mysteriously much later. In production user-facing systems, graceful degradation (Netflix showing cached recommendations if the live recommendation service is down) prioritises availability over perfect correctness. The art is applying fail-fast to programming errors (which indicate bugs needing fixes) and graceful degradation to operational failures (which indicate infrastructure issues to be tolerated).
व्याख्या (हिन्दी) विकास के दौरान, फेल-फास्ट (दावा, सख्त सत्यापन) यह सुनिश्चित करता है कि बग तुरंत पूरे संदर्भ के साथ सामने आ जाएं न कि चुपचाप डेटा को दूषित कर दें जो बहुत बाद में रहस्यमय तरीके से विफल हो जाता है। उत्पादन उपयोगकर्ता-सामना वाले सिस्टम में, ग्रेसफुल डिग्रेडेशन (लाइव अनुशंसा सेवा बंद होने पर नेटफ्लिक्स कैश्ड अनुशंसाएँ दिखाता है) सही शुद्धता पर उपलब्धता को प्राथमिकता देता है। कला प्रोग्रामिंग त्रुटियों (जो बग को ठीक करने की आवश्यकता को इंगित करती है) और परिचालन विफलताओं (जो सहन किए जाने वाले बुनियादी ढांचे के मुद्दों को इंगित करती है) के लिए शालीन गिरावट को लागू कर रही है।
2720
EN + हिं Medium
GB What is 'rule of three' in refactoring decision-making and how does it guide when to extract reusable abstractions?
IN रीफैक्टरिंग निर्णय लेने में 'तीन का नियम' क्या है और पुन: प्रयोज्य सार निकालने के लिए यह कैसे मार्गदर्शन करता है?
A
Rule of three requires every function to have exactly three parameters तीन के नियम के लिए आवश्यक है कि प्रत्येक फ़ंक्शन में बिल्कुल तीन पैरामीटर हों
B
The rule of three (Martin Fowler, originally from Don Roberts) suggests waiting until similar code appears three times before extracting a shared abstraction — premature abstraction after seeing only two similar instances often produces the wrong abstraction because the pattern isn't yet clear; the third occurrence reveals which aspects are truly common versus coincidentally similar तीन का नियम (मार्टिन फाउलर, मूल रूप से डॉन रॉबर्ट्स से) एक साझा अमूर्त को निकालने से पहले तीन बार समान कोड प्रकट होने तक प्रतीक्षा करने का सुझाव देता है - केवल दो समान उदाहरणों को देखने के बाद समयपूर्व अमूर्तता अक्सर गलत अमूर्तता उत्पन्न करती है क्योंकि पैटर्न अभी तक स्पष्ट नहीं है; तीसरी घटना से पता चलता है कि कौन से पहलू वास्तव में सामान्य बनाम संयोगवश समान हैं
C
Rule of three means code should be reviewed by exactly three different developers before merging तीन के नियम का मतलब है कि विलय से पहले कोड की समीक्षा बिल्कुल तीन अलग-अलग डेवलपर्स द्वारा की जानी चाहिए
D
The rule applies only to test code and has no relevance to production code refactoring decisions नियम केवल परीक्षण कोड पर लागू होता है और उत्पादन कोड रीफैक्टरिंग निर्णयों से इसकी कोई प्रासंगिकता नहीं है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Sandi Metz's observation: 'duplication is far cheaper than the wrong abstraction.' Two similar code blocks might look alike coincidentally — extracting a shared function based on two instances risks creating an abstraction that doesn't actually fit the third use case, forcing awkward parameters or special-case branches to accommodate. Waiting for the third occurrence provides enough data points to identify the true commonality versus superficial similarity.
व्याख्या (हिन्दी) सैंडी मेट्ज़ का अवलोकन: 'गलत अमूर्तन की तुलना में दोहराव कहीं अधिक सस्ता है।' दो समान कोड ब्लॉक संयोग से एक जैसे दिख सकते हैं - दो उदाहरणों के आधार पर एक साझा फ़ंक्शन को निकालने से एक अमूर्तता पैदा होने का जोखिम होता है जो वास्तव में तीसरे उपयोग के मामले में फिट नहीं होता है, अजीब मापदंडों या विशेष-मामले शाखाओं को समायोजित करने के लिए मजबूर करता है। तीसरी घटना की प्रतीक्षा वास्तविक समानता बनाम सतही समानता की पहचान करने के लिए पर्याप्त डेटा बिंदु प्रदान करती है।
2721
EN + हिं Easy
GB What is 'API contract testing' for backward compatibility and what specific breaking change category does semantic versioning fail to catch automatically?
IN बैकवर्ड संगतता के लिए 'एपीआई अनुबंध परीक्षण' क्या है और सिमेंटिक संस्करण स्वचालित रूप से किस विशिष्ट ब्रेकिंग परिवर्तन श्रेणी को पकड़ने में विफल रहता है?
A
Semantic versioning automatically catches every possible type of breaking API change without exception सिमेंटिक वर्जनिंग बिना किसी अपवाद के हर संभावित प्रकार के ब्रेकिंग एपीआई परिवर्तन को स्वचालित रूप से पकड़ लेती है
B
Contract testing verifies actual API behaviour matches a published schema across versions; semantic versioning relies on humans correctly classifying changes — it fails to catch 'silent' breaking changes where a developer mistakenly tags a breaking change as a minor/patch bump (e.g., changing a field's data type while believing it's backward compatible), since SemVer is a convention, not an automatically enforced guarantee अनुबंध परीक्षण सत्यापित करता है कि वास्तविक एपीआई व्यवहार सभी संस्करणों में प्रकाशित स्कीमा से मेल खाता है; सिमेंटिक संस्करण मनुष्यों द्वारा परिवर्तनों को सही ढंग से वर्गीकृत करने पर निर्भर करता है - यह 'मूक' ब्रेकिंग परिवर्तनों को पकड़ने में विफल रहता है जहां एक डेवलपर गलती से एक ब्रेकिंग परिवर्तन को मामूली/पैच बम्प के रूप में टैग करता है (उदाहरण के लिए, किसी फ़ील्ड के डेटा प्रकार को यह मानते हुए कि यह बैकवर्ड संगत है), क्योंकि सेमवीर एक सम्मेलन है, स्वचालित रूप से लागू गारंटी नहीं है
C
Contract testing is identical to unit testing with no functional differences between the two approaches अनुबंध परीक्षण इकाई परीक्षण के समान है और दोनों दृष्टिकोणों के बीच कोई कार्यात्मक अंतर नहीं है
D
Contract testing can only verify API documentation accuracy, not actual runtime behaviour अनुबंध परीक्षण केवल एपीआई दस्तावेज़ सटीकता को सत्यापित कर सकता है, वास्तविक रनटाइम व्यवहार को नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) SemVer is a human-applied convention — nothing technically prevents a developer from incorrectly bumping only the patch version for an actually-breaking change (changing a response field from string to integer, removing a field, changing error codes). Automated contract testing (Pact, OpenAPI schema diffing) actually validates the API's observable behaviour against the previous version's contract, catching unintentional breaking changes regardless of how the version bump was labelled — providing a safety net SemVer's honour system cannot guarantee alone.
व्याख्या (हिन्दी) सेमवीर एक मानव-प्रयुक्त सम्मेलन है - तकनीकी रूप से कुछ भी डेवलपर को वास्तव में ब्रेकिंग परिवर्तन (स्ट्रिंग से पूर्णांक में प्रतिक्रिया फ़ील्ड को बदलना, फ़ील्ड को हटाना, त्रुटि कोड बदलना) के लिए केवल पैच संस्करण को गलत तरीके से बंप करने से रोकता है। स्वचालित अनुबंध परीक्षण (पैक्ट, ओपनएपीआई स्कीमा डिफिंग) वास्तव में पिछले संस्करण के अनुबंध के खिलाफ एपीआई के अवलोकन योग्य व्यवहार को मान्य करता है, संस्करण बम्प को कैसे लेबल किया गया था, इसकी परवाह किए बिना अनजाने में होने वाले परिवर्तनों को पकड़ता है - एक सुरक्षा जाल प्रदान करना सेमवीर का सम्मान सिस्टम अकेले गारंटी नहीं दे सकता है।
2722
EN + हिं Easy
GB What is 'feature branch lifetime' standard and what specific risk increases non-linearly as branch age increases?
IN 'फ़ीचर शाखा जीवनकाल' मानक क्या है और शाखा की आयु बढ़ने पर गैर-रेखीय रूप से कौन सा विशिष्ट जोखिम बढ़ जाता है?
A
Feature branch age has no measurable relationship to merge difficulty or integration risk फ़ीचर शाखा की आयु का मर्ज कठिनाई या एकीकरण जोखिम से कोई मापने योग्य संबंध नहीं है
B
Coding standards often mandate short-lived branches (merge within 1-2 days) because merge conflict probability and complexity increase non-linearly with divergence time — both branches' code evolves independently, increasing the surface area of potential conflicts and the cognitive difficulty of resolving them correctly as more unrelated changes accumulate on both sides कोडिंग मानक अक्सर अल्पकालिक शाखाओं (1-2 दिनों के भीतर विलय) को अनिवार्य करते हैं क्योंकि विलय संघर्ष की संभावना और जटिलता विचलन समय के साथ गैर-रैखिक रूप से बढ़ती है - दोनों शाखाओं का कोड स्वतंत्र रूप से विकसित होता है, संभावित संघर्षों के सतह क्षेत्र में वृद्धि होती है और उन्हें सही ढंग से हल करने की संज्ञानात्मक कठिनाई बढ़ जाती है क्योंकि दोनों तरफ अधिक असंबंधित परिवर्तन जमा होते हैं
C
Long-lived feature branches always produce higher quality code than short-lived branches लंबे समय तक जीवित रहने वाली फीचर शाखाएं हमेशा अल्पकालिक शाखाओं की तुलना में उच्च गुणवत्ता वाले कोड का उत्पादन करती हैं
D
Branch lifetime is only relevant for projects using Subversion; Git eliminates all merge conflict risks शाखा जीवनकाल केवल सबवर्सन का उपयोग करने वाली परियोजनाओं के लिए प्रासंगिक है; Git सभी मर्ज विरोध जोखिमों को समाप्त करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A 1-day branch likely has minimal overlap with main's changes — merge is trivial. A 1-month branch has accumulated 30 days of unrelated changes on both sides; merging now requires reconciling potentially hundreds of overlapping changes, often requiring deep understanding of both branches' intent to resolve correctly. This non-linear growth (not just more conflicts, but exponentially harder-to-reason-about conflicts) is why trunk-based development and short-lived feature branches/flags are now widely recommended over long-lived GitFlow-style feature branches.
व्याख्या (हिन्दी) 1-दिवसीय शाखा में मुख्य परिवर्तनों के साथ न्यूनतम ओवरलैप होने की संभावना है - विलय तुच्छ है। 1-महीने की शाखा में दोनों पक्षों में 30 दिनों के असंबंधित परिवर्तन जमा हो गए हैं; अब विलय के लिए संभावित रूप से सैकड़ों अतिव्यापी परिवर्तनों को समेटने की आवश्यकता होती है, जिसे अक्सर सही ढंग से हल करने के लिए दोनों शाखाओं के इरादे की गहरी समझ की आवश्यकता होती है। यह गैर-रैखिक विकास (न केवल अधिक संघर्ष, बल्कि तेजी से कठिन-से-कारण-संबंधी संघर्ष) यही कारण है कि ट्रंक-आधारित विकास और अल्पकालिक फीचर शाखाएं/झंडे अब लंबे समय तक चलने वाले गिटफ्लो-शैली फीचर शाखाओं पर व्यापक रूप से अनुशंसित हैं।
2723
EN + हिं Easy
GB What is 'configuration as code' standard and what specific deployment risk does hardcoding configuration values introduce?
IN 'कोड के रूप में कॉन्फ़िगरेशन' मानक क्या है और हार्डकोडिंग कॉन्फ़िगरेशन मान किस विशिष्ट परिनियोजन जोखिम का परिचय देते हैं?
A
Configuration as code means all application logic must be written in YAML instead of a programming language कोड के रूप में कॉन्फ़िगरेशन का मतलब है कि सभी एप्लिकेशन लॉजिक को प्रोग्रामिंग भाषा के बजाय YAML में लिखा जाना चाहिए
B
Configuration as code stores environment-specific settings (database URLs, API keys, feature flags) outside the application binary, in version-controlled config files or environment variables — hardcoding values (e.g., a production database URL embedded directly in source code) risks accidentally deploying production credentials to lower environments or requiring a full rebuild/redeploy for any configuration change, including emergency fixes कोड के रूप में कॉन्फ़िगरेशन पर्यावरण-विशिष्ट सेटिंग्स (डेटाबेस यूआरएल, एपीआई कुंजी, फ़ीचर फ़्लैग) को एप्लिकेशन बाइनरी के बाहर, संस्करण-नियंत्रित कॉन्फ़िगरेशन फ़ाइलों या पर्यावरण चर में संग्रहीत करता है - हार्डकोडिंग मान (उदाहरण के लिए, स्रोत कोड में सीधे एम्बेडेड एक उत्पादन डेटाबेस यूआरएल) कम वातावरण में उत्पादन क्रेडेंशियल्स को गलती से तैनात करने या आपातकालीन फिक्स समेत किसी भी कॉन्फ़िगरेशन परिवर्तन के लिए पूर्ण पुनर्निर्माण/पुनः तैनाती की आवश्यकता का जोखिम उठाता है।
C
Configuration as code eliminates the need for any environment-specific settings since all environments become identical कोड के रूप में कॉन्फ़िगरेशन किसी भी पर्यावरण-विशिष्ट सेटिंग्स की आवश्यकता को समाप्त कर देता है क्योंकि सभी वातावरण समान हो जाते हैं
D
Hardcoded configuration values are always more secure than externalised configuration हार्डकोडेड कॉन्फ़िगरेशन मान हमेशा बाहरी कॉन्फ़िगरेशन की तुलना में अधिक सुरक्षित होते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The Twelve-Factor App methodology explicitly mandates strict separation of config from code. A hardcoded API key requires a code change, code review, build, and deploy just to rotate a compromised credential — dangerous delay during a security incident. Externalised configuration (environment variables, secret managers like Vault) allows instant credential rotation without touching application code, and prevents the common mistake of accidentally committing production secrets to version control.
व्याख्या (हिन्दी) बारह-फैक्टर ऐप पद्धति स्पष्ट रूप से कोड से कॉन्फ़िगरेशन को सख्ती से अलग करने का आदेश देती है। एक हार्डकोडेड एपीआई कुंजी के लिए एक कोड परिवर्तन, कोड समीक्षा, निर्माण और तैनाती की आवश्यकता होती है ताकि एक समझौता किए गए क्रेडेंशियल को घुमाया जा सके - एक सुरक्षा घटना के दौरान खतरनाक देरी। बाहरी कॉन्फ़िगरेशन (पर्यावरण चर, वॉल्ट जैसे गुप्त प्रबंधक) एप्लिकेशन कोड को छुए बिना तत्काल क्रेडेंशियल रोटेशन की अनुमति देता है, और गलती से उत्पादन रहस्यों को संस्करण नियंत्रण में डालने की सामान्य गलती को रोकता है।
2724
EN + हिं Easy
GB What is 'graceful shutdown' coding standard for distributed services and what data loss risk does ignoring it create?
IN वितरित सेवाओं के लिए 'ग्रेसफुल शटडाउन' कोडिंग मानक क्या है और इसे अनदेखा करने से डेटा हानि का क्या जोखिम पैदा होता है?
A
Graceful shutdown only matters for desktop applications, not server-side distributed services ग्रेसफुल शटडाउन केवल डेस्कटॉप अनुप्रयोगों के लिए मायने रखता है, सर्वर-साइड वितरित सेवाओं के लिए नहीं
B
Graceful shutdown handlers respond to termination signals (SIGTERM) by finishing in-flight requests, closing database connections cleanly, and deregistering from service discovery before exiting — ignoring it (immediate process kill) risks dropping in-progress requests mid-transaction, leaving database connections in inconsistent states, and routing new traffic to a service that's already shutting down ग्रेसफुल शटडाउन हैंडलर इन-फ़्लाइट अनुरोधों को पूरा करके, डेटाबेस कनेक्शन को साफ़-साफ़ बंद करके, और बाहर निकलने से पहले सेवा खोज से अपंजीकृत करके समाप्ति संकेतों (SIGTERM) का जवाब देते हैं - इसे अनदेखा करना (तत्काल प्रक्रिया को समाप्त करना) मध्य-लेन-देन में प्रगति अनुरोधों को छोड़ने का जोखिम, डेटाबेस कनेक्शन को असंगत स्थिति में छोड़ना, और नए ट्रैफ़िक को उस सेवा पर रूट करना जो पहले से ही बंद हो रही है
C
Graceful shutdown is automatically handled by all container orchestration platforms with zero application code required ग्रेसफुल शटडाउन को शून्य एप्लिकेशन कोड की आवश्यकता के साथ सभी कंटेनर ऑर्केस्ट्रेशन प्लेटफार्मों द्वारा स्वचालित रूप से नियंत्रित किया जाता है
D
Implementing graceful shutdown increases application startup time but has no effect on shutdown behaviour ग्रेसफुल शटडाउन लागू करने से एप्लिकेशन स्टार्टअप समय बढ़ जाता है लेकिन शटडाउन व्यवहार पर कोई प्रभाव नहीं पड़ता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Kubernetes sends SIGTERM before forcibly killing a pod (SIGKILL after a grace period). An application without a SIGTERM handler is killed mid-request when scaling down or during rolling deployments — a user's checkout request might be half-processed, charging their card without confirming the order. Proper graceful shutdown: stop accepting new connections, finish processing in-flight requests within the grace period, then exit cleanly — preventing data corruption during routine deployment operations.
व्याख्या (हिन्दी) कुबेरनेट्स एक पॉड को जबरन मारने से पहले SIGTERM भेजता है (एक अनुग्रह अवधि के बाद SIGKILL)। SIGTERM हैंडलर के बिना एक एप्लिकेशन स्केल डाउन करते समय या रोलिंग तैनाती के दौरान अनुरोध के मध्य में बंद हो जाता है - उपयोगकर्ता का चेकआउट अनुरोध आधा संसाधित हो सकता है, जिससे ऑर्डर की पुष्टि किए बिना उनके कार्ड से शुल्क लिया जा सकता है। उचित ग्रेसफुल शटडाउन: नए कनेक्शन स्वीकार करना बंद करें, ग्रेस अवधि के भीतर इन-फ़्लाइट अनुरोधों को संसाधित करना समाप्त करें, फिर सफाई से बाहर निकलें - नियमित तैनाती संचालन के दौरान डेटा भ्रष्टाचार को रोकना।
2725
EN + हिं Easy
GB What is 'dependency pinning' versus 'dependency ranges' in package management standards and what stability/security trade-off exists between them?
IN पैकेज प्रबंधन मानकों में 'डिपेंडेंसी पिनिंग' बनाम 'डिपेंडेंसी रेंज' क्या है और उनके बीच कौन सी स्थिरता/सुरक्षा व्यापार-बंद मौजूद है?
A
Dependency pinning and ranges produce functionally identical builds in all circumstances निर्भरता पिनिंग और श्रेणियां सभी परिस्थितियों में कार्यात्मक रूप से समान निर्माण उत्पन्न करती हैं
B
Pinning (exact version: 'lodash: 4.17.21') guarantees reproducible builds but requires manual intervention to receive security patches; ranges ('lodash: ^4.17.0') automatically receive compatible updates including security fixes but risk unexpected behaviour changes from a dependency's minor update breaking the application unexpectedly पिनिंग (सटीक संस्करण: 'लॉश: 4.17.21') प्रतिलिपि प्रस्तुत करने योग्य निर्माण की गारंटी देता है लेकिन सुरक्षा पैच प्राप्त करने के लिए मैन्युअल हस्तक्षेप की आवश्यकता होती है; श्रेणियां ('लॉश: ^4.17.0') स्वचालित रूप से सुरक्षा सुधारों सहित संगत अपडेट प्राप्त करती हैं, लेकिन निर्भरता के मामूली अपडेट से अप्रत्याशित रूप से एप्लिकेशन को तोड़ने से अप्रत्याशित व्यवहार परिवर्तन का जोखिम होता है।
C
Dependency pinning is always insecure and should never be used in any production system निर्भरता पिनिंग हमेशा असुरक्षित होती है और इसका उपयोग कभी भी किसी उत्पादन प्रणाली में नहीं किया जाना चाहिए
D
Dependency ranges eliminate the need for any dependency vulnerability scanning since updates are automatic निर्भरता श्रेणियां किसी भी निर्भरता भेद्यता स्कैनिंग की आवश्यकता को खत्म कर देती हैं क्योंकि अपडेट स्वचालित होते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The 2021 ua-parser-js npm supply chain attack illustrates the range risk: malicious code was published as a 'patch' update; projects using ranges automatically pulled the compromised version. Conversely, pinned dependencies that never update silently accumulate known vulnerabilities (e.g., the Equifax breach was partly due to an unpatched, pinned Apache Struts version). The modern best practice: pin exact versions for reproducibility AND use automated dependency update tools (Dependabot, Renovate) with required review, combining stability with timely patching.
व्याख्या (हिन्दी) 2021 यूए-पार्सर-जेएस एनपीएम आपूर्ति श्रृंखला हमला रेंज जोखिम को दर्शाता है: दुर्भावनापूर्ण कोड को 'पैच' अपडेट के रूप में प्रकाशित किया गया था; श्रेणियों का उपयोग करने वाली परियोजनाएं स्वचालित रूप से समझौता किए गए संस्करण को खींच लेती हैं। इसके विपरीत, पिन की गई निर्भरताएं जो कभी भी अपडेट नहीं होती हैं वे चुपचाप ज्ञात कमजोरियों को जमा करती हैं (उदाहरण के लिए, इक्विफैक्स उल्लंघन आंशिक रूप से एक अप्रकाशित, पिन किए गए अपाचे स्ट्रट्स संस्करण के कारण था)। आधुनिक सर्वोत्तम अभ्यास: पुनरुत्पादन के लिए सटीक संस्करण पिन करें और आवश्यक समीक्षा के साथ स्वचालित निर्भरता अद्यतन उपकरण (डिपेंडाबोट, रेनोवेट) का उपयोग करें, समय पर पैचिंग के साथ स्थिरता का संयोजन करें।
2726
EN + हिं Easy
GB What is 'twelve-factor app' methodology's stance on logs and what anti-pattern does it explicitly discourage?
IN लॉग पर 'बारह-कारक ऐप' पद्धति का रुख क्या है और यह किस विरोधी पैटर्न को स्पष्ट रूप से हतोत्साहित करता है?
A
Twelve-factor methodology mandates that all applications must write logs to a centralised database table बारह-कारक पद्धति यह अनिवार्य करती है कि सभी अनुप्रयोगों को एक केंद्रीकृत डेटाबेस तालिका में लॉग लिखना होगा
B
Twelve-factor treats logs as a stream of event data, written unbuffered to stdout — explicitly discouraging applications from managing their own log file rotation/storage/routing, since this couples the application to infrastructure concerns; instead, the execution environment captures stdout and routes it to the appropriate destination (file, log aggregator, etc.) बारह-कारक लॉग को इवेंट डेटा की एक धारा के रूप में मानता है, जिसे स्टडआउट के लिए असंबद्ध लिखा जाता है - स्पष्ट रूप से अनुप्रयोगों को अपने स्वयं के लॉग फ़ाइल रोटेशन / स्टोरेज / रूटिंग को प्रबंधित करने से हतोत्साहित करता है, क्योंकि यह एप्लिकेशन को बुनियादी ढांचे की चिंताओं से जोड़ता है; इसके बजाय, निष्पादन वातावरण stdout को कैप्चर करता है और इसे उचित गंतव्य (फ़ाइल, लॉग एग्रीगेटर, आदि) पर रूट करता है।
C
Twelve-factor app methodology recommends disabling all logging in production to maximise performance बारह-कारक ऐप कार्यप्रणाली प्रदर्शन को अधिकतम करने के लिए उत्पादन में सभी लॉगिंग को अक्षम करने की अनुशंसा करती है
D
This methodology requires every application to implement its own custom log rotation algorithm इस पद्धति के लिए प्रत्येक एप्लिकेशन को अपने स्वयं के कस्टम लॉग रोटेशन एल्गोरिदम को लागू करने की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Applications that manage their own log file paths, rotation schedules, and retention policies are coupled to filesystem assumptions that break in containerised/ephemeral environments (a container's filesystem is destroyed on restart, losing logs). By simply writing to stdout, the application remains environment-agnostic — Docker, Kubernetes, or systemd captures stdout and the platform-specific logging infrastructure (Fluentd, CloudWatch, Splunk) handles routing, storage, and rotation as an orthogonal infrastructure concern.
व्याख्या (हिन्दी) एप्लिकेशन जो अपने स्वयं के लॉग फ़ाइल पथ, रोटेशन शेड्यूल और अवधारण नीतियों का प्रबंधन करते हैं, वे फ़ाइल सिस्टम मान्यताओं से जुड़े होते हैं जो कंटेनरीकृत/क्षणिक वातावरण में टूट जाते हैं (एक कंटेनर का फ़ाइल सिस्टम पुनरारंभ होने पर नष्ट हो जाता है, लॉग खो जाता है)। केवल stdout पर लिखने से, एप्लिकेशन पर्यावरण-अज्ञेयवादी बना रहता है - डॉकर, कुबेरनेट्स, या सिस्टमडी stdout को कैप्चर करता है और प्लेटफ़ॉर्म-विशिष्ट लॉगिंग इंफ्रास्ट्रक्चर (फ्लुएंटडी, क्लाउडवॉच, स्प्लंक) एक ऑर्थोगोनल इंफ्रास्ट्रक्चर चिंता के रूप में रूटिंग, स्टोरेज और रोटेशन को संभालता है।
2716–2726 of 2726