DBMS — MCQ Practice

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

📚 2982 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
2982 questions
2281
EN + हिं Medium
GB What is the application-level deadlock and how does it differ from database-level deadlock?
IN एप्लिकेशन-स्तरीय गतिरोध क्या है और यह डेटाबेस-स्तरीय गतिरोध से कैसे भिन्न है?
A
They are identical types of deadlocks वे समान प्रकार के गतिरोध हैं
B
Application-level deadlocks are faster to resolve एप्लिकेशन-स्तरीय गतिरोधों का समाधान तेजी से होता है
C
Application deadlocks cannot occur with a DBMS DBMS के साथ एप्लिकेशन गतिरोध उत्पन्न नहीं हो सकता
D
Application-level deadlock: occurs in application code (e.g. Thread A holds Java lock L1 waiting for Java lock L2; Thread B holds L2 waiting for L1) without involving database locks - the database itself is not deadlocked but the application threads are stuck. Different from DB deadlock where DBMS transactions hold DB locks circularly एप्लिकेशन-स्तरीय गतिरोध: एप्लिकेशन कोड में होता है (उदाहरण के लिए थ्रेड ए जावा लॉक एल1 को जावा लॉक एल2 के इंतजार में रखता है; थ्रेड बी एल2 को एल1 के इंतजार में रखता है) डेटाबेस लॉक को शामिल किए बिना - डेटाबेस स्वयं डेडलॉक नहीं है लेकिन एप्लिकेशन थ्रेड अटके हुए हैं। डीबी गतिरोध से भिन्न जहां डीबीएमएस लेनदेन डीबी लॉक को गोलाकार रूप से रखता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Application deadlock: circular waiting in application code (mutexes, semaphores, Java synchronized blocks). DBMS cannot detect this. Solution: application must implement its own deadlock detection or prevention (consistent lock ordering in application code, timeouts in application logic). Different from DBMS-level deadlocks that the DB detects/resolves.
व्याख्या (हिन्दी) एप्लिकेशन गतिरोध: एप्लिकेशन कोड में सर्कुलर प्रतीक्षा (म्यूटेक्स, सेमाफोर, जावा सिंक्रोनाइज्ड ब्लॉक)। DBMS इसका पता नहीं लगा सकता. समाधान: एप्लिकेशन को अपने स्वयं के गतिरोध का पता लगाने या रोकथाम (एप्लिकेशन कोड में लगातार लॉक ऑर्डर, एप्लिकेशन लॉजिक में टाइमआउट) को लागू करना होगा। DBMS-स्तर के गतिरोधों से भिन्न जिनका DB पता लगाता/समाधान करता है।
2282
EN + हिं Easy
GB What is the Bankers algorithm for deadlock avoidance and what information does it require?
IN गतिरोध से बचने के लिए बैंकर्स एल्गोरिदम क्या है और इसके लिए किस जानकारी की आवश्यकता है?
A
A resource allocation algorithm that determines whether granting a resource request leaves the system in a safe state; requires: for each transaction - maximum resource needs declared in advance current allocation and remaining need; safe state = exists a sequence in which all transactions can complete using available resources एक संसाधन आवंटन एल्गोरिदम जो यह निर्धारित करता है कि संसाधन अनुरोध देने से सिस्टम सुरक्षित स्थिति में रहता है या नहीं; आवश्यक है: प्रत्येक लेनदेन के लिए - अधिकतम संसाधन आवश्यकताओं की घोषणा अग्रिम वर्तमान आवंटन और शेष आवश्यकता; सुरक्षित स्थिति = एक अनुक्रम मौजूद है जिसमें सभी लेनदेन उपलब्ध संसाधनों का उपयोग करके पूरा किया जा सकता है
B
An algorithm for distributing resources evenly among transactions लेन-देन के बीच संसाधनों को समान रूप से वितरित करने के लिए एक एल्गोरिदम
C
A financial transaction scheduling algorithm एक वित्तीय लेनदेन शेड्यूलिंग एल्गोरिदम
D
A banking application algorithm for managing transactions लेनदेन के प्रबंधन के लिए एक बैंकिंग एप्लिकेशन एल्गोरिदम
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Bankers algorithm: Safe state check before each allocation. Data needed: Available (resources currently free), Max (maximum needs per transaction), Allocation (current allocation), Need (Max - Allocation). Safety check: find a transaction whose Need <= Available, simulate completion (release allocation), repeat. If all transactions can complete: safe state, grant. Else: deny and wait.
व्याख्या (हिन्दी) बैंकर्स एल्गोरिदम: प्रत्येक आवंटन से पहले सुरक्षित स्थिति की जांच। आवश्यक डेटा: उपलब्ध (संसाधन वर्तमान में निःशुल्क), अधिकतम (प्रति लेनदेन अधिकतम आवश्यकताएं), आवंटन (वर्तमान आवंटन), आवश्यकता (अधिकतम - आवंटन)। सुरक्षा जांच: ऐसा लेन-देन ढूंढें जिसकी आवश्यकता है
2283
EN + हिं Easy
GB What is the hold-and-wait Coffman condition and what strategies eliminate it in database systems?
IN होल्ड-एंड-वेट कॉफ़मैन स्थिति क्या है और कौन सी रणनीतियाँ डेटाबेस सिस्टम में इसे समाप्त करती हैं?
A
Hold-and-wait: a transaction holds one or more resources (locks) while waiting to acquire additional resources it needs. Elimination strategies: (1) Require all-or-nothing lock acquisition (acquire ALL needed locks at once before starting) (2) Release all current locks before requesting new ones (3) Use timeout-based retry after releasing होल्ड-एंड-वेट: एक लेनदेन आवश्यक अतिरिक्त संसाधनों को प्राप्त करने की प्रतीक्षा करते समय एक या अधिक संसाधनों (लॉक) को रखता है। उन्मूलन रणनीतियाँ: (1) सभी या कुछ भी नहीं लॉक अधिग्रहण की आवश्यकता है (शुरू करने से पहले सभी आवश्यक लॉक एक साथ प्राप्त करें) (2) नए लॉक का अनुरोध करने से पहले सभी मौजूदा लॉक जारी करें (3) जारी करने के बाद टाइमआउट-आधारित पुनः प्रयास का उपयोग करें
B
A performance optimization for lock management लॉक प्रबंधन के लिए एक प्रदर्शन अनुकूलन
C
Holding locks for too long during transactions लेन-देन के दौरान बहुत देर तक ताले लटकाए रखना
D
A condition where all resources are held by one transaction ऐसी स्थिति जहां सभी संसाधन एक लेनदेन द्वारा रखे जाते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hold-and-wait elimination: (1) All-or-nothing: declare all needed locks upfront, acquire atomically (difficult - often do not know all needs in advance). (2) Release before requesting (conservative): release all current locks when requesting new ones (causes restart overhead). Both are impractical for most real workloads. This is why most systems detect deadlocks rather than prevent hold-and-wait.
व्याख्या (हिन्दी) होल्ड-एंड-वेट उन्मूलन: (1) सभी या कुछ भी नहीं: सभी आवश्यक तालों को अग्रिम रूप से घोषित करें, परमाणु रूप से प्राप्त करें (कठिन - अक्सर सभी जरूरतों को पहले से नहीं जानते हैं)। (2) अनुरोध करने से पहले रिलीज़ करें (रूढ़िवादी): नए लॉक का अनुरोध करते समय सभी मौजूदा लॉक को रिलीज़ करें (ओवरहेड पुनरारंभ होने का कारण बनता है)। अधिकांश वास्तविक कार्यभार के लिए दोनों अव्यावहारिक हैं। यही कारण है कि अधिकांश सिस्टम होल्ड-एंड-वेट को रोकने के बजाय गतिरोध का पता लगाते हैं।
2284
EN + हिं Easy
GB What is the no-preemption Coffman condition and how can preemption be introduced to break deadlocks?
IN नो-प्रीएम्प्शन कॉफ़मैन स्थिति क्या है और गतिरोध को तोड़ने के लिए प्रीएम्प्शन को कैसे लागू किया जा सकता है?
A
Preemption means stopping a transaction without completing it प्रीएम्प्शन का अर्थ है किसी लेन-देन को पूरा किए बिना रोकना
B
Preemption only works for shared locks प्रीएम्प्शन केवल साझा तालों के लिए काम करता है
C
Preemption requires explicit transaction consent प्रीएम्प्शन के लिए स्पष्ट लेनदेन सहमति की आवश्यकता होती है
D
No preemption means that resources (locks) cannot be forcibly taken from a transaction holding them. Preemption can be introduced by: aborting (preempting) a deadlocked transaction (victim selection) which is how deadlock resolution works - the DBMS forcibly rolls back a chosen victim transaction releasing its locks for other waiting transactions नो प्रीएम्प्शन का मतलब यह है कि संसाधनों (ताले) को उनके पास मौजूद लेनदेन से जबरन नहीं लिया जा सकता है। प्रीएम्प्शन को इसके द्वारा प्रस्तुत किया जा सकता है: एक गतिरोध वाले लेनदेन को निरस्त करना (पीड़ित चयन) जो कि गतिरोध समाधान कैसे काम करता है - डीबीएमएस जबरन चुने गए पीड़ित लेनदेन को वापस लाता है और अन्य प्रतीक्षा लेनदेन के लिए अपने ताले जारी करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) No-preemption elimination (deadlock resolution): when deadlock detected, the DBMS selects a victim transaction and aborts it (preempts its resources). This forcibly takes the victim transactionssource (locks) and releases them. The Wound-Wait prevention scheme also introduces preemption: older transactions can wound (abort) younger transactions holding needed resources.
व्याख्या (हिन्दी) नो-प्रीएम्पशन उन्मूलन (गतिरोध समाधान): जब गतिरोध का पता चलता है, तो डीबीएमएस एक पीड़ित लेनदेन का चयन करता है और इसे निरस्त कर देता है (अपने संसाधनों को रोक देता है)। यह पीड़ित के लेनदेनस्रोत को जबरन ले लेता है (ताले लगा देता है) और उन्हें छोड़ देता है। घाव-प्रतीक्षा रोकथाम योजना प्रीएम्प्शन का भी परिचय देती है: पुराने लेनदेन आवश्यक संसाधनों को रखने वाले युवा लेनदेन को समाप्त (निरस्त) कर सकते हैं।
2285
EN + हिं Medium
GB What is the difference between deadlock detection frequency and deadlock detection latency?
IN डेडलॉक डिटेक्शन फ़्रीक्वेंसी और डेडलॉक डिटेक्शन विलंबता के बीच क्या अंतर है?
A
Detection frequency: how often the deadlock detector runs (e.g. every 100ms or every N lock requests); Detection latency: how long a deadlock persists before being detected and resolved (= time to next detection run + detection + abort time). Trade-off: higher frequency = lower latency but higher CPU overhead from running detection; lower frequency = lower overhead but deadlocked transactions blocked longer पता लगाने की आवृत्ति: डेडलॉक डिटेक्टर कितनी बार चलता है (उदाहरण के लिए प्रत्येक 100 एमएस या प्रत्येक एन लॉक अनुरोध); डिटेक्शन विलंबता: पता लगाने और हल करने से पहले कितने समय तक गतिरोध बना रहता है (= अगली डिटेक्शन रन का समय + डिटेक्शन + निरस्त समय)। ट्रेड-ऑफ: उच्च आवृत्ति = कम विलंबता लेकिन रनिंग डिटेक्शन से उच्च सीपीयू ओवरहेड; कम आवृत्ति = कम ओवरहेड लेकिन गतिरोध वाले लेनदेन लंबे समय तक अवरुद्ध रहते हैं
B
Frequency refers to number of deadlocks; latency refers to resolution time आवृत्ति से तात्पर्य गतिरोधों की संख्या से है; विलंबता का तात्पर्य समाधान समय से है
C
Detection frequency only applies to distributed deadlocks पता लगाने की आवृत्ति केवल वितरित गतिरोधों पर लागू होती है
D
They are the same concept वे एक ही अवधारणा हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Detection frequency vs latency trade-off: If detection runs every 5 seconds: deadlocks may persist up to 5 seconds (blocking other transactions for that duration). If detection runs every 10ms: very low latency but CPU overhead from constant graph scanning. MySQL InnoDB: detects deadlocks immediately after each lock wait (very low latency, efficient because it only checks affected transactions not the whole graph).
व्याख्या (हिन्दी) डिटेक्शन फ़्रीक्वेंसी बनाम विलंबता ट्रेड-ऑफ़: यदि डिटेक्शन हर 5 सेकंड में चलता है: गतिरोध 5 सेकंड तक बना रह सकता है (उस अवधि के लिए अन्य लेनदेन को अवरुद्ध करना)। यदि डिटेक्शन हर 10ms पर चलता है: बहुत कम विलंबता लेकिन निरंतर ग्राफ़ स्कैनिंग से CPU ओवरहेड। MySQL InnoDB: प्रत्येक लॉक प्रतीक्षा के तुरंत बाद गतिरोध का पता लगाता है (बहुत कम विलंबता, कुशल क्योंकि यह केवल प्रभावित लेनदेन की जांच करता है, पूरे ग्राफ की नहीं)।
2286
EN + हिं Easy
GB What is cycle prevention vs cycle detection in the context of deadlock management strategies?
IN गतिरोध प्रबंधन रणनीतियों के संदर्भ में चक्र रोकथाम बनाम चक्र पहचान क्या है?
A
Prevention always outperforms detection रोकथाम हमेशा पता लगाने से बेहतर प्रदर्शन करती है
B
They are different terms for the same approach वे एक ही दृष्टिकोण के लिए अलग-अलग शब्द हैं
C
Detection is always preferred over prevention रोकथाम की तुलना में जांच को हमेशा प्राथमिकता दी जाती है
D
Cycle prevention: design the system so that cycles in the wait-for graph cannot form (e.g., lock ordering, Wait-Die, Wound-Wait, no-wait) - proactive approach that adds overhead to every transaction. Cycle detection: allow cycles to form then detect and break them periodically (e.g., wait-for graph cycle detection) - reactive approach lower per-transaction overhead but deadlocks persist briefly चक्र रोकथाम: सिस्टम को डिज़ाइन करें ताकि वेट-फॉर ग्राफ़ में चक्र न बन सकें (जैसे, लॉक ऑर्डरिंग, वेट-डाई, वाउंड-वेट, नो-वेट) - सक्रिय दृष्टिकोण जो हर लेनदेन में ओवरहेड जोड़ता है। चक्र का पता लगाना: चक्रों को बनने की अनुमति दें, फिर समय-समय पर उनका पता लगाएं और उन्हें तोड़ें (उदाहरण के लिए, ग्राफ़ चक्र का पता लगाने के लिए प्रतीक्षा करें) - प्रतिक्रियाशील दृष्टिकोण कम प्रति-लेन-देन ओवरहेड लेकिन गतिरोध थोड़े समय के लिए बना रहता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Prevention vs Detection trade-offs: Prevention overhead: every lock acquisition must check ordering rules or timestamp comparison - overhead even when no deadlock. Detection overhead: periodic graph scan or per-wait-graph update - overhead only when waits exist, but deadlocks briefly persist. Most OLTP DBMS use detection (InnoDB) because prevention (like lock ordering) is too restrictive for application developers to maintain.
व्याख्या (हिन्दी) रोकथाम बनाम जांच व्यापार-बंद: रोकथाम ओवरहेड: प्रत्येक लॉक अधिग्रहण को ऑर्डरिंग नियमों या टाइमस्टैम्प तुलना की जांच करनी चाहिए - कोई गतिरोध न होने पर भी ओवरहेड। डिटेक्शन ओवरहेड: आवधिक ग्राफ स्कैन या प्रति-प्रतीक्षा-ग्राफ अद्यतन - ओवरहेड केवल तभी जब प्रतीक्षा मौजूद होती है, लेकिन गतिरोध थोड़े समय के लिए बना रहता है। अधिकांश ओएलटीपी डीबीएमएस डिटेक्शन (इनोडीबी) का उपयोग करते हैं क्योंकि रोकथाम (जैसे लॉक ऑर्डरिंग) एप्लिकेशन डेवलपर्स के लिए बनाए रखने के लिए बहुत प्रतिबंधात्मक है।
2287
EN + हिं Easy
GB What is the innodb_deadlock_detect system variable in MySQL and what is the alternative when it is disabled?
IN MySQL में innodb_deadlock_detect सिस्टम वेरिएबल क्या है और इसके अक्षम होने पर विकल्प क्या है?
A
innodb_deadlock_detect=ON (default): InnoDB actively detects deadlocks using a wait-for graph and immediately resolves them by aborting a victim. innodb_deadlock_detect=OFF: deadlock detection is disabled; the lock wait timeout (innodb_lock_wait_timeout) becomes the only mechanism to break deadlocks - transactions wait until timeout then abort. Disabling detection reduces overhead in very high-concurrency scenarios but increases worst-case deadlock resolution time. innodb_deadlock_detect=ON (डिफ़ॉल्ट): InnoDB सक्रिय रूप से प्रतीक्षा-ग्राफ़ का उपयोग करके गतिरोधों का पता लगाता है और पीड़ित को गर्भपात करके तुरंत उनका समाधान करता है। innodb_deadlock_detect=OFF: गतिरोध का पता लगाना अक्षम है; लॉक वेट टाइमआउट (innodb_lock_wait_timeout) गतिरोध को तोड़ने का एकमात्र तंत्र बन जाता है - लेनदेन टाइमआउट तक प्रतीक्षा करते हैं और फिर निरस्त हो जाते हैं। पहचान को अक्षम करने से बहुत उच्च-समवर्ती परिदृश्यों में ओवरहेड कम हो जाता है लेकिन सबसे खराब स्थिति में गतिरोध समाधान समय बढ़ जाता है।
B
It controls the deadlock timeout value यह डेडलॉक टाइमआउट मान को नियंत्रित करता है
C
It controls whether deadlocks are logged to the error log यह नियंत्रित करता है कि त्रुटि लॉग में गतिरोध लॉग हैं या नहीं
D
It determines which transaction becomes the deadlock victim यह निर्धारित करता है कि कौन सा लेनदेन गतिरोध का शिकार बनेगा
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) innodb_deadlock_detect: ON = active detection (default, recommended for most workloads). OFF = use timeout-only for resolution. Use case for OFF: extremely high concurrency systems where the deadlock detection mutex itself becomes a bottleneck (the detection latch protects the wait-for graph - under extremely high concurrent locking, this latch becomes a serialization point). Alternative: use innodb_lock_wait_timeout with a short value (e.g., 5 seconds).
व्याख्या (हिन्दी) innodb_deadlock_detect: ON = सक्रिय पहचान (डिफ़ॉल्ट, अधिकांश कार्यभार के लिए अनुशंसित)। बंद = समाधान के लिए केवल टाइमआउट का उपयोग करें। ऑफ के लिए केस का उपयोग करें: अत्यधिक उच्च समवर्ती प्रणाली जहां डेडलॉक डिटेक्शन म्यूटेक्स स्वयं एक बाधा बन जाता है (डिटेक्शन लैच प्रतीक्षा-ग्राफ की सुरक्षा करता है - अत्यधिक उच्च समवर्ती लॉकिंग के तहत, यह लैच एक क्रमबद्धता बिंदु बन जाता है)। वैकल्पिक: कम मान (जैसे, 5 सेकंड) के साथ innodb_lock_wait_timeout का उपयोग करें।
2288
EN + हिं Easy
GB What are the implications of deadlocks in distributed microservices systems that use distributed transactions (SAGA pattern)?
IN वितरित लेनदेन (एसएजीए पैटर्न) का उपयोग करने वाले वितरित माइक्रोसर्विसेज सिस्टम में गतिरोध के निहितार्थ क्या हैं?
A
Deadlocks in microservices require manual DBA intervention माइक्रोसर्विसेज में गतिरोध के लिए मैन्युअल डीबीए हस्तक्षेप की आवश्यकता होती है
B
In SAGA-based distributed transactions traditional database deadlocks at the local level can still occur within each services database; additionally SAGA introduces higher-level semantic deadlocks where multiple sagas wait for each other to complete compensating actions or where resource locks across services create circular dependencies - resolved by designing sagas to acquire resources in consistent order and implementing timeouts for saga steps एसएजीए-आधारित वितरित लेनदेन में स्थानीय स्तर पर पारंपरिक डेटाबेस गतिरोध अभी भी प्रत्येक सेवा डेटाबेस के भीतर हो सकता है; इसके अतिरिक्त SAGA उच्च-स्तरीय सिमेंटिक गतिरोधों का परिचय देता है, जहां कई गाथाएं क्षतिपूर्ति कार्यों को पूरा करने के लिए एक-दूसरे की प्रतीक्षा करती हैं या जहां सेवाओं में संसाधन लॉक परिपत्र निर्भरताएं बनाते हैं - सुसंगत क्रम में संसाधनों को प्राप्त करने के लिए गाथाओं को डिजाइन करके और गाथा चरणों के लिए टाइमआउट लागू करके हल किया जाता है।
C
SAGA eliminates all deadlock possibilities SAGA सभी गतिरोध संभावनाओं को समाप्त कर देता है
D
SAGA prevents deadlocks by eliminating all locking SAGA सभी लॉकिंग को समाप्त करके गतिरोध को रोकता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Distributed microservice deadlocks: (1) Local deadlocks: each service may have deadlocks within its own database (handled by individual DBMS deadlock detection). (2) Saga-level deadlocks: uncommon but possible when sagas hold semantic locks (reservation of resources) in circular dependencies. Prevention: define saga ordering rules, implement step timeouts, use choreography with event-based coordination to reduce blocking.
व्याख्या (हिन्दी) वितरित माइक्रोसर्विस गतिरोध: (1) स्थानीय गतिरोध: प्रत्येक सेवा के अपने डेटाबेस में गतिरोध हो सकते हैं (व्यक्तिगत डीबीएमएस गतिरोध का पता लगाने द्वारा नियंत्रित)। (2) सागा-स्तरीय गतिरोध: असामान्य लेकिन संभव है जब सागा परिपत्र निर्भरता में सिमेंटिक लॉक (संसाधनों का आरक्षण) रखता है। रोकथाम: सागा ऑर्डरिंग नियमों को परिभाषित करें, चरण टाइमआउट लागू करें, अवरोधन को कम करने के लिए इवेंट-आधारित समन्वय के साथ कोरियोग्राफी का उपयोग करें।
2289
EN + हिं Easy
GB What is role-based access control (RBAC) in database security?
IN डेटाबेस सुरक्षा में भूमिका-आधारित अभिगम नियंत्रण (आरबीएसी) क्या है?
A
RBAC: privileges are assigned to roles (logical groups) and roles are assigned to users; changing a roles privileges automatically affects all users with that role. Direct grants: privileges assigned directly to individual users making management complex and error-prone at scale आरबीएसी: विशेषाधिकार भूमिकाओं (तार्किक समूहों) को सौंपे जाते हैं और भूमिकाएं उपयोगकर्ताओं को सौंपी जाती हैं; किसी भूमिका के विशेषाधिकार बदलने से उस भूमिका वाले सभी उपयोगकर्ता स्वचालित रूप से प्रभावित होते हैं। प्रत्यक्ष अनुदान: प्रबंधन को जटिल और बड़े पैमाने पर त्रुटि-प्रवण बनाने वाले व्यक्तिगत उपयोगकर्ताओं को सीधे दिए गए विशेषाधिकार
B
Roles can only be assigned to database administrators भूमिकाएँ केवल डेटाबेस प्रशासकों को सौंपी जा सकती हैं
C
RBAC is weaker than direct privilege grants आरबीएसी प्रत्यक्ष विशेषाधिकार अनुदान से कमजोर है
D
RBAC is identical to direct privilege grants आरबीएसी प्रत्यक्ष विशेषाधिकार अनुदान के समान है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) RBAC example: CREATE ROLE analyst_role; GRANT SELECT ON sales TO analyst_role; GRANT analyst_role TO alice, bob, charlie. Adding new analyst: GRANT analyst_role TO dave (one command). Changing analyst privileges: ALTER ROLE analyst_role (affects all automatically). Direct grants: 4 individual GRANT commands, error-prone.
व्याख्या (हिन्दी) आरबीएसी उदाहरण: भूमिका विश्लेषक_भूमिका बनाएं; विश्लेषक_भूमिका को बिक्री पर अनुदान चयन; ऐलिस, बॉब, चार्ली को विश्लेषक की भूमिका प्रदान करें। नया विश्लेषक जोड़ा जा रहा है: डेव को विश्लेषक की भूमिका प्रदान करें (एक आदेश)। विश्लेषक विशेषाधिकार बदलना: भूमिका विश्लेषक_भूमिका बदलें (सभी को स्वचालित रूप से प्रभावित करता है)। प्रत्यक्ष अनुदान: 4 व्यक्तिगत अनुदान आदेश, त्रुटि-प्रवण।
2290
EN + हिं Medium
GB What is row-level security (RLS) and how does it differ from view-based row filtering?
IN पंक्ति-स्तरीय सुरक्षा (आरएलएस) क्या है और यह दृश्य-आधारित पंक्ति फ़िल्टरिंग से कैसे भिन्न है?
A
RLS is only available in NoSQL databases RLS केवल NoSQL डेटाबेस में उपलब्ध है
B
RLS requires application code to implement आरएलएस को लागू करने के लिए एप्लिकेशन कोड की आवश्यकता होती है
C
RLS is a database feature where security policies are automatically applied to queries at the database level based on the executing user/role transparently filtering rows without requiring application code or view modifications; views require explicit usage and can be bypassed if user has direct table access आरएलएस एक डेटाबेस सुविधा है जहां सुरक्षा नीतियां स्वचालित रूप से एप्लिकेशन कोड या दृश्य संशोधनों की आवश्यकता के बिना निष्पादित उपयोगकर्ता/भूमिका के आधार पर पंक्तियों को पारदर्शी रूप से फ़िल्टर करने वाले डेटाबेस स्तर पर प्रश्नों पर लागू होती हैं; दृश्यों के लिए स्पष्ट उपयोग की आवश्यकता होती है और यदि उपयोगकर्ता के पास सीधी तालिका पहुंच है तो इसे बायपास किया जा सकता है
D
RLS and view-based filtering are identical आरएलएस और दृश्य-आधारित फ़िल्टरिंग समान हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) RLS (PostgreSQL): CREATE POLICY emp_policy ON employee FOR SELECT USING (dept = current_user_dept()); ALTER TABLE employee ENABLE ROW LEVEL SECURITY. Any SELECT on employee automatically filters by department even if user queries the base table directly. Cannot be bypassed by the restricted user.
व्याख्या (हिन्दी) आरएलएस (पोस्टग्रेएसक्यूएल): चुनिंदा उपयोग के लिए कर्मचारी पर नीति emp_policy बनाएं (विभाग = current_user_dept()); परिवर्तन तालिका कर्मचारी पंक्ति स्तरीय सुरक्षा सक्षम करें। कर्मचारी पर कोई भी चयन स्वचालित रूप से विभाग द्वारा फ़िल्टर किया जाता है, भले ही उपयोगकर्ता सीधे आधार तालिका पर सवाल उठाता हो। प्रतिबंधित उपयोगकर्ता द्वारा बायपास नहीं किया जा सकता.
2291
EN + हिं Easy
GB What is transparent data encryption (TDE) and what threat does it protect against?
IN पारदर्शी डेटा एन्क्रिप्शन (टीडीई) क्या है और यह किस खतरे से बचाता है?
A
Database-level encryption where data files log files and backups are encrypted on disk automatically by the DBMS without application changes; protects against: theft of physical storage media unauthorized access to database file copies but does NOT protect against authorized database users or SQL injection डेटाबेस-स्तरीय एन्क्रिप्शन जहां डेटा फ़ाइलें लॉग फ़ाइलें और बैकअप एप्लिकेशन परिवर्तन के बिना डीबीएमएस द्वारा स्वचालित रूप से डिस्क पर एन्क्रिप्ट की जाती हैं; इनसे सुरक्षा करता है: भौतिक भंडारण मीडिया की चोरी, डेटाबेस फ़ाइल प्रतियों तक अनधिकृत पहुंच, लेकिन अधिकृत डेटाबेस उपयोगकर्ताओं या SQL इंजेक्शन से सुरक्षा नहीं करता है
B
Encryption applied transparently to all SQL results एन्क्रिप्शन सभी SQL परिणामों पर पारदर्शी रूप से लागू किया गया
C
Encryption that is visible to database users एन्क्रिप्शन जो डेटाबेस उपयोगकर्ताओं को दिखाई देता है
D
Encryption of the database schema definition डेटाबेस स्कीमा परिभाषा का एन्क्रिप्शन
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) TDE protection: physical media theft (stolen hard drive has encrypted data = unreadable without DBMS key). Backup file theft (encrypted backup file is unreadable without key). Does NOT protect: legitimate DB user with SELECT privilege, DBA accounts, in-memory data during query execution, or SQL injection attacks.
व्याख्या (हिन्दी) टीडीई सुरक्षा: भौतिक मीडिया चोरी (चोरी की गई हार्ड ड्राइव में एन्क्रिप्टेड डेटा = डीबीएमएस कुंजी के बिना अपठनीय है)। बैकअप फ़ाइल चोरी (एन्क्रिप्टेड बैकअप फ़ाइल कुंजी के बिना अपठनीय है)। सुरक्षा नहीं करता: SELECT विशेषाधिकार के साथ वैध DB उपयोगकर्ता, DBA खाते, क्वेरी निष्पादन के दौरान इन-मेमोरी डेटा, या SQL इंजेक्शन हमले।
2292
EN + हिं Easy
GB What is data masking (static vs dynamic) in database security?
IN डेटाबेस सुरक्षा में डेटा मास्किंग (स्थैतिक बनाम गतिशील) क्या है?
A
Static data masking: permanently replaces sensitive data with realistic but fictitious values in non-production copies. Dynamic data masking: applies masking rules at query time for specific users returning masked values while original data remains stored unchanged स्टेटिक डेटा मास्किंग: गैर-उत्पादन प्रतियों में संवेदनशील डेटा को यथार्थवादी लेकिन काल्पनिक मूल्यों से स्थायी रूप से बदल देता है। डायनामिक डेटा मास्किंग: विशिष्ट उपयोगकर्ताओं के लिए क्वेरी समय पर मास्किंग नियम लागू करता है, जो मास्क्ड मान लौटाते हैं, जबकि मूल डेटा अपरिवर्तित रहता है
B
Compressing data for storage efficiency भंडारण दक्षता के लिए डेटा को संपीड़ित करना
C
Encrypting data before storage भंडारण से पहले डेटा एन्क्रिप्ट करना
D
Hiding column names from users उपयोगकर्ताओं से कॉलम नाम छुपाया जा रहा है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Static masking: copy prod data, apply irreversible masks (SSN 123-45-6789 becomes 999-99-9999), give to dev team. Data cannot be unmasked. Dynamic masking (SQL Server, Oracle): DBA sees real SSN, app user sees masked value. Applied at query time. Useful for: partial data visibility, customer service seeing only last 4 digits.
व्याख्या (हिन्दी) स्टेटिक मास्किंग: उत्पाद डेटा कॉपी करें, अपरिवर्तनीय मास्क लागू करें (एसएसएन 123-45-6789 999-99-9999 बन जाता है), डेव टीम को दें। डेटा को उजागर नहीं किया जा सकता. डायनेमिक मास्किंग (एसक्यूएल सर्वर, ओरेकल): डीबीए वास्तविक एसएसएन देखता है, ऐप उपयोगकर्ता मास्क्ड वैल्यू देखता है। क्वेरी के समय लागू किया गया. इसके लिए उपयोगी: आंशिक डेटा दृश्यता, ग्राहक सेवा केवल अंतिम 4 अंक देखती है।
2293
EN + हिं Easy
GB What is discretionary access control (DAC) vs mandatory access control (MAC)?
IN विवेकाधीन अभिगम नियंत्रण (डीएसी) बनाम अनिवार्य अभिगम नियंत्रण (एमएसी) क्या है?
A
DAC is stricter than MAC DAC, MAC से अधिक सख्त है
B
DAC: resource owners control access permissions (GRANT/REVOKE by object owner) - flexible but owners can grant to anyone. MAC: system-enforced labels on data and users (e.g. TOP SECRET data accessible only by TOP SECRET cleared users) owner cannot override - used in government/defense systems डीएसी: संसाधन मालिक पहुंच अनुमतियों को नियंत्रित करते हैं (ऑब्जेक्ट मालिक द्वारा अनुदान/निरस्त) - लचीला लेकिन मालिक किसी को भी अनुमति दे सकते हैं। मैक: डेटा और उपयोगकर्ताओं पर सिस्टम-प्रवर्तित लेबल (उदाहरण के लिए टॉप सीक्रेट डेटा केवल टॉप सीक्रेट क्लियर किए गए उपयोगकर्ताओं द्वारा पहुंच योग्य) मालिक ओवरराइड नहीं कर सकता - सरकारी/रक्षा प्रणालियों में उपयोग किया जाता है
C
MAC is less secure than DAC MAC, DAC की तुलना में कम सुरक्षित है
D
They provide identical security guarantees वे समान सुरक्षा गारंटी प्रदान करते हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) DAC (most commercial DBMS): table owner grants SELECT to User A, who might GRANT WITH GRANT OPTION to User B. MAC (e.g., Oracle Label Security): data labeled CONFIDENTIAL, user has CONFIDENTIAL clearance, system enforces - no owner override. Bell-LaPadula model (read down, write up) for classification systems.
व्याख्या (हिन्दी) डीएसी (अधिकांश वाणिज्यिक डीबीएमएस): टेबल मालिक उपयोगकर्ता ए को चयन अनुदान देता है, जो उपयोगकर्ता बी को अनुदान विकल्प प्रदान कर सकता है। मैक (उदाहरण के लिए, ओरेकल लेबल सुरक्षा): गोपनीय लेबल वाला डेटा, उपयोगकर्ता के पास गोपनीय मंजूरी है, सिस्टम लागू करता है - कोई मालिक ओवरराइड नहीं करता है। वर्गीकरण प्रणालियों के लिए बेल-लापैडुला मॉडल (नीचे पढ़ें, लिखें)।
2294
EN + हिं Easy
GB What is database auditing and what are the key events that should be audited?
IN डेटाबेस ऑडिटिंग क्या है और कौन सी प्रमुख घटनाएँ हैं जिनका ऑडिट किया जाना चाहिए?
A
Testing database performance metrics डेटाबेस प्रदर्शन मेट्रिक्स का परीक्षण
B
Performing regular backups of the database डेटाबेस का नियमित बैकअप करना
C
Recording and monitoring database activities for security analysis compliance and forensics; key events to audit: all DDL changes privilege grants/revokes failed login attempts access to sensitive tables (PII financial) privileged user actions and unusual query patterns सुरक्षा विश्लेषण अनुपालन और फोरेंसिक के लिए डेटाबेस गतिविधियों की रिकॉर्डिंग और निगरानी; ऑडिट के लिए मुख्य घटनाएं: सभी डीडीएल विशेषाधिकार अनुदान को बदल देता है/संवेदनशील तालिकाओं (पीआईआई वित्तीय) तक पहुंच में विफल लॉगिन प्रयासों को रद्द कर देता है, विशेषाधिकार प्राप्त उपयोगकर्ता क्रियाएं और असामान्य क्वेरी पैटर्न
D
Performing annual database design reviews वार्षिक डेटाबेस डिज़ाइन समीक्षाएँ करना
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Comprehensive database auditing: (1) Authentication: login successes and failures. (2) Authorization: GRANT/REVOKE. (3) Schema changes: DDL. (4) Data access: SELECT/DML on sensitive tables. (5) DBA actions. (6) Error conditions. Tools: Oracle Audit Vault, SQL Server Audit, PostgreSQL pgaudit extension, MySQL Enterprise Audit.
व्याख्या (हिन्दी) व्यापक डेटाबेस ऑडिटिंग: (1) प्रमाणीकरण: लॉगिन सफलताएँ और विफलताएँ। (2) प्राधिकरण: अनुदान/निरस्त करना। (3) स्कीमा परिवर्तन: डीडीएल। (4) डेटा एक्सेस: संवेदनशील तालिकाओं पर चयन/डीएमएल। (5) डीबीए क्रियाएँ। (6) त्रुटि स्थितियाँ। उपकरण: Oracle ऑडिट वॉल्ट, SQL सर्वर ऑडिट, PostgreSQL pgaudit एक्सटेंशन, MySQL एंटरप्राइज़ ऑडिट।
2295
EN + हिं Easy
GB What is least privilege principle applied to database security?
IN डेटाबेस सुरक्षा पर लागू न्यूनतम विशेषाधिकार सिद्धांत क्या है?
A
Applications should have full DBA privileges for flexibility लचीलेपन के लिए एप्लिकेशन में पूर्ण DBA विशेषाधिकार होने चाहिए
B
Applications need SUPER privileges for performance एप्लिकेशन को प्रदर्शन के लिए सुपर विशेषाधिकारों की आवश्यकता होती है
C
Application accounts should share the DBA account credentials एप्लिकेशन खातों को डीबीए खाता क्रेडेंशियल साझा करना चाहिए
D
Application database accounts should have only the minimum privileges required for their specific function: SELECT only for read-only applications INSERT/UPDATE/DELETE on specific tables for write operations no DDL permissions no GRANT permissions no access to system tables or other schemas एप्लिकेशन डेटाबेस खातों में केवल उनके विशिष्ट कार्य के लिए आवश्यक न्यूनतम विशेषाधिकार होने चाहिए: केवल पढ़ने के लिए अनुप्रयोगों के लिए चयन करें, लिखने के संचालन के लिए विशिष्ट तालिकाओं पर डालें/अपडेट करें/हटाएं, कोई डीडीएल अनुमति नहीं, कोई अनुदान अनुमति नहीं, सिस्टम टेबल या अन्य स्कीमा तक पहुंच नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Least privilege configuration: read-only app - GRANT SELECT ON specific_tables TO app_user. Transaction app - GRANT SELECT, INSERT, UPDATE, DELETE ON specific tables. No DDL, GRANT OPTION, access to sys tables, other schemas. Separate accounts per application. Connection via specific host. Rotate credentials regularly.
व्याख्या (हिन्दी) न्यूनतम विशेषाधिकार कॉन्फ़िगरेशन: केवल-पढ़ने योग्य ऐप - ऐप_उपयोगकर्ता को विशिष्ट_टेबल पर चयन प्रदान करें। लेन-देन ऐप - विशिष्ट तालिकाओं पर अनुदान चयन, सम्मिलित करें, अद्यतन करें, हटाएं। कोई डीडीएल नहीं, अनुदान विकल्प, सिस्टम तालिकाओं तक पहुंच, अन्य स्कीमा। प्रति आवेदन अलग खाते। विशिष्ट होस्ट के माध्यम से कनेक्शन. क्रेडेंशियल नियमित रूप से घुमाएँ.
2281–2295 of 2982