Security practice questions

A data analyst frequently receives ad hoc requests for the same type of analysis. Which TWO approaches could reduce the number of ad hoc requests?

Trap 1: Increase data freshness to real-time

Real-time freshness changes how current the data is, not how often the same analysis is requested; the recurring demand persists. It is tempting because latency is a common complaint, and streaming ingestion would be correct where decisions depend on sub-minute data, but here the requirement is eliminating repeat requests through reusable reporting.

Trap 2: Add more security to the data

Restricting data access does not reduce demand; analysts still receive the same requests, merely with narrower visibility. It tempts as a governance control, which is its actual purpose. Reducing ad hoc volume comes from publishing reusable dashboards or self-service reports that requesters can consult directly.

Trap 3: Ignore the requests until they become urgent

Ignoring requests does not reduce their volume; it simply delays delivery and damages stakeholder trust, leaving the underlying recurring need unaddressed. It is tempting as a triage tactic when capacity is exhausted, but the correct approach is to build a reusable self-service report or dashboard that answers the repeated question directly.

A
Increase data freshness to real-time
Why it fails: Real-time freshness changes how current the data is, not how often the same analysis is requested; the recurring demand persists. It is tempting because latency is a common complaint, and streaming ingestion would be correct where decisions depend on sub-minute data, but here the requirement is eliminating repeat requests through reusable reporting.
B
Create a scheduled report that covers the common analysis
A scheduled report delivers the recurring analysis automatically at set intervals, so requesters self-serve instead of raising tickets. This satisfies the goal of reducing repeated ad hoc requests by converting a predictable, recurring need into a standing deliverable.
C
Add more security to the data
Why it fails: Restricting data access does not reduce demand; analysts still receive the same requests, merely with narrower visibility. It tempts as a governance control, which is its actual purpose. Reducing ad hoc volume comes from publishing reusable dashboards or self-service reports that requesters can consult directly.
D
Ignore the requests until they become urgent
Why it fails: Ignoring requests does not reduce their volume; it simply delays delivery and damages stakeholder trust, leaving the underlying recurring need unaddressed. It is tempting as a triage tactic when capacity is exhausted, but the correct approach is to build a reusable self-service report or dashboard that answers the repeated question directly.
E
Encourage users to create their own reports using a self-service BI tool
Self-service BI lets business users build and refresh their own dashboards against governed datasets, removing their dependence on the analytics team for repeatable questions. This directly cuts the recurring ad hoc requests described in the stem, since users answer the same analysis themselves.

Question 2mediummulti select

A data analyst is evaluating data quality issues during acquisition. Which TWO issues are most likely to arise from merging data from different sources? (Select exactly 2)

Trap 1: User access permissions

Access permissions are a security and governance control, not a data quality defect produced by combining sources. It tempts because merged repositories widen exposure, but acquisition quality issues are content-level — mismatched formats, duplicate keys, conflicting definitions — rather than authorisation configuration.

Trap 2: Slow network speed

Network speed is a performance and infrastructure characteristic, not a data quality issue created by merging sources. It tempts because large transfers between systems can be slow, but acquisition quality problems concern the data's content — inconsistent schemas, duplicates, conflicting values — not transfer throughput.

Trap 3: High storage cost

Storage cost is an infrastructure and budget concern, not a data quality defect arising from combining sources. It tempts because merged datasets grow larger, but acquisition quality issues are semantic and structural — conflicting formats, duplicate records, inconsistent definitions — not capacity economics.

A
User access permissions
Why it fails: Access permissions are a security and governance control, not a data quality defect produced by combining sources. It tempts because merged repositories widen exposure, but acquisition quality issues are content-level — mismatched formats, duplicate keys, conflicting definitions — rather than authorisation configuration.
B
Duplicate records
Merging sources that share overlapping entities, such as the same customer appearing in two systems, produces duplicate records unless deduplication keys are defined. This directly satisfies the stem's constraint of combining data from different sources, where repeated identifiers create redundancy.
C
Slow network speed
Why it fails: Network speed is a performance and infrastructure characteristic, not a data quality issue created by merging sources. It tempts because large transfers between systems can be slow, but acquisition quality problems concern the data's content — inconsistent schemas, duplicates, conflicting values — not transfer throughput.
D
High storage cost
Why it fails: Storage cost is an infrastructure and budget concern, not a data quality defect arising from combining sources. It tempts because merged datasets grow larger, but acquisition quality issues are semantic and structural — conflicting formats, duplicate records, inconsistent definitions — not capacity economics.
E
Formatting inconsistencies
Different source systems store dates, numbers and codes in their own conventions, so merging them yields formatting inconsistencies that break joins and comparisons. This satisfies the stem's multi-source merge scenario, where no shared schema standardises field representation across the contributing systems.

Question 3hardmulti select

Which THREE are challenges in acquiring data from external sources? (Select three.)

Trap 1: Data redundancy

Redundancy arises from internal storage and integration design, not from the external acquisition process itself. It is tempting because duplicated records genuinely complicate later cleansing and warehouse loading, so it feels data-related; however, the stem asks about external-source acquisition challenges, where format inconsistency, access restrictions and licensing terms apply.

Trap 2: Unauthorized access

Unauthorised access concerns protecting data you already hold, not the difficulty of obtaining it from external providers. It is tempting because external sharing raises genuine security worries, and access control is a real data-governance topic; yet the acquisition challenges are availability, format, cost and contractual restrictions imposed by the source.

A
Data redundancy
Why it fails: Redundancy arises from internal storage and integration design, not from the external acquisition process itself. It is tempting because duplicated records genuinely complicate later cleansing and warehouse loading, so it feels data-related; however, the stem asks about external-source acquisition challenges, where format inconsistency, access restrictions and licensing terms apply.
B
Unauthorized access
Why it fails: Unauthorised access concerns protecting data you already hold, not the difficulty of obtaining it from external providers. It is tempting because external sharing raises genuine security worries, and access control is a real data-governance topic; yet the acquisition challenges are availability, format, cost and contractual restrictions imposed by the source.
C
Licensing restrictions
External datasets arrive under vendor or public licences governing permitted use, redistribution and derivative works. These contractual terms constrain whether the data can legally be ingested and stored, making licensing restrictions a genuine acquisition challenge rather than a technical processing concern.
D
Rate limiting
External APIs and providers cap request volume per interval, so acquisition pipelines must throttle, batch or back off to avoid rejected calls. This throughput ceiling directly limits how quickly data can be collected, making rate limiting a structural constraint of sourcing data outside the organisation.
E
Data format inconsistency
Third parties supply data in differing schemas, encodings and delimiters, so records cannot be loaded uniformly without transformation. Reconciling these structural differences adds parsing and mapping effort during ingestion, making format inconsistency a core acquisition challenge for external sources.

Question 4mediummulti select

A data analyst is designing a self-service reporting platform for business users. Which TWO practices will help ensure data consistency and trust? (Select TWO.)

Trap 1: Allow users to create their own data sources

User-authored data sources bypass governed, certified connections, producing divergent extracts and conflicting figures across reports. It is tempting because it accelerates self-service, but it is correct only in exploratory sandboxes where consistency across shared reporting is not required.

Trap 2: Grant row-level security to all users

Row-level security filters which rows each user sees; it does not standardise definitions or values across reports, so business users still see conflicting figures. It is tempting because RLS genuinely enforces per-user data access, and would be correct when the requirement is restricting users to their own region's or department's records.

Trap 3: Remove all data lineage tracking

Discarding lineage removes the ability to trace metrics to source systems, so errors cannot be diagnosed and trust erodes. It is tempting when simplifying the platform, but lineage is correctly retained where auditability and impact analysis across transformations are required.

A
Implement a single version of truth
A single version of truth consolidates metrics and definitions into one governed dataset, eliminating conflicting figures across reports. This directly satisfies the consistency and trust requirement, since business users draw from identical, curated data rather than divergent extracts.
B
Allow users to create their own data sources
Why it fails: User-authored data sources bypass governed, certified connections, producing divergent extracts and conflicting figures across reports. It is tempting because it accelerates self-service, but it is correct only in exploratory sandboxes where consistency across shared reporting is not required.
C
Grant row-level security to all users
Why it fails: Row-level security filters which rows each user sees; it does not standardise definitions or values across reports, so business users still see conflicting figures. It is tempting because RLS genuinely enforces per-user data access, and would be correct when the requirement is restricting users to their own region's or department's records.
D
Remove all data lineage tracking
Why it fails: Discarding lineage removes the ability to trace metrics to source systems, so errors cannot be diagnosed and trust erodes. It is tempting when simplifying the platform, but lineage is correctly retained where auditability and impact analysis across transformations are required.
E
Provide a data dictionary for all metrics
A data dictionary documents each metric's definition, calculation, source and owner, so every business user interprets figures identically. This directly satisfies the consistency and trust requirement by removing ambiguous or conflicting metric definitions across the self-service platform.

Question 5mediummultiple choice

A data analyst is creating a report on customer satisfaction scores. The analyst wants to ensure that regional managers can only see data for their own region. Which security measure should be applied?

Trap 1: Data encryption

Encryption protects data at rest and in transit but does not filter rows by region, so every manager would still see all regions once decrypted. It is the correct control when the requirement is confidentiality against interception or unauthorised storage access, not per-user row visibility.

Trap 2: Single version of truth

A single version of truth is a data-governance principle ensuring consistent definitions and values, not an access control; it cannot restrict which rows a manager retrieves. It is the right aim when reconciling conflicting reports, but it grants no row-level filtering by region.

Trap 3: Data masking

Masking obscures or replaces sensitive values such as names or card numbers, yet the underlying rows for every region remain present and visible. It suits protecting PII within a dataset, whereas restricting managers to their own region requires row-level filtering by their identity.

A
Data encryption
Why it fails: Encryption protects data at rest and in transit but does not filter rows by region, so every manager would still see all regions once decrypted. It is the correct control when the requirement is confidentiality against interception or unauthorised storage access, not per-user row visibility.
B
Row-level security
Row-level security filters table rows by the user's identity, so each regional manager's query returns only their own region's satisfaction scores. This directly satisfies the stem's constraint that managers see solely their region's data, enforced at query time within the semantic model rather than through separate reports or workspace permissions.
C
Single version of truth
Why it fails: A single version of truth is a data-governance principle ensuring consistent definitions and values, not an access control; it cannot restrict which rows a manager retrieves. It is the right aim when reconciling conflicting reports, but it grants no row-level filtering by region.
D
Data masking
Why it fails: Masking obscures or replaces sensitive values such as names or card numbers, yet the underlying rows for every region remain present and visible. It suits protecting PII within a dataset, whereas restricting managers to their own region requires row-level filtering by their identity.

Question 6mediummultiple choice

A mid-sized insurance company stores policyholder records in a Microsoft SQL Server database. The compliance team must ensure that any column containing Social Security numbers is masked whenever the data is queried by analysts who are not authorized to view full identifiers. The database administrators want a solution that enforces masking at query time without altering the stored values or requiring application changes. Which SQL Server feature should they implement?

Trap 1: Row-Level Security

Row-Level Security restricts which rows a user can access based on a predicate, but it does not mask column values. Analysts who are permitted to see a row would still see the full Social Security number, so this feature does not satisfy the need to obscure sensitive column data for unauthorized users.

Trap 2: Always Encrypted

Always Encrypted protects data in use and at rest by encrypting columns on the client side, but it requires application changes such as specifying encryption metadata and column encryption keys. The scenario explicitly states that no application changes should be required, so this approach is not suitable despite its strong security properties.

Trap 3: Transparent Data Encryption

Transparent Data Encryption encrypts data at rest and protects the database files, but once a user is authenticated and authorized, queries return the actual plaintext values. It does not prevent an authorized analyst from seeing full Social Security numbers, so it fails to meet the requirement of query-time masking for unauthorized users.

A
Row-Level Security
Why it fails: Row-Level Security restricts which rows a user can access based on a predicate, but it does not mask column values. Analysts who are permitted to see a row would still see the full Social Security number, so this feature does not satisfy the need to obscure sensitive column data for unauthorized users.
B
Dynamic Data Masking
Dynamic Data Masking applies masking rules at query time based on the user's permissions, so unauthorized analysts see masked values while authorized users see the original data. It does not change stored data or require application changes, which directly satisfies the scenario's requirement to protect Social Security numbers without altering the underlying records.
C
Always Encrypted
Why it fails: Always Encrypted protects data in use and at rest by encrypting columns on the client side, but it requires application changes such as specifying encryption metadata and column encryption keys. The scenario explicitly states that no application changes should be required, so this approach is not suitable despite its strong security properties.
D
Transparent Data Encryption
Why it fails: Transparent Data Encryption encrypts data at rest and protects the database files, but once a user is authenticated and authorized, queries return the actual plaintext values. It does not prevent an authorized analyst from seeing full Social Security numbers, so it fails to meet the requirement of query-time masking for unauthorized users.

Question 7mediummatching

Match each data security concept to its description.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

Convert data into code to prevent unauthorized access

Replace sensitive data with non-sensitive placeholder

Hide parts of data (e.g., show only last 4 digits)

Restrict data access based on user permissions

Log of all data access and modifications

Trap 1: Encryption: Process of verifying identity.

Incorrect — this describes Authentication, not Encryption.

Trap 2: Authentication: Process of converting data into code.

Incorrect — this describes Encryption, not Authentication.

A
Encryption: Process of converting data into a coded form to prevent unauthorized access.
Encryption is correctly defined as the process of encoding data to protect it from unauthorized access.
B
Authentication: Process of verifying the identity of a user or system.
Authentication is correctly defined as the process of verifying identity.
C
Authorization: Process of granting or denying access to resources based on roles.
Authorization is correctly defined as the process of granting or denying access based on permissions.
D
Non-repudiation: Assurance that a party cannot deny the authenticity of their actions.
Non-repudiation is correctly defined as the assurance that a party cannot deny their actions.
E
Encryption: Process of verifying identity.
Why it fails: Incorrect — this describes Authentication, not Encryption.
F
Authentication: Process of converting data into code.
Why it fails: Incorrect — this describes Encryption, not Authentication.

Question 8mediummulti select

A data analyst is documenting a report for external stakeholders. Which THREE elements should be included to ensure report quality and transparency?

Trap 1: Employee names who created the report

Naming report authors is metadata about provenance, not a quality or transparency element for external readers; it exposes internal staff to third parties. Author attribution belongs in internal audit trails or change logs, where accountability for who built or approved a dataset is the requirement.

Trap 2: Row-level security settings

Row-level security governs which internal users can query which rows; it is an access-control configuration, not documentation content. It would be the right answer when auditing who can see sensitive records, but external stakeholders need stated data sources, assumptions and definitions instead.

A
Data freshness (e.g., last updated timestamp)
A last-updated timestamp directly evidences data freshness, satisfying the transparency requirement for external stakeholders who cannot verify currency themselves. Unlike internal audiences, external readers lack system access, so an explicit recency marker lets them judge whether figures remain valid for their decision. This makes the report auditable and trustworthy.
B
Employee names who created the report
Why it fails: Naming report authors is metadata about provenance, not a quality or transparency element for external readers; it exposes internal staff to third parties. Author attribution belongs in internal audit trails or change logs, where accountability for who built or approved a dataset is the requirement.
C
Row-level security settings
Why it fails: Row-level security governs which internal users can query which rows; it is an access-control configuration, not documentation content. It would be the right answer when auditing who can see sensitive records, but external stakeholders need stated data sources, assumptions and definitions instead.
D
Limitations and assumptions
Documenting limitations and assumptions discloses where the analysis may not hold, which data was excluded, and what conditions affect the results. This satisfies the transparency requirement for external stakeholders, who need to judge how far the report's conclusions can reasonably be relied upon.
E
Methodology notes
Methodology notes record how data was sourced, transformed, filtered and calculated, so external stakeholders can trace figures back to their origin. This satisfies the transparency requirement by making the report's derivation reproducible and auditable rather than presenting unexplained numbers.