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.

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.