Is an AWS Lambda environment variable a safe place to store a database password? Explain how Lambda protects environment variables and who is able to read them.

## What Lambda actually does with environment variables Environment variables are part of a function's configuration. You set them with `UpdateFunctionConfiguration`, they are stored by the Lambda service encrypted at rest with a KMS key, and at the start of each execution environment Lambda decrypts them and places them in the process environment, where your runtime reads them as ordinary variables (`process.env.X`, `os.environ["X"]`). The key used for that encryption is the AWS managed key `aws/lambda` unless you specify your own through the function's `KMSKeyArn`. This distinction is the whole security story, because it decides who can read the values back. ## The read path is the risk, not the storage "Encrypted at rest" says nothing about who is authorised to decrypt. With the default AWS managed key, the Lambda service will decrypt on behalf of anyone permitted to describe the function, so a single API call returns the values: ```bash aws lambda get-function-configuration \ --function-name order-writer \ --query 'Environment.Variables' # { "DB_PASSWORD": "hunter2", "TABLE_NAME": "orders" } ``` `lambda:GetFunctionConfiguration` — along with `lambda:GetFunction` and the broad read-only managed policies that include them — is exactly the permission organisations hand to auditors, support engineers, dashboards and CI tooling on the assumption that reading configuration is innocuous. It is not, once a credential is in there. The console shows the same values in the function's configuration pane. Assigning a **customer managed key** changes the calculus. The values are then encrypted under a key whose policy you write, and reading the configuration requires `kms:Decrypt` on that key in addition to the Lambda read permission. Now "who can see the password" is a question you can answer and enforce, and every decryption is a CloudTrail event on your key. A stricter variant stores ciphertext in the variable and decrypts it in the handler, so the Lambda API never returns plaintext at all — but at that point you have hand-built a worse version of a secrets store. ## The lifecycle problem Even with a customer managed key, environment variables are the wrong home for a rotating credential. Values are frozen into function configuration: - Rotating the password requires an `UpdateFunctionConfiguration` on every function that carries it, coordinated with the rotation itself. Between the two, callers authenticate with the wrong value. - The value tends to leak into places you did not intend: infrastructure templates checked into git, pipeline variables, deployment logs, screenshots of the console. - Environment variables are also capped — the total size of a function's environment variables is 4 KB as of 2026 — so a certificate or a large credential bundle does not fit anyway. Secrets Manager and Parameter Store exist for precisely this shape: the value is fetched at runtime, so rotating it changes behaviour without touching the function; access is a separate IAM decision (`secretsmanager:GetSecretValue`, `ssm:GetParameter`, plus `kms:Decrypt` for a SecureString or a customer managed key); and every read is auditable. ## The pragmatic split A rule of thumb that survives interview scrutiny: - **Environment variables** — non-secret configuration that differs per stage: table and bucket names, queue URLs, endpoint hostnames, log level, feature flags, the *identifier* of the secret to fetch. These also cost nothing to read and are available instantly. - **Secrets Manager / Parameter Store** — anything that would be damaging to disclose or that rotates: database passwords, third-party API keys, signing keys, private certificates. Notice that the environment variable still plays a role in the second case: you put the secret's name or ARN in `DB_SECRET_ID` and let the code resolve it. That keeps the function's configuration environment-specific without ever carrying the credential. ## Answering the question well Do not answer with a flat "no, that's insecure" — interviewers want the mechanism. Say that the values are KMS-encrypted at rest but returned decrypted to anyone with configuration-read permission under the default key; that a customer managed key turns that into an explicit, auditable `kms:Decrypt` grant; and that even then, static configuration is a poor home for a value that rotates. Then give the split: identifiers in environment variables, credentials in a secrets store.