Security, PII, And Secrets In Banking Systems

What's being tested

Interviewers are probing that you can design and implement practical, secure handling of PII and secrets at the application level: correct use of encryption, key management, access controls, logging hygiene, and safe CI/CD patterns. They want evidence you understand tradeoffs (latency, cost, operability) and that you can reason about attacker models relevant to a Software Engineer's responsibilities. You'll be judged on concrete choices, API-level security, and pragmatic mitigations rather than enterprise policy.

Core knowledge

PII classification: Know types (names, SSNs, account numbers), retention minimization, and how classification drives masking, encryption-at-rest, and access-control decisions in application code paths.
Encryption in transit: Always use TLS (mutual TLS when needed) for service-to-service; validate certificates, disable weak ciphers, and prefer TLS 1.2+ with AEAD ciphers like AES-GCM.
Encryption at rest: Use envelope encryption: data encrypted with a data key (DEK), which is itself encrypted by a key-encryption-key (KEK) managed by `AWS KMS`/`GCP KMS`/`HashiCorp Vault` or an HSM. This removes key exposure from app storage.
Secret management: Integrate with a KMS/secret store (`HashiCorp Vault`, `AWS KMS` + `Secrets Manager`) instead of committing secrets to repo or `env vars`; use short-lived credentials and dynamic secrets where supported.
Tokenization vs hashing: Use tokenization for reversible mapping to preserve format and business use; use salted cryptographic hashing (e.g., `bcrypt`/`argon2`) for irreversible storage, remembering salts must be unique and stored separately.
Least privilege & IAM: Follow least-privilege in application IAM roles: services should only have the specific KMS decrypt/list permissions needed. Prefer role-based access over long-lived API keys.
Secrets in CI/CD: Do not echo secrets in logs, avoid storing secrets in build artifacts, and use the CI system's secret-store features. Use ephemeral agents and workload identities (e.g., OIDC) to mint short-lived creds.
Logging & telemetry hygiene: Instrument audit logs but mask or redact PII before logging. Use deterministic redaction rules and ensure logs containing secrets are stored separately with restricted access and retention.
Rotation & revocation: Automate secret rotation and design for key rollover (support multiple active keys for decrypting older data). Rotation cadence depends on risk; design to support emergency revocation without data loss.
Performance & caching: Cache decrypted values in memory with strict TTLs and guardrails; never persist plaintext to disk or dump in heap to long-lived storage. Consider rate limits and p99 latency when calling `KMS` frequently.
Threat model & attack surface: Enumerate attackers (malicious insider, compromised container, CI compromise) and defend at code-level (input validation, avoid secrets in URLs, protect debug endpoints).
Compliance constraints: Be familiar with `PCI DSS` requirements for card data and data residency/consent obligations from `GDPR` — these affect encryption, access logging, and deletion APIs.

Worked example

Problem: "Design how an API stores and serves customer PII securely." First 30 seconds: ask clarifying questions — which PII fields, read/write patterns, throughput, regulatory constraints, and who needs plaintext access. Skeleton answer pillars: (1) classify fields and decide which need reversible access; (2) choose storage scheme (encrypted columns vs tokenization); (3) key management and rotation via `KMS`/`Vault`; (4) access controls and audit logging; (5) CI/CD and runtime secret handling. A concrete tradeoff: tokenization reduces blast radius but requires a highly-available token service and increases lookup latency; column encryption reduces architectural complexity but complicates searches and indexing. Close by noting monitoring/alerting (`KMS` error rates, token service latency) and follow-ups: "If more time, I'd show data schemas, demo key-rotation flow, and write unit tests that assert redaction in logs."

A second angle

Question variant: "How do you handle secrets for a high-scale batch job that processes historical PII nightly?" Emphasize different constraints: long-running jobs may need cached DEKs, but you must limit in-memory lifetime and use ephemeral worker identities to fetch keys at start. For throughput, use envelope encryption to avoid `KMS` calls per record and decrypt batches with an in-memory DEK rotated per job. Also address failure/retry semantics: design idempotent reprocessing and ensure that rotated keys still allow decryption of previously encrypted records, or include key-version metadata with each record to select the right KEK.

Common pitfalls

Pitfall: Storing secrets in source control or plain `env vars` that are committed.
Many teams accidentally commit credentials; demonstrate you know secret-scanning tools, git-hooks, and how to rotate exposed secrets quickly.

Pitfall: Logging PII or secrets during errors or debug traces.
An engineer who prints request bodies into logs or error emails creates persistent leakage; always sanitize before logging and enforce log-access controls.

Pitfall: Treating encryption as a checkbox without operational plans.
Choosing AES is necessary but insufficient — you must handle key rotation, backup of KEKs, `KMS` availability fallbacks, and test recovery to show you thought end-to-end.

Connections

Interviewers may pivot to secure deployment topics (container secrets, PodSecurityPolicies, workload identities), data lifecycle (retention and deletion APIs), or observability (secure logging and alerting). Knowledge of authz/authn (OAuth/OIDC, JWT handling) is often adjacent.