Software Engineering — MCQ Practice

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

📚 647 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
647 questions
646
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 यूए-पार्सर-जेएस एनपीएम आपूर्ति श्रृंखला हमला रेंज जोखिम को दर्शाता है: दुर्भावनापूर्ण कोड को 'पैच' अपडेट के रूप में प्रकाशित किया गया था; श्रेणियों का उपयोग करने वाली परियोजनाएं स्वचालित रूप से समझौता किए गए संस्करण को खींच लेती हैं। इसके विपरीत, पिन की गई निर्भरताएं जो कभी भी अपडेट नहीं होती हैं वे चुपचाप ज्ञात कमजोरियों को जमा करती हैं (उदाहरण के लिए, इक्विफैक्स उल्लंघन आंशिक रूप से एक अप्रकाशित, पिन किए गए अपाचे स्ट्रट्स संस्करण के कारण था)। आधुनिक सर्वोत्तम अभ्यास: पुनरुत्पादन के लिए सटीक संस्करण पिन करें और आवश्यक समीक्षा के साथ स्वचालित निर्भरता अद्यतन उपकरण (डिपेंडाबोट, रेनोवेट) का उपयोग करें, समय पर पैचिंग के साथ स्थिरता का संयोजन करें।
647
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 को कैप्चर करता है और प्लेटफ़ॉर्म-विशिष्ट लॉगिंग इंफ्रास्ट्रक्चर (फ्लुएंटडी, क्लाउडवॉच, स्प्लंक) एक ऑर्थोगोनल इंफ्रास्ट्रक्चर चिंता के रूप में रूटिंग, स्टोरेज और रोटेशन को संभालता है।
646–647 of 647