Security

Explain how AWS IAM Role assumption works across different AWS accounts securely.

One account can use another account's resources without a password or an access key ever changing hands. The role's trust policy decides who is allowed in, its permissions policy decides what they can do once they're there, and STS hands out credentials that expire on their own.

Your EC2 instances in a private subnet need to reach S3 and a third-party API, but must never be reachable from the internet. Design the networking.

Outbound-only access comes from a NAT Gateway in a public subnet, but S3 traffic should skip it entirely through a VPC endpoint, which is free and never leaves the AWS network. Nothing can reach in because there's no route for it to take, not because a rule is blocking it, and that distinction is usually the real follow-up question.

A subnet holds your most sensitive data. Design the Network ACL rules around it as a second layer of defense behind Security Groups.

A NACL earns its place by doing the one thing a Security Group can't: an explicit, subnet-wide deny that survives a misconfigured Security Group rule. The design is a default-deny rule set with narrow, numbered exceptions, remembering that NACLs are stateless, so return traffic on ephemeral ports needs its own explicit allow.

Multiple teams share one AWS account. How do you structure IAM so each team can only touch the resources they own?

Individual users each get their own IAM role via SSO federation, never a shared login or a long-lived access key, and permissions are grouped by team into roles scoped with resource tags rather than hardcoded ARNs. Past a certain team count, the real fix is separate AWS accounts per team, not tighter policies inside one shared account.

How do you make sure data is encrypted everywhere it lives in AWS, both at rest and in transit, without it becoming a project unto itself?

At rest, nearly every AWS storage service takes a KMS key as a one-time setting at creation, and the actual work is deciding who can use that key, not the encryption itself. In transit, TLS terminated with a Certificate Manager certificate covers the external hop, but internal service-to- service traffic needs its own explicit decision, since nothing enforces it by default.

Design layered protection for a public-facing web application against DDoS attacks and common web exploits.

No single AWS service handles both problems, since a volumetric DDoS attack and a targeted web exploit look nothing alike at the network layer. CloudFront and Shield absorb and dilute volume before it reaches your origin, and WAF inspects individual requests for exploit patterns. Both sit in front of the origin, stacked, not swapped for each other.

How do you continuously monitor an AWS account for security and compliance drift, instead of only finding out during an annual audit?

Point-in-time audits catch a configuration that was wrong when someone happened to look. AWS Config evaluates resources continuously against rules and records every configuration change, CloudTrail records who made it, and Security Hub aggregates both into one place with a severity score so drift gets flagged the hour it happens, not the quarter someone checks.

How do you safely rotate IAM credentials or database secrets without downtime?

The safe pattern is overlapping validity. Create the new secret while the old one still works, get code that accepts either one deployed everywhere, confirm the new one is actually being used, then revoke the old one. Rotating in a single step guarantees a window where something is still holding a credential that no longer works.

You accidentally committed a .env file containing API keys. What do you do?

Rotate the credentials first. That's the only step that actually makes you safe, since the secret is already in every clone, fork and CI cache that pulled before you noticed. Cleaning up Git history is a second, separate job that comes after.

A secret was committed six months ago and exists in hundreds of commits. What do you do?

Treat it as a security incident, not a Git cleanup task. Rotate first, then work out the blast radius, then decide honestly whether rewriting history is worth the cost. The rewrite is the most visible part of the response and the least important one.

Your organization wants signed commits for production code. How would you implement it?

git config user.email is free text, not identity, so signing is what turns authorship into a cryptographic claim. Roll out SSH signing, enforce it with branch protection and a trusted-key list, and plan for the parts that actually break rollouts: bots, squash merges, and key rotation.

Someone moved a production Git tag to a different commit. Why is that dangerous?

A release tag is a promise that a version name means one exact, unchanging set of code. Moving it breaks that promise everywhere at once: rollbacks, audits, incident timelines, and any pipeline that deploys by tag now point somewhere different from what people believe, and some clones won't even notice the change.

Your organization wants production deployments to be reproducible six months later. How does Git help?

Git pins the source exactly and that's all it pins. Real reproducibility also needs locked dependencies, versioned infrastructure, immutable artifacts, and a stored record linking a deployment to its digest, plus keeping the actual artifact, because rebuilding it later is rarely byte-identical.

Someone force-pushed main at 2 AM. How do you investigate?

Preserve evidence first, then answer four questions: what was main before, what is it now, who did it, and was anything deployed from the rewritten history. Treat it as potentially malicious until the audit log says otherwise, because a force-push at 2 AM is an unusual enough event to earn that default.

An attacker steals a developer's Git credentials and pushes malicious code. How do you defend against this?

Assume one credential will eventually be stolen and design so that alone isn't enough to ship code. Layer identity, branch protection, review, signing, pipeline isolation and detection, and remember the attacker's real target is usually the CI workflow, not the application code itself.