Data Engineering Interview: How Would You Protect Sensitive Parquet Columns?

Problem and scope

A data lake stores email addresses, payment identifiers, regions, and public aggregates in the same Parquet files. Object storage, metadata services, and compute clusters belong to different teams. Authorized jobs should read only required columns; unauthorized readers must not see sensitive values or metadata that reveals identities. Design column-level encryption and key management, then discuss the footer, indexes, predicate pushdown, rotation, legacy readers, and recovery.

Apache Parquet Modular Encryption protects separately serialized modules such as pages, page headers, column indexes, offset indexes, Bloom filters, and the footer while retaining normal column projection, predicate pushdown, encoding, and compression options. A strong answer separates encrypted data, protected metadata, key authorization, and proof that reads and writes are correct.

What the interviewer is testing

• Can you explain the relationship between column keys, a footer key, data encryption keys, and master keys?
• Do you know that encrypting only sensitive columns can still expose schema, statistics, or identity clues?
• Can you compare encrypted and plaintext footers in terms of security, compatibility, and migration cost?
• Do you understand AES-GCM integrity and AAD binding, as well as the limitation of CTR pages?
• Can you connect KMS, authorization, rotation, backup, query failure, and audit into an executable design?

A weak answer says “use AES-256 for the file.” A strong answer proves which Parquet modules are protected, which job can obtain which key, and what legacy readers and predicate pushdown give up.

Clarifying questions to ask first

1. Must the schema, row count, and statistics be hidden, or only column values? This determines whether the footer must be encrypted.
2. Which jobs, tenants, and columns may be read together? This defines column-key domains and KMS policy boundaries.
3. Do the query engine and its PyArrow/Parquet library support Modular Encryption? If not, the read/write path cannot switch directly.
4. Must legacy readers continue to read unencrypted columns? This determines whether a plaintext-footer transition is acceptable.
5. Are files immutable partitions or overwritten, copied, and replayed? This determines AAD identity, rotation, and replay detection.

A 30-second answer

“I would first decide whether the footer and statistics are sensitive, then define access domains by column. Each file or column gets a random DEK wrapped by a KMS-managed MEK or KEK; column pages, headers, indexes, and required column metadata use column keys, while the footer is protected separately. I would prefer AES-GCM because it provides confidentiality and integrity, and bind table, partition, file version, and module identity through AAD to prevent replacement. If legacy readers must read public columns, a plaintext footer can be a time-boxed transition, but it exposes some metadata; sensitive datasets with strict schema confidentiality should use an encrypted footer. I would verify KMS authorization, rotation, predicate pushdown, error recovery, legacy behavior, and tamper cases before rollout.”

Step-by-step reasoning

1. List the Parquet modules that need protection

Parquet is not a black box with only a data area. Pages and page headers carry values; column indexes, offset indexes, and Bloom filters may reveal ranges or distributions; the footer contains schema, row count, sort information, statistics, and key-value metadata. Encrypting only column pages can still expose customer categories or time windows.

file
├── row-group
│   └── column chunk
│       ├── dictionary/data pages
│       ├── page headers
│       ├── column index
│       ├── offset index
│       └── bloom-filter modules
└── footer / FileMetaData

Use the threat model to choose the protection set. Low-sensitivity columns may stay readable for legacy tools; sensitive columns and their statistics, schema, and file identity need stronger footer and column-metadata protection. This decision matters more than selecting an AES key length in isolation.

2. Design envelope encryption and access boundaries

Give each file or column a random data encryption key (DEK), wrapped by a master encryption key (MEK) or key-encryption key (KEK). Keep the MEK in the organization’s KMS. A job receives unwrap permission through a short-lived identity; object storage contains ciphertext and necessary key metadata, not a plaintext master key.

authorized job -> KMS policy -> unwrap DEK -> decrypt footer/columns
object storage  -> ciphertext + key metadata only

Separate column keys by tenant, data domain, or sensitivity so one job does not receive permission for an entire table. Key metadata can be a KMS key ID, wrapped-material identifier, or external reference; it is not the secret itself but affects audit and rotation. During master-key rotation, rewrap DEKs first. Do not rewrite all immutable data pages merely because an MEK changed.

3. Choose between encrypted and plaintext footers

An encrypted footer hides schema, row count, column names, sort information, and more column metadata. It gives a stronger boundary, but every reader of sensitive files must support modular encryption. Parquet uses PARE magic bytes for encrypted-footer files, so a legacy reader expecting PAR1 can reject the format immediately.

A plaintext footer lets older readers see some metadata and read unencrypted columns. They cannot read encrypted column data, while the footer is signed for integrity. This can be a time-boxed migration mode, not a security substitute when statistics are sensitive.

Test a reader matrix: can the engine discover encrypted columns, does unauthorized access fail, can a public-only query still push predicates, and does a legacy reader report an explicit unsupported-encryption error rather than treating the file as corrupt?

4. Select an algorithm and bind AAD

AES-GCM provides encryption and an authentication tag. AAD binds table, partition, file version, and module position to ciphertext, preventing an attacker from replacing the current file, another partition, or another row group under the same key. Random nonces must remain unique for a key, and key invocation budgets must be managed across writers.

Parquet also defines AESGCMCTRV1: non-page modules use GCM while data pages use CTR for throughput. CTR pages do not have GCM’s authenticated integrity. If the threat model requires page-tamper detection, prefer AESGCM_V1 instead of choosing only by CPU speed.

5. Preserve query capability and define failure paths

Encryption is applied to compressed pages and other modules, so the format can still express projection, predicate pushdown, encoding, and compression. A planner may read a visible footer or index and request only authorized columns. If the footer or column index is encrypted, however, the planner needs the corresponding decrypt permission; “I only query public columns” does not automatically mean “no key is needed.”

Record decrypt failure, KMS timeout, revoked permission, AAD mismatch, and authentication-tag failure separately. Never fall back silently to plaintext and do not label every failure as a corrupt file. Keep file ID, key metadata, algorithm version, and audit principal, but never log DEKs, plaintext values, or complete key material.

6. Verify rotation, tampering, and disaster recovery

Test unauthorized reads of sensitive columns, authorized public-column reads, authorized sensitive reads, old-file replacement, row-group exchange, ciphertext-page edits, KMS denial, post-rotation reads, and cross-region recovery. For each test, record the expected error, whether plaintext was returned, and the audit event.

Recovery needs encrypted files, key metadata, KMS key-version mappings, and AAD file identity. Restoring storage without KMS permission produces unreadable files; restoring KMS without the AAD prefix may prevent file-identity verification. Keep old key versions through the snapshot, replay, and backup validation window before destruction.

High-quality sample answer

“I would start by defining the threat model: must schema, row count, and statistics be hidden, and which jobs can read which columns? Parquet Modular Encryption can protect not only column pages but also page headers, column indexes, offset indexes, Bloom filters, and the footer. I would generate random DEKs for files or columns and wrap them with MEK/KEK in a KMS. Jobs get unwrap permission through short-lived identities, and files contain only auditable key metadata.

For a complete boundary I would use an encrypted footer. If legacy readers must access public columns, I would use a time-boxed plaintext-footer migration and document the metadata it exposes. I would prefer AES-GCM with AAD binding table, partition, file version, and module identity, and would not trade away page integrity merely because CTR pages are faster. Before rollout I would test projection and predicate pushdown, KMS denial, AAD tampering, key rotation, cross-region recovery, and legacy behavior. Logs would exclude DEKs, plaintext, and key material. The design makes encryption, authorization, query behavior, and recovery independently testable.”

Common mistakes

• Using only storage-layer encryption → anyone with object access can read every column → design boundaries at columns, footer, and modules.
• Encrypting sensitive pages but not the footer → schema, statistics, and row count can leak → choose an encrypted footer or state the plaintext-footer exposure explicitly.
• Treating a DEK as a long-lived master key → one file leak expands rotation and revocation impact → wrap random DEKs with a KMS MEK or KEK.
• Ignoring AAD → old files or other partitions under the same key can be substituted → bind file and module identity and test swaps.
• Calling AESGCMCTR_V1 fully authenticated → CTR pages may lack GCM page authentication → choose by integrity requirements and test tampering.
• Deleting old keys immediately after rotation → snapshots, backups, and replay jobs cannot recover → retain version mappings and a controlled old-key window.

Follow-up questions and responses

Legacy readers must keep reading public columns. How do you migrate?

Use a plaintext footer temporarily while encrypting sensitive column data pages, and let legacy readers access only public columns. Measure the schema and statistics exposed, set an upgrade deadline, then move to an encrypted footer after new-reader coverage and replay tests pass. Keep a rollback file version.

How do you stop a page from another partition being copied into this file?

Construct stable AAD identity from the file, table, partition, row group, and module. A mismatch must fail authentication. Test old-version, cross-partition, and cross-column swaps under the same key and verify that all are rejected.

Does every page read require a KMS round trip?

No. Unwrap a DEK or KEK through KMS, then cache short-lived material inside a controlled process. Bound cache scope and TTL, invalidate it on rotation or revocation, and monitor KMS failures and cache hits. Do not put a KMS call on the page hot path.

Why not use only AES-CTR for higher throughput?

CTR does not authenticate integrity, so a modified page may go undetected. Use AES-GCM when the threat model requires tamper detection. Consider CTR only when the integrity trade-off is explicit and an outer integrity mechanism is verified.

How do you prove predicate pushdown does not bypass authorization?

Run public-only, sensitive-filter, and sensitive-projection queries under authorized and unauthorized identities. Inspect requested modules and KMS permissions. Audit records should connect query, file, column, key metadata, and denial reason; a final row count is insufficient.