Prompt and scope
A core dump is a snapshot of a process address space. It may contain keys, request bodies, user data, and uncleared buffers. This question tests Linux diagnosis and production data governance: separate whether a dump can be collected from who can view it, how long it remains, and how cleanup is proven.
What the interviewer is evaluating
- Evidence from exit signals, journal, kernel messages, version, and core metadata.
- Understanding of systemd-coredump collection, compression, storage, and
coredumpctlboundaries. - Symbolization with the exact binary, libraries, debug symbols, and build ID.
- Complete controls for content, permissions, encryption, retention, capacity, and privacy.
- Proof after the fix through reproduction, crash metrics, deletion checks, and access review.
Recommended answer structure
Start with low-risk evidence: service status, signal, journal, kernel messages, version, and resource metrics. If a core is justified, enable controlled capture briefly on an isolated instance, limit size and count, and use dedicated encrypted storage. Analyze and destroy it promptly or let a documented retention job expire it.
Deep dive: from crash to remediation
Identify the exit cause first
Check systemctl status, journal, kernel OOM records, exit signal, and restart count. SIGSEGV, SIGABRT, and SIGBUS provide different clues; exit 137 should first trigger a cgroup OOM check. A core file alone is not proof of a segmentation fault.
Fix the symbolization inputs
Keep the exact binary, shared libraries, debug symbols, and build ID for the crashed instance. Retrieve them from a trusted artifact store. Read threads, signal, and stacks first; inspect heap and registers only when needed to reduce exposure.
Build controlled collection
systemd-coredump can hand the dump to a dedicated service and store it in the journal or an external directory. Set per-file and total quotas, compression, concurrency, and alerts. For a highly sensitive service, set LimitCORE=0 or collect only metadata and a controlled stack, with a recorded rollback.
Establish access and retention boundaries
Encrypt core storage, grant least privilege, and audit every access. Do not allow ordinary operations accounts to download dumps. Set retention from the diagnostic window and policy, with automatic expiry and capacity alarms. Commands, paths, and tickets must not contain tokens.
Close the loop with evidence
Reproduce the pre-fix crash, verify the new build under the same input, and observe crash and restart rates. Verify expiry of dumps, caches, and backups and perform an access review. If removal of sensitive data cannot be proven, the risk remains open.
Sample answer
“I would confirm the signal, journal, kernel OOM records, deployment version, and cgroup metrics, distinguishing SIGSEGV from exit 137. If it is an application crash, I would enable systemd-coredump briefly on an isolated node, cap per-file and total size, and use symbols matching the build ID to inspect stacks before the heap. The encrypted directory would allow short-lived access only to the incident team; tokens would never enter a ticket. I would regression-test the original input, observe crash rate, delete the dump, and review journal, backups, and permissions. If the boundary cannot be made trustworthy, I would disable full dumps and keep only controlled metadata and stacks.”
Common failure modes and fixes
- Assuming a core means SIGSEGV → Verify signal, OOM, cgroup, and deployment evidence.
- Installing tools directly on production → Use matching artifacts and an isolated analysis environment.
- Discussing only disk space → Include quotas, retention, encryption, and cleanup.
- Treating a dump like an ordinary log → Use least privilege, temporary access, and independent audit.
- Stopping after the service recovers → Verify reproduction, crash rate, deletion, backups, and access.
Scoring rubric and self-check
Strong answers cover exit evidence, build IDs and symbols, systemd-coredump boundaries, collection switches, quotas, encryption, access control, retention and deletion, data minimization, rollback, and post-fix metrics.
Ask: Can I prove the cause? Do analysis files match the build? Who can access them? How long are they kept? How are tokens kept out of logs? What proves remediation and cleanup?
Follow-ups and extensions
When should you disable core dumps entirely?
Disable full dumps when the address space is highly sensitive and trustworthy isolation, encryption, access, and cleanup cannot be established. Keep signal, thread-stack, or minimal diagnostic evidence and record the lost diagnostic capability.
How do you reduce risk when only one machine crashes?
Collect metadata and a controlled stack first, limited to that instance and a short window. If a full dump is necessary, use automatic expiry, one-time authorization, and immediate deletion of the local copy after upload.
How do you avoid misleading symbolization?
Verify build ID, checksums, and the artifact manifest for the binary, libraries, and symbols. Mark a stack uncertain when they do not match; never conclude from a similar release.
What if the dump is already in a backup?
Treat backups as a separate data domain. Track object version and expiry, restrict restore access, and make the erasure process cover backup indexes and rotation jobs. Record any approved exception and latest cleanup time.