Question 1

SQL performance guideline: As a general rule, should queries that perform full table scans be avoided when selective access paths (e.g., indexes) are available?

Accepted Answer

Introduction / Context:Query performance often hinges on how data is accessed. Full table scans read every row, which can be costly. This question checks whether avoiding them is a sensible default practice.Given Data / Assumptions:Large tables can contain millions of rows.Indexes provide selective access paths when predicates are selective.Optimizers choose plans based on statistics.Concept / Approach:As a general guideline, avoid unnecessary full scans by providing appropriate indexes and predicates. However, full scans can be optimal for small tables, unselective predicates, or when most rows are needed. The statement emphasizes the “avoid when possible” principle, not an absolute rule.Step-by-Step Solution:Profile workload and identify long-running queries.Check execution plans; note full table scans on large tables.Add or tune indexes that match selective predicates or join keys.Update statistics and verify plan improvements.Verification / Alternative check:Benchmark the same query with and without a supporting index on representative data volumes; the indexed plan typically reduces I/O and elapsed time.Why Other Options Are Wrong:Restricting the guidance to tiny tables or cloud databases misunderstands fundamentals. Marking “Incorrect” ignores the common performance trade-off.Common Pitfalls:Creating too many indexes (hurting writes); stale statistics; predicates that prevent index usage (functions on columns, mismatched data types).Final Answer:Correct

Question 2

High availability design: Are mirrored or replicated databases commonly included in high-availability (HA) systems to reduce downtime risk?

Accepted Answer

Introduction / Context:High availability aims to minimize service interruption. Database mirroring and replication provide redundancy so that if a primary fails, a secondary can take over quickly with minimal data loss.Given Data / Assumptions:HA targets include recovery time objective (RTO) and recovery point objective (RPO).Techniques include synchronous replication, asynchronous replication, log shipping, clustering, and managed cloud replicas.Failover may be automatic or manual.Concept / Approach:Mirroring/replication maintains one or more up-to-date copies of data. In synchronous modes, commits are confirmed only after the mirror acknowledges, achieving near-zero RPO. In asynchronous modes, performance improves at the cost of small potential data lag. Both patterns are widely used in HA architectures across on-premises and cloud environments.Step-by-Step Solution:Define RTO/RPO targets with stakeholders.Choose replication technology (native DB features, cluster, or cloud-managed).Configure monitoring, health checks, and failover procedures.Regularly test failover and validate data integrity on secondaries.Verification / Alternative check:Perform a controlled failover drill. If applications recover within target RTO and data loss is within RPO, the HA design is effective.Why Other Options Are Wrong:Limiting replicas to reporting ignores HA use cases. HA applies equally in cloud and on-prem. Marking “Incorrect” would deny a standard industry practice.Common Pitfalls:Unvalidated failover runbooks; untested backups; split-brain risk without quorum; assuming synchronous replication needs no latency planning.Final Answer:Correct

Question 3

Database security fundamentals: Authorization tables (user accounts, roles, privileges) contain highly sensitive data and must be protected with stringent security controls. Do you agree?

Accepted Answer

Introduction / Context:Authorization tables store who can do what in a database: users, roles, privileges, password hashes, API keys, and often auditing references. Because these entries govern access to every other object, they are a prime target for attackers and require rigorous protection measures that exceed ordinary data safeguards.Given Data / Assumptions:The authorization subsystem includes users, roles, grants, revokes, and sometimes row-level policies.Compromise of this data can elevate privileges and bypass application controls.Security controls span authentication, authorization, encryption, auditing, and change management.Concept / Approach:The principle of least privilege and defense-in-depth both imply that metadata which controls access to all data must be placed under the strongest controls. This typically includes restricted ownership, tight GRANT policies, encryption at rest and in transit, separation of duties, and immutable audit trails. Backups of these tables deserve equal protection because restoring a compromised backup can reintroduce risk.Step-by-Step Solution:Classify authorization tables as highly confidential assets.Restrict direct access to security administrators only; deny ad-hoc reads by application roles.Enable encryption at rest for system catalogs (when supported) and for any auxiliary security tables.Harden backups: encrypt keys, store off-site securely, and limit restore permissions.Continuously audit DDL and DCL affecting users, roles, and privileges; alert on anomalies.Verification / Alternative check:Perform a tabletop exercise: if an attacker gained read/write access to authorization tables, could they create a superuser or grant broad privileges? The answer is almost always yes, which validates the need for stringent controls.Why Other Options Are Wrong:Incorrect: downplays the criticality of authorization metadata.Depends only on OS: database-native controls are equally important.Not applicable for read-only DBs: even read-only modes still rely on authorization metadata.Common Pitfalls:Leaving default accounts enabled, over-granting SELECT on system catalogs, failing to encrypt backups, and neglecting privilege-change auditing.Final Answer:Correct

Question 4

Database recovery basics: Does the restore/rerun technique reprocess the day’s transactions up to the point of failure after restoring the last good backup?

Accepted Answer

Introduction / Context:Recovery strategies determine how quickly and accurately a database returns to a consistent state after a crash or corruption. The restore/rerun technique is a classic approach for systems that process batches of transactions, especially where the unit of work is a day’s workload.Given Data / Assumptions:You have a reliable, recent full backup taken before the failure.The system archived or captured the day’s transactions in an ordered form (logs, journal, or batch input files).Transactions are deterministic and can be re-applied safely in the same sequence.Concept / Approach:Restore/rerun proceeds in two phases: first, restore the last known good backup to return the database to a consistent baseline; second, rerun (replay) the day’s transactions from the beginning of the period up to the failure. This recovers committed work while avoiding lost updates. It is conceptually similar to roll-forward recovery using archive logs but is often described in batch contexts.Step-by-Step Solution:Restore full backup to a clean environment.Validate integrity and baseline consistency.Apply transactions in recorded order up to the failure time.Reconcile any partially processed batches based on checkpoints.Reopen the system and resume normal processing.Verification / Alternative check:Compare ending balances or control totals before failure to the post-recovery state. If they match expected audit totals through the last good commit, restore/rerun succeeded.Why Other Options Are Wrong:Incorrect: misstates the standard recovery flow.Only for distributed DBs: the approach is topology-agnostic.Used only when no logs exist: logs or batch journals are typically required for rerun.Common Pitfalls:Missing or corrupt input journals, non-idempotent transaction logic, unreconciled time-of-failure edge cases, and inadequate audit trails.Final Answer:Correct

Question 5

Data warehouse readiness: For successful data warehousing and business intelligence, is it important to build and maintain a comprehensive metadata repository?

Accepted Answer

Introduction / Context:Data warehouses integrate data from many sources. Business Intelligence (BI) depends on consistent definitions, lineage, data quality rules, and repeatable transformations. A comprehensive metadata repository captures these details and becomes the backbone for governance and reliable analytics delivery.Given Data / Assumptions:Multiple, heterogeneous sources feed the warehouse.There are evolving business definitions (dimensions, measures, KPIs).Teams require data lineage, impact analysis, and stewardship workflows.Concept / Approach:A metadata repository stores technical metadata (schemas, ETL jobs, column types), business metadata (glossary, KPI definitions), and operational metadata (job runs, data quality scores). Maintaining it improves trust, accelerates onboarding, supports self-service BI, and reduces regression risk during schema changes. Without it, reports drift, definitions conflict, and auditability suffers.Step-by-Step Solution:Catalog sources, datasets, tables, columns, and transformations.Document business definitions and owners for core metrics.Track lineage from source fields to report visuals.Record data quality rules, thresholds, and test results.Expose searchable metadata to analysts and engineers.Verification / Alternative check:Perform impact analysis for a source column rename. If you can programmatically list affected ETL jobs, tables, and reports, your repository is functioning; otherwise, you will face blind deployments and broken dashboards.Why Other Options Are Wrong:Incorrect: underestimates governance needs.Only for real-time or regulatory cases: routine BI also needs robust metadata.Common Pitfalls:Letting metadata fall out-of-date, poor ownership, and failing to integrate lineage with CI/CD so changes trigger review.Final Answer:Correct

Question 6

Roles in data management: Are data modeling and database design key responsibilities of data administration and database administration?

Accepted Answer

Introduction / Context:Modern organizations separate concerns between data administration (DA) and database administration (DBA). While titles vary, both roles contribute significantly to data modeling and database design, which shape how data is structured, governed, and optimized for use.Given Data / Assumptions:Data administration focuses on enterprise data policies, modeling standards, and stewardship.Database administration focuses on physical design, performance, availability, and security.Effective schemas reflect both business semantics and platform constraints.Concept / Approach:Conceptual and logical data modeling typically arise from DA working with business stakeholders to define entities, relationships, and rules. Physical database design is commonly the DBA’s responsibility, translating models into indexes, partitions, access paths, and storage parameters. The two areas overlap: DBAs advise on feasibility; DAs adjust models to practical constraints.Step-by-Step Solution:Elicit business requirements and craft a conceptual model (DA-led).Refine to logical models with keys, constraints, and normalization.Implement physical structures: tablespaces, indexes, partitioning (DBA-led).Validate performance using representative workloads.Govern changes through versioned models and review boards.Verification / Alternative check:Trace a change—say, adding a new dimension attribute—from business request to deployed table and index. Both DA and DBA are involved, confirming shared responsibility.Why Other Options Are Wrong:Incorrect: contradicts common practice in data management.Only vendors or only app developers: external or application viewpoints alone rarely yield robust enterprise designs.Common Pitfalls:Poor handoff between logical and physical design, neglecting indexing strategy, and failing to align schemas with governance and quality standards.Final Answer:Correct

Question 7

Confidentiality risk: Can failure to control data confidentiality lead to loss of competitiveness for an organization?

Accepted Answer

Introduction / Context:Confidentiality is one pillar of the CIA triad (confidentiality, integrity, availability). It protects sensitive information from unauthorized disclosure. Breaches can erode competitive advantage, invite legal liability, and damage brand trust—all of which directly affect market position.Given Data / Assumptions:Organizations hold trade secrets, pricing models, product roadmaps, customer lists, and proprietary algorithms.Competitors can leverage leaked information to undercut pricing, preempt launches, or target key accounts.Customers and partners expect privacy and contractual compliance.Concept / Approach:Effective confidentiality controls include access management, encryption, data loss prevention, and auditing. When these fail, sensitive data may leak, enabling rivals to copy strategies or customers to churn due to trust loss. The downstream effects—lost deals, regulatory fines, higher cyber insurance premiums—reduce competitiveness and increase operating costs.Step-by-Step Solution:Classify data by sensitivity and apply proportional controls.Grant least-privilege access; review entitlements regularly.Encrypt sensitive data at rest and in transit; manage keys securely.Monitor egress via DLP and alert on anomalies.Practice incident response with tabletop exercises and post-mortems.Verification / Alternative check:Model a scenario where pricing leaks to a competitor. Simulate tender outcomes before and after the leak to quantify margin compression and win-rate decline—demonstrating real competitive harm.Why Other Options Are Wrong:Incorrect: ignores well-documented business impacts.Only in regulated or retail verticals: every industry holds sensitive information.Common Pitfalls:Relying solely on perimeter defenses, neglecting insider risk, and failing to secure backups and analytics extracts stored outside core databases.Final Answer:Correct

Question 8

Transaction logging: Does a database transaction log record before-images and after-images for rows modified by transactions (supporting undo and redo)?

Accepted Answer

Introduction / Context:Transaction logs (also called write-ahead logs or journals) are central to ACID properties. They capture enough information about each change to support recovery, rollbacks, and replication. Conceptually, they store the “before” state (to undo) and the “after” state (to redo) of modifications.Given Data / Assumptions:The DBMS writes log records before applying data pages (write-ahead logging).Each logical change has sufficient detail to invert (undo) or replay (redo) it.Implementation specifics differ, but the effect is equivalent to before/after images.Concept / Approach:On crash recovery, the DBMS scans the log, redoes committed work not yet on disk and undoes uncommitted updates to ensure consistency. Point-in-time recovery and replication also leverage these records. Whether the system stores physical before/after bytes or logical operations, the semantics allow reconstructing prior and new states.Step-by-Step Solution:Begin a transaction; DBMS logs intended changes (WAL).Apply changes to in-memory pages; flush log to stable storage on commit.On crash, redo committed but unflushed changes using after-images.Undo in-flight transactions to remove partial effects using before-images.Bring database to a consistent, committed state.Verification / Alternative check:Demonstrate a forced crash after commit but before data page flush; recovery uses redo to make data durable, proving the role of after-images in practice.Why Other Options Are Wrong:Incorrect: contradicts core logging semantics.Only for inserts or in-memory DBs: all durable ACID systems implement equivalent logging.Common Pitfalls:Misconfiguring log retention, placing logs and data on the same failing media, or skipping validated backups that align with log chain continuity.Final Answer:Correct

Question 9

Disaster recovery scope: Should a disaster recovery plan include secure shipment or replication of database backups to off-site or secondary locations?

Accepted Answer

Introduction / Context:Disaster recovery (DR) addresses region-level risks: fires, floods, ransomware, data center failures. If your backups are stored only on-site, the same disaster that destroys production can destroy your ability to recover. Therefore, off-site backup shipment or replication is a foundational DR requirement.Given Data / Assumptions:Backups must be durable, intact, and recoverable independent of the primary site.Threats include physical disasters and logical corruption (malicious deletion or encryption).Recovery Time Objective (RTO) and Recovery Point Objective (RPO) drive technology choices.Concept / Approach:A sound DR plan uses one or more of: off-site vaulting of encrypted media, cross-region object storage, log shipping, snapshot replication, or fully managed cross-region database replicas. Periodic test restores validate that backups are usable. Chain-of-custody and key management ensure confidentiality and integrity while in transit and at rest.Step-by-Step Solution:Define RTO/RPO and choose off-site replication or shipment accordingly.Encrypt backups; separate encryption keys from backup storage.Automate transfer to secondary locations; monitor success and latency.Perform scheduled DR drills with full restore procedures.Continuously improve based on drill outcomes and incident learnings.Verification / Alternative check:Run a failover simulation assuming the primary site is unavailable. If you can restore from the off-site copy to meet RTO/RPO, the plan is adequate; if not, the gap reveals missing off-site provisioning.Why Other Options Are Wrong:Correct (as an answer to the original false claim) would wrongly suggest off-site is unnecessary.Only for cloud or archives: on-premises and hot transactional systems equally require off-site protection.Common Pitfalls:Keeping backups in the same blast radius, untested restores, weak key management, and forgetting to protect the backup catalog itself.Final Answer:Incorrect

Question 10

Threat modeling: Is the greatest security risk to a business often internal (insider threats) rather than purely external?

Accepted Answer

Introduction / Context:Security programs must balance defenses against external attackers and internal actors. Insider threats—whether malicious or accidental—can be particularly damaging because insiders already possess credentials, context, and legitimate access paths that bypass many perimeter controls.Given Data / Assumptions:Employees, contractors, and administrators have varying levels of legitimate access.Accidental insiders can expose data via misconfiguration or phishing.Monitoring, segregation of duties, and culture are crucial mitigations.Concept / Approach:Because insiders operate within trust boundaries, their actions are harder to detect with traditional perimeter tools. Privilege misuse, data exfiltration, and configuration errors frequently originate internally. Therefore, zero-trust principles, least privilege, and continuous behavioral analytics are essential. External threats remain critical, but numerous breach reports show internal vectors—intentional or accidental—are often the proximate cause.Step-by-Step Solution:Inventory privileged accounts and reduce standing privileges.Implement just-in-time access and multi-factor authentication.Log and monitor administrative actions with independent review.Deploy DLP and anomaly detection to spot unusual data movements.Train staff to avoid phishing and report suspicious activity.Verification / Alternative check:Run red-team exercises simulating insider misuse; compare detection and response times versus external phishing scenarios to assess relative risk and control efficacy.Why Other Options Are Wrong:Incorrect: ignores well-documented insider risk.Only for small firms or no firewalls: insider risk affects all sizes and architectures.Common Pitfalls:Over-reliance on perimeter defense, inadequate logging of admin actions, and failing to separate duties between development, operations, and security teams.Final Answer:Correct

Data and Database Administration Questions

Questions

Practice smarter