Security Interview Questions

Identity policies grant actions such as GetItem and Query on table and index ARNs. The caller needs an IAM principal (role, user) with those statements. There is no SQL GRANT; a missing dynamodb:Query on the index ARN is a common production 400/AccessDenied.

Server-side encryption is on by default with AWS owned keys; you can use AWS managed or customer managed KMS keys. Encryption at rest does not replace IAM. Losing IAM control of a CMK can make the table unreadable even if the data is still there.

The public API is HTTPS/TLS. Inside a VPC, use gateway endpoints so packets stay on the AWS network. Plain HTTP is not a DynamoDB option; the remaining risk is usually a mis-logged secret or a client that disables certificate checks.

A wildcard lets a leaked task role Scan every table in the account, including PII and payment tables. Scope ARNs to table/index and the actions the service actually calls. Separate read-only reporting roles from the write path.

Private routing from subnets to DynamoDB without a NAT/public IP, plus endpoint policies that can deny access except from that VPC. It reduces data-exfil paths that go out to the internet. It is not encryption by itself and does not replace IAM on the table.

IAM condition keys such as dynamodb:LeadingKeys restrict a principal to items whose partition key matches a value (often ${cognito-identity.amazonaws.com:sub}). That is item-level isolation for mobile/IoT patterns. It is not a substitute for putting tenantId in the key correctly.

Management events (CreateTable, UpdateTable, DeleteTable, UpdateTimeToLive) at minimum; data-plane logging is optional and expensive but used in high-compliance accounts. Alarms on DeleteTable and policy changes catch accidents. Trail logs are not a replacement for application audit fields.

List the table ARN and each index ARN (or a tight suffix pattern) with the exact actions. Query on a GSI fails if you only allowed the table ARN. Review the policy whenever you add a GSI or the app will break or someone will widen to *.

The condition compares the request’s partition key to a session value so tenant A’s role cannot GetItem tenant B’s PK. Combined with PK=tenantId#… this is strong. If the PK is a global userId, LeadingKeys cannot express tenancy and you must enforce it in the app.

When you need key rotation ownership, CloudTrail on key use, or the ability to revoke access by disabling the key. AWS owned keys are simpler. CMKs add blast radius: a bad key policy outage looks like a DynamoDB outage.

Deny dynamodb:DeleteTable except for a break-glass role, enable deletion protection, and require MFA on the admin role. PITR and backups recover data, not a fat-finger in CI with admin credentials. Separate apply-time Terraform roles from runtime task roles.

Task/instance/IRSA roles, never long-lived access keys in source or mobile binaries. Clients that embed keys get scraped. Frontend apps should call your API; they should not hold dynamodb:* on the user’s table.

The table itself can deny or allow principals, including cross-account access, similar to S3 bucket policies. Use it to enforce “only these roles” even if someone attaches a wide identity policy later. Conflicting allows still follow IAM evaluation; test with policy simulator.

Enable data-plane CloudTrail for that table or use AWS Config/GuardDuty-style detections, plus application logs that should not Scan at all. Alert on Scan/Query with no PK from unexpected roles. After-the-fact forensics is harder if you never logged GetRecords-style data events.

PK prefixed by tenant, LeadingKeys or equivalent ABAC, separate roles per tenant only if the model requires it, and no Scan in tenant roles. App-layer checks are defense in depth, not the only control. A reporting user with Scan is the usual isolation hole.

SCPs set the account ceiling (deny LeaveOrganization-style and deny DynamoDB outside the endpoint). Endpoint policies restrict which tables the VPC can reach. Table policies name principals. You want all three aligned; any one allow with a * elsewhere undoes the rest.

Read, write, delete, stream, backup, and restore on every table the account can see, including tearing down PITR recovery points depending on actions granted. Treat that as production-break-glass only. Runtime microservices should have a handful of actions on a handful of ARNs.

Use KMS automatic rotation for CMKs where supported, or re-encrypt by updating the table’s SSE specification to a new key and allowing AWS to re-encrypt. Test restore from backup under the new key. Disabling the old key before re-encryption completes is an outage.

Anomaly alarms on ConsumedReadCapacity, Scan count, and data-event CloudTrail from unusual IPs or roles, plus VPC endpoint policies that block the internet path. Rate-limit Scan in IAM where possible (not always expressive) and ban Scan from app roles entirely. Assume breach: least privilege first.

A table resource policy allowing a specific role in the consumer account, plus that role’s identity policy, often with an external ID or ABAC tags. Sharing a long-lived key is not cross-account design. Copying data with Export to S3 and a bucket policy is sometimes cleaner than live Query across accounts.