631

EN + हिं Easy

GB What is 'database per service' pattern in microservices and what consistency trade-off does it introduce?

IN माइक्रोसर्विसेज में 'डेटाबेस प्रति सेवा' पैटर्न क्या है और यह किस स्थिरता व्यापार-बंद का परिचय देता है?

A

Database per service means each developer gets their own personal database for testing प्रति सेवा डेटाबेस का मतलब है कि प्रत्येक डेवलपर को परीक्षण के लिए अपना निजी डेटाबेस मिलता है

B

Each microservice owns and exclusively accesses its own database, with no other service allowed direct access — this enables service independence (schema changes don't break other services) but introduces the trade-off that queries spanning multiple services' data can no longer use simple SQL joins, requiring API composition or data duplication via events प्रत्येक माइक्रोसर्विस अपने स्वयं के डेटाबेस का मालिक है और विशेष रूप से उस तक पहुंचता है, किसी अन्य सेवा को सीधे पहुंच की अनुमति नहीं है - यह सेवा स्वतंत्रता को सक्षम बनाता है (स्कीमा परिवर्तन अन्य सेवाओं को नहीं तोड़ता है) लेकिन व्यापार-बंद का परिचय देता है कि एकाधिक सेवाओं के डेटा को फैलाने वाले प्रश्न अब सरल एसक्यूएल जॉइन का उपयोग नहीं कर सकते हैं, घटनाओं के माध्यम से एपीआई संरचना या डेटा डुप्लिकेशन की आवश्यकता होती है

C

Database per service is only applicable when using cloud-hosted databases; on-premise systems cannot use this pattern प्रति सेवा डेटाबेस केवल क्लाउड-होस्टेड डेटाबेस का उपयोग करते समय लागू होता है; ऑन-प्रिमाइसेस सिस्टम इस पैटर्न का उपयोग नहीं कर सकते

D

This pattern eliminates all data consistency concerns since each service has full control of its data यह पैटर्न सभी डेटा स्थिरता संबंधी चिंताओं को समाप्त कर देता है क्योंकि प्रत्येक सेवा का अपने डेटा पर पूर्ण नियंत्रण होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) A monolith's 'show me all orders with customer details and product names' is a simple SQL JOIN. In microservices with database-per-service, Orders, Customers, and Products live in separate databases owned by separate services — there's no cross-database JOIN. Solutions: API composition (call all three services, merge results in application code — slower, more complex) or maintaining a denormalised read-only copy of needed data via event subscription (faster reads, eventual consistency, additional storage).

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

632

EN + हिं Easy

GB What is 'sidecar pattern' in cloud-native architecture and what cross-cutting concerns does it typically handle?

IN क्लाउड-नेटिव आर्किटेक्चर में 'साइडकार पैटर्न' क्या है और यह आम तौर पर किन क्रॉस-कटिंग चिंताओं को संभालता है?

A

Sidecar pattern only applies to mobile applications running on motorcycle delivery apps साइडकार पैटर्न केवल मोटरसाइकिल डिलीवरी ऐप्स पर चलने वाले मोबाइल एप्लिकेशन पर लागू होता है

B

Sidecar pattern deploys a helper container alongside the main application container (in the same pod) to handle cross-cutting concerns — typically: service mesh networking (mTLS, retries, load balancing via Istio/Linkerd), logging aggregation, and configuration management — without modifying the main application's code साइडकार पैटर्न क्रॉस-कटिंग चिंताओं को संभालने के लिए मुख्य एप्लिकेशन कंटेनर (उसी पॉड में) के साथ एक सहायक कंटेनर तैनात करता है - आम तौर पर: सर्विस मेश नेटवर्किंग (एमटीएलएस, रिट्रीज़, इस्तियो/लिंकरड के माध्यम से लोड संतुलन), लॉगिंग एकत्रीकरण, और कॉन्फ़िगरेशन प्रबंधन - मुख्य एप्लिकेशन के कोड को संशोधित किए बिना

C

Sidecar pattern requires every microservice to be rewritten in the same programming language as the sidecar साइडकार पैटर्न के लिए प्रत्येक माइक्रोसर्विस को साइडकार के समान प्रोग्रामिंग भाषा में फिर से लिखने की आवश्यकता होती है

D

Sidecar containers replace the need for the main application container entirely साइडकार कंटेनर मुख्य एप्लिकेशन कंटेनर की आवश्यकता को पूरी तरह से बदल देते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Istio's Envoy sidecar intercepts all network traffic to/from the application container, handling mTLS encryption, retries, circuit breaking, and observability — without the application code knowing or caring. This separates infrastructure concerns (which evolve independently and require specialised expertise) from business logic (which the application team owns) — enabling polyglot microservices to get consistent networking behaviour regardless of their implementation language.

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

633

EN + हिं Easy

GB What is 'bulkhead pattern' in resilience engineering and what naval metaphor does it draw from?

IN लचीलापन इंजीनियरिंग में 'बल्कहेड पैटर्न' क्या है और यह किस नौसैनिक रूपक से लिया गया है?

A

Bulkhead pattern only applies to systems running on ships and maritime navigation software बल्कहेड पैटर्न केवल जहाजों और समुद्री नेविगेशन सॉफ़्टवेयर पर चलने वाले सिस्टम पर लागू होता है

B

The bulkhead pattern partitions system resources (thread pools, connection pools) into isolated groups so that failure or resource exhaustion in one partition doesn't cascade to others — drawn from ship bulkheads that compartmentalise the hull so a breach in one compartment doesn't sink the entire ship बल्कहेड पैटर्न विभाजन सिस्टम संसाधनों (थ्रेड पूल, कनेक्शन पूल) को अलग-अलग समूहों में विभाजित करता है ताकि एक विभाजन में विफलता या संसाधन की कमी दूसरों तक न पहुंचे - जहाज के बल्कहेड से तैयार किया गया है जो पतवार को विभाजित करता है ताकि एक डिब्बे में दरार से पूरा जहाज न डूब जाए।

C

Bulkhead pattern requires physically separate servers for every microservice with no shared infrastructure बल्कहेड पैटर्न के लिए प्रत्येक माइक्रोसर्विस के लिए बिना किसी साझा बुनियादी ढांचे के भौतिक रूप से अलग सर्वर की आवश्यकता होती है

D

Bulkhead pattern is identical to the circuit breaker pattern with no meaningful distinction बल्कहेड पैटर्न बिना किसी सार्थक अंतर के सर्किट ब्रेकर पैटर्न के समान है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Without bulkheads, a single slow downstream dependency (say, a recommendation service) consuming all available threads in a shared pool starves unrelated functionality (checkout) of threads, even though checkout doesn't depend on recommendations. Bulkheading allocates separate thread pools per dependency — recommendation service's slowness exhausts only its dedicated pool, leaving checkout's pool unaffected. This isolation principle (Netflix Hystrix popularised it) prevents one weak link from sinking the entire application.

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

634

EN + हिं Easy

GB What is 'strangler fig pattern' applied at the architectural level and what risk-managed migration strategy does it enable?

IN वास्तुशिल्प स्तर पर लागू 'स्ट्रैंगलर फ़िग पैटर्न' क्या है और यह किस जोखिम-प्रबंधित प्रवासन रणनीति को सक्षम बनाता है?

A

Strangler fig pattern requires complete system downtime during the entire migration period स्ट्रैंगलर अंजीर पैटर्न को संपूर्ण प्रवासन अवधि के दौरान पूर्ण सिस्टम डाउनटाइम की आवश्यकता होती है

B

At the architecture level, an intercepting facade (proxy/gateway) routes requests either to the legacy system or new system based on which functionality has been migrated — enabling incremental, low-risk migration where the legacy and new system coexist, with traffic gradually shifting feature by feature until the legacy system can be safely decommissioned वास्तुकला स्तर पर, एक इंटरसेप्टिंग मुखौटा (प्रॉक्सी/गेटवे) मार्ग या तो विरासत प्रणाली या नई प्रणाली के लिए अनुरोध करता है जिसके आधार पर कार्यक्षमता माइग्रेट की गई है - वृद्धिशील, कम जोखिम वाले प्रवासन को सक्षम करना जहां विरासत और नई प्रणाली सह-अस्तित्व में है, यातायात धीरे-धीरे सुविधा दर सुविधा स्थानांतरित हो रहा है जब तक कि विरासत प्रणाली को सुरक्षित रूप से डीकमीशन नहीं किया जा सकता है

C

Strangler fig pattern can only be applied to systems with fewer than 10 total features स्ट्रैंगलर अंजीर पैटर्न केवल 10 से कम कुल सुविधाओं वाले सिस्टम पर लागू किया जा सकता है

D

This pattern eliminates the need for any testing during the migration since old and new systems run in parallel यह पैटर्न माइग्रेशन के दौरान किसी भी परीक्षण की आवश्यकता को समाप्त कर देता है क्योंकि पुराने और नए सिस्टम समानांतर में चलते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) A large insurance company migrating a 20-year-old mainframe policy system might route new policy creation through a modern microservice while claims processing still routes to the mainframe. As each function is reimplemented and validated, the facade's routing rules update. The risk is bounded: if the new claims service has a bug, only claims (not the still-stable policy creation) is affected, and rollback is just a routing rule change — far safer than a 'big bang' cutover.

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

635

EN + हिं Easy

GB What is 'API gateway pattern' and what cross-cutting responsibilities does it centralise away from individual microservices?

IN 'एपीआई गेटवे पैटर्न' क्या है और यह व्यक्तिगत माइक्रोसर्विसेज से दूर किन क्रॉस-कटिंग जिम्मेदारियों को केंद्रीकृत करता है?

A

API gateway only forwards requests to backend services with no additional processing एपीआई गेटवे बिना किसी अतिरिक्त प्रोसेसिंग के केवल बैकएंड सेवाओं के अनुरोधों को अग्रेषित करता है

B

An API gateway centralises: authentication/authorisation (validate tokens once, not per service), rate limiting, request routing/composition, SSL termination, and response caching — removing the need for every individual microservice to implement these concerns redundantly, ensuring consistency and reducing per-service complexity एक एपीआई गेटवे केंद्रीकृत है: प्रमाणीकरण/प्राधिकरण (एक बार टोकन मान्य करें, प्रति सेवा नहीं), दर सीमित करना, अनुरोध रूटिंग/रचना, एसएसएल समाप्ति, और प्रतिक्रिया कैशिंग - इन चिंताओं को अनावश्यक रूप से लागू करने के लिए प्रत्येक व्यक्तिगत माइक्रोसर्विस की आवश्यकता को दूर करना, स्थिरता सुनिश्चित करना और प्रति-सेवा जटिलता को कम करना

C

API gateways are only used for mobile applications and cannot serve web or desktop clients एपीआई गेटवे का उपयोग केवल मोबाइल एप्लिकेशन के लिए किया जाता है और यह वेब या डेस्कटॉप क्लाइंट को सेवा प्रदान नहीं कर सकता है

D

Using an API gateway eliminates the possibility of a single point of failure in the architecture एपीआई गेटवे का उपयोग करने से आर्किटेक्चर में विफलता के एकल बिंदु की संभावना समाप्त हो जाती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Without a gateway, each of 30 microservices would need to independently implement JWT validation, rate limiting logic, and CORS handling — multiplying the chance of inconsistent or buggy implementations and the maintenance burden when auth requirements change. Centralising at the gateway means a single, well-tested implementation enforces these policies consistently. The trade-off acknowledged in the false option: the gateway itself becomes a critical component requiring high availability design (clustering, failover) since it's now a potential single point of failure.

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

636

EN + हिं Medium

GB What is 'hexagonal architecture's' relationship to dependency injection and why is the domain layer the only layer with zero framework dependencies?

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

A

Hexagonal architecture requires the domain layer to directly import the database driver for performance हेक्सागोनल आर्किटेक्चर को प्रदर्शन के लिए डेटाबेस ड्राइवर को सीधे आयात करने के लिए डोमेन परत की आवश्यकता होती है

B

Hexagonal architecture uses dependency injection to invert control: the domain layer defines interfaces (ports) that infrastructure (adapters) implements, so the domain depends only on its own abstractions, never on frameworks/databases/UI — this keeps business logic testable in isolation and portable across infrastructure changes (swap MySQL for PostgreSQL without touching domain code) हेक्सागोनल आर्किटेक्चर नियंत्रण को पलटने के लिए निर्भरता इंजेक्शन का उपयोग करता है: डोमेन परत उन इंटरफेस (पोर्ट) को परिभाषित करती है जो बुनियादी ढांचे (एडेप्टर) लागू करते हैं, इसलिए डोमेन केवल अपने स्वयं के अमूर्त पर निर्भर करता है, फ्रेमवर्क/डेटाबेस/यूआई पर कभी नहीं - यह व्यवसाय तर्क को अलगाव में परीक्षण योग्य रखता है और बुनियादी ढांचे में परिवर्तन के दौरान पोर्टेबल रखता है (डोमेन कोड को छुए बिना PostgreSQL के लिए MySQL को स्वैप करें)

C

All layers in hexagonal architecture must have identical dependencies for consistency हेक्सागोनल वास्तुकला में सभी परतों में स्थिरता के लिए समान निर्भरता होनी चाहिए

D

Hexagonal architecture cannot use dependency injection because it conflicts with the ports and adapters concept हेक्सागोनल आर्किटेक्चर निर्भरता इंजेक्शन का उपयोग नहीं कर सकता क्योंकि यह पोर्ट और एडेप्टर अवधारणा के साथ टकराव करता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) This is the practical implementation of DIP applied architecturally. The domain's OrderService depends on an abstract PaymentGatewayPort interface, not directly on StripeAdapter. At runtime, dependency injection wires the concrete StripeAdapter implementation in. Unit testing OrderService requires only a mock implementing PaymentGatewayPort — no real Stripe API, no database, no web framework. This is why hexagonal architecture's domain layer can achieve near-instant, fully isolated test execution.

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

637

EN + हिं Easy

GB What is 'static analysis' versus 'dynamic analysis' in code quality enforcement and what defect categories does each catch?

IN कोड गुणवत्ता प्रवर्तन में 'स्थैतिक विश्लेषण' बनाम 'गतिशील विश्लेषण' क्या है और प्रत्येक कौन सी दोष श्रेणियां पकड़ता है?

A

Static analysis only checks code formatting; dynamic analysis only checks runtime performance स्थैतिक विश्लेषण केवल कोड स्वरूपण की जाँच करता है; गतिशील विश्लेषण केवल रनटाइम प्रदर्शन की जाँच करता है

B

Static analysis (SonarQube, ESLint) examines source code without executing it — catching style violations, null pointer risks, unused variables, complexity thresholds; dynamic analysis (profilers, sanitizers) examines behaviour during actual execution — catching memory leaks, race conditions, actual performance bottlenecks that only manifest at runtime स्थैतिक विश्लेषण (सोनारक्यूब, ईएसलिंट) स्रोत कोड को निष्पादित किए बिना उसकी जांच करता है - शैली उल्लंघन, शून्य सूचक जोखिम, अप्रयुक्त चर, जटिलता थ्रेशोल्ड को पकड़ना; गतिशील विश्लेषण (प्रोफाइलर, सैनिटाइज़र) वास्तविक निष्पादन के दौरान व्यवहार की जांच करता है - मेमोरी लीक, दौड़ की स्थिति, वास्तविक प्रदर्शन बाधाओं को पकड़ना जो केवल रनटाइम पर प्रकट होते हैं

C

Static and dynamic analysis are identical techniques with different marketing names स्थैतिक और गतिशील विश्लेषण विभिन्न विपणन नामों वाली समान तकनीकें हैं

D

Static analysis can only be performed by human reviewers; dynamic analysis is always automated स्थैतिक विश्लेषण केवल मानव समीक्षकों द्वारा ही किया जा सकता है; गतिशील विश्लेषण हमेशा स्वचालित होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Static analysis is fast and runs on every commit but has false positives/negatives because it reasons about code without knowing actual runtime values. Dynamic analysis (ASan, race detectors, profilers) catches what only manifests when code actually runs with real data and timing — but requires execution, so it's slower and requires test coverage to exercise the relevant code paths. Comprehensive quality requires both.

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

638

EN + हिं Easy

GB What is 'linting' and what is the specific risk of over-aggressive linting rule enforcement on team productivity?

IN 'लिंटिंग' क्या है और टीम उत्पादकता पर अति-आक्रामक लिंटिंग नियम प्रवर्तन का विशिष्ट जोखिम क्या है?

A

Linting only checks for syntax errors that prevent code from compiling लिंटिंग केवल सिंटैक्स त्रुटियों की जाँच करता है जो कोड को संकलित होने से रोकता है

B

Linting analyses code for style and potential error patterns; over-aggressive enforcement (hundreds of strict rules, zero tolerance for any deviation) can create developer fatigue, encourage workarounds (disabling lint rules inline rather than fixing issues), and slow velocity disproportionate to the quality benefit gained लिंटिंग शैली और संभावित त्रुटि पैटर्न के लिए कोड का विश्लेषण करता है; अत्यधिक आक्रामक प्रवर्तन (सैकड़ों सख्त नियम, किसी भी विचलन के लिए शून्य सहनशीलता) डेवलपर थकान पैदा कर सकता है, वर्कअराउंड को प्रोत्साहित कर सकता है (समस्याओं को ठीक करने के बजाय लिंट नियमों को इनलाइन अक्षम कर सकता है), और प्राप्त गुणवत्ता लाभ के अनुपात में धीमी गति

C

Linting rules should always be set to maximum strictness regardless of team or project context टीम या प्रोजेक्ट संदर्भ की परवाह किए बिना लिंटिंग नियमों को हमेशा अधिकतम सख्ती पर सेट किया जाना चाहिए

D

Linting tools cannot be customised; all projects must use identical default rule sets लिंटिंग टूल को अनुकूलित नहीं किया जा सकता; सभी परियोजनाओं को समान डिफ़ॉल्ट नियम सेट का उपयोग करना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Effective lint configuration distinguishes correctness rules (catch actual bugs: unused variable that should be used, missing await) from stylistic preferences (single vs double quotes). Teams that enforce hundreds of stylistic rules with equal severity to correctness rules see developers add '// eslint-disable-next-line' comments reflexively, defeating the tool's purpose. Effective teams curate a focused rule set emphasising correctness, automate formatting (Prettier) to eliminate style debates entirely, and reserve human judgment for what tools cannot assess.

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

639

EN + हिं Easy

GB What is 'API versioning strategy' and what trade-off exists between URL versioning and header versioning?

IN 'एपीआई वर्जनिंग रणनीति' क्या है और यूआरएल वर्जनिंग और हेडर वर्जनिंग के बीच क्या समझौता मौजूद है?

A

API versioning is unnecessary if the API is well-documented; documentation alone prevents breaking changes यदि एपीआई अच्छी तरह से प्रलेखित है तो एपीआई संस्करण अनावश्यक है; केवल दस्तावेज़ीकरण ही परिवर्तनों को तोड़ने से रोकता है

B

URL versioning (/api/v2/users) is visible, cacheable, and easy to test but clutters the URL space and implies the resource itself changed; header versioning (Accept: application/vnd.api+json;version=2) keeps URLs clean and resource-focused but is less visible/discoverable and complicates caching and manual testing URL संस्करणीकरण (/api/v2/users) दृश्यमान, कैश करने योग्य और परीक्षण करने में आसान है, लेकिन URL स्थान को अव्यवस्थित कर देता है और इसका अर्थ है कि संसाधन स्वयं बदल गया है; हेडर वर्जनिंग (स्वीकार करें: एप्लिकेशन/vnd.api+json;version=2) यूआरएल को साफ और संसाधन-केंद्रित रखता है लेकिन कम दृश्यमान/खोजने योग्य होता है और कैशिंग और मैन्युअल परीक्षण को जटिल बनाता है

C

Both versioning strategies are functionally identical with zero practical differences दोनों संस्करण रणनीतियाँ शून्य व्यावहारिक अंतर के साथ कार्यात्मक रूप से समान हैं

D

API versioning is only relevant for public APIs; internal APIs never need version management एपीआई संस्करण केवल सार्वजनिक एपीआई के लिए प्रासंगिक है; आंतरिक एपीआई को कभी भी संस्करण प्रबंधन की आवश्यकता नहीं होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) URL versioning's visibility helps developers immediately understand which version they're calling and enables simple curl testing without header manipulation, but semantically the resource (/users/123) shouldn't change identity just because the representation format version changed. Header versioning maintains REST's principle that a resource has one URL regardless of representation, but requires developers to remember to set headers, complicating browser testing and proxy caching strategies that key on URL alone.

व्याख्या (हिन्दी) यूआरएल संस्करण की दृश्यता डेवलपर्स को तुरंत यह समझने में मदद करती है कि वे किस संस्करण को कॉल कर रहे हैं और हेडर हेरफेर के बिना सरल कर्ल परीक्षण को सक्षम बनाता है, लेकिन शब्दार्थ रूप से संसाधन (/ उपयोगकर्ता/123) को केवल इसलिए पहचान नहीं बदलनी चाहिए क्योंकि प्रतिनिधित्व प्रारूप संस्करण बदल गया है। हेडर संस्करण REST के सिद्धांत को बनाए रखता है कि एक संसाधन में प्रतिनिधित्व की परवाह किए बिना एक URL होता है, लेकिन डेवलपर्स को हेडर सेट करना याद रखना पड़ता है, जिससे ब्राउज़र परीक्षण और प्रॉक्सी कैशिंग रणनीतियाँ जटिल हो जाती हैं जो अकेले URL पर कुंजी लगाती हैं।

640

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

641

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() फेंक सकता है और कॉलर पकड़ नहीं पाता है, तो प्रोग्राम रनटाइम पर क्रैश हो जाता है, अक्सर वास्तविक त्रुटि स्रोत से बहुत दूर। रस्ट का परिणाम बल देता है: मैच डू समथिंग() { ओके(वी) => ..., इर(ई) => ... } - वर्बोज़ लेकिन कंपाइलर कोड को संकलित करने से इंकार कर देता है जो त्रुटि मामले को पूरी तरह से अनदेखा करता है। यह प्रत्येक त्रुटिपूर्ण ऑपरेशन के लिए अधिक बॉयलरप्लेट की कीमत पर, रनटाइम खोज से संकलन-समय रोकथाम में त्रुटि-हैंडलिंग बग को स्थानांतरित करता है।

642

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.

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

643

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.

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

644

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 दिनों के असंबंधित परिवर्तन जमा हो गए हैं; अब विलय के लिए संभावित रूप से सैकड़ों अतिव्यापी परिवर्तनों को समेटने की आवश्यकता होती है, जिसे अक्सर सही ढंग से हल करने के लिए दोनों शाखाओं के इरादे की गहरी समझ की आवश्यकता होती है। यह गैर-रैखिक विकास (न केवल अधिक संघर्ष, बल्कि तेजी से कठिन-से-कारण-संबंधी संघर्ष) यही कारण है कि ट्रंक-आधारित विकास और अल्पकालिक फीचर शाखाएं/झंडे अब लंबे समय तक चलने वाले गिटफ्लो-शैली फीचर शाखाओं पर व्यापक रूप से अनुशंसित हैं।

645

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.

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

Software Engineering — MCQ Practice