AWS Engineer interview questions

An AWS Region is a separate geographic area where AWS operates multiple Availability Zones.

• I would first meet data residency and compliance requirements because they can rule out otherwise suitable Regions.
• I would confirm that the required services and instance types are available there, since AWS offerings differ by Region.
• I would then compare latency to users and regional pricing, keeping dependent resources close to avoid transfer delay and cost.

An Availability Zone is an isolated location within a Region with independent power, cooling, and networking.

• AZs in one Region are connected by high-bandwidth, low-latency links, so an application can operate across them.
• I would place redundant application instances in at least two AZs so one location does not become the only failure point.
• Cross-AZ traffic can add data transfer cost, so I would gain resilience deliberately rather than spread resources without a reason.

Edge locations bring selected AWS services closer to users without running the whole workload in every location.

• CloudFront caches content at edge locations, which reduces latency and load on the origin.
• Route 53 and AWS Shield also use the global edge network for DNS responses and traffic protection.
• An edge location is not an Availability Zone, so I would still deploy the application's compute and database in a Region.

AWS secures the cloud infrastructure, while the customer secures what they configure and run in the cloud.

• AWS is responsible for facilities, physical hardware, and the foundational networking and virtualization layers.
• The customer manages identities, data access, network rules, and guest operating system patches on EC2.
• The boundary shifts with managed services, so AWS patches the RDS host while I still control database users, encryption, and configuration.

The control plane manages resource configuration, while the data plane handles the workload's actual traffic and data.

• Creating an S3 bucket, changing an IAM policy, or launching an EC2 instance uses control plane APIs.
• Reading an S3 object or serving an application request through an instance is data plane activity.
• I separate their permissions and monitoring because an operator may need to deploy a resource without reading the customer data it processes.

I use users for specific people or exceptional long-lived identities, groups to organize user permissions, and roles for temporary access.

• A group can give several IAM users the same job-based policies, but a group cannot be assumed like a role.
• EC2, Lambda, federated employees, and cross-account principals should assume roles instead of storing access keys.
• For a human workforce I would prefer IAM Identity Center, reserving IAM users for cases that truly require them.

AWS allows a request only when an applicable policy allows it and no applicable policy explicitly denies it.

• Requests start with an implicit deny, so having no matching Allow statement means access is refused.
• An explicit Deny overrides an Allow from an identity policy or resource policy.
• Permission boundaries and organization policies can limit an Allow, but they do not grant permission by themselves.

Least privilege means granting only the actions and resources needed for a defined task.

• I would replace a broad action such as s3:* with exact operations such as s3:GetObject on one bucket prefix.
• I would add conditions where useful, such as requiring a specific source VPC endpoint or resource tag.
• I would review CloudTrail activity and IAM Access Analyzer findings to remove permissions that the workload does not use.

I would require MFA for every human identity with console or privileged access and for the root user if root credentials exist.

• Centralized root access in AWS Organizations can remove root credentials from member accounts; otherwise root should have no access keys, use securely stored MFA, and be reserved for root-only tasks.
• IAM Identity Center can enforce MFA centrally for workforce sign-in instead of configuring separate IAM users.
• MFA reduces damage from a stolen password, but workloads should use roles rather than interactive MFA or long-lived keys.

AWS Security Token Service issues temporary credentials for an assumed role or federated session.

• The credentials include an access key ID, secret access key, session token, and expiration time.
• A service, user, or external identity assumes a role and receives only the permissions attached to that session.
• Expiring credentials reduce the useful lifetime of a leak and avoid distributing permanent keys to EC2 instances or CI jobs.

A VPC CIDR block defines the private IP address range from which its subnets receive addresses.

• I would choose enough address space for expected subnets and growth because every subnet reserves part of that range.
• I would avoid overlap with office networks, other VPCs, and planned partner networks so routing can work later.
• For IPv4 I would normally use an RFC 1918 range such as 10.20.0.0/16 and divide it into smaller subnet CIDRs.

A subnet is public when its route table has a route to an internet gateway, while a private subnet has no direct route there.

• A resource in a public subnet also needs a public IPv4 address or IPv6 address and suitable security rules to use the internet path.
• I would put internet-facing load balancers in public subnets and application instances or databases in private subnets.
• Private resources can still make outbound IPv4 connections through a NAT gateway without accepting unsolicited inbound internet traffic.

A route table maps destination CIDR blocks to targets such as a local VPC path, internet gateway, or NAT gateway.

• Each subnet is associated with one route table, either explicitly or through the VPC's main route table.
• The built-in local route lets subnets in the same VPC communicate unless security controls block the traffic.
• When several routes match, AWS uses the most specific prefix, so 10.0.1.0/24 wins over 10.0.0.0/16.

An internet gateway is the VPC target that enables communication between public IP addresses in the VPC and the internet.

• I attach one internet gateway to the VPC and add a route such as 0.0.0.0/0 from public subnet route tables.
• For IPv4, it performs the public-to-private address translation for an instance that has a public IPv4 address.
• It does not open ports by itself, because security groups, network ACLs, and host firewalls still control traffic.

A NAT gateway lets resources in a private subnet initiate outbound IPv4 connections without becoming directly reachable from the internet.

• I place the public NAT gateway in a public subnet, associate an Elastic IP, and route the private subnet's 0.0.0.0/0 traffic to it.
• Return traffic for an established connection is allowed, but an internet client cannot initiate a connection through that gateway.
• For resilient multi-AZ designs I use a NAT gateway per AZ, while accounting for hourly and data processing charges.

A security group is a stateful firewall for attached resources, while a network ACL is a stateless filter at the subnet boundary.

• Security groups contain allow rules only, and response traffic is automatically allowed for an accepted connection.
• Network ACLs support both allow and deny rules, process numbered rules in order, and require explicit return-path rules.
• I use security groups as the main workload control and keep NACLs as a broader subnet guardrail when one is needed.

I would use Route 53 hosted zones, with public zones for internet DNS and private zones for selected VPCs.

• A public hosted zone can map app.example.com to an ALB using an alias record.
• A private hosted zone resolves only from associated VPCs, which suits internal service names such as db.internal.example.com.
• VPC DNS support and DNS hostnames must be configured correctly so workloads can use the Amazon-provided resolver and generated names.

An Elastic IP is a static public IPv4 address that I can associate with a supported resource in one Region.

• It is useful when an allowlist requires a stable source address, such as outbound traffic through a NAT gateway.
• I would not assign one to every EC2 instance because load balancers and DNS usually provide cleaner application endpoints.
• Public IPv4 addresses are billed and scarce, so I would release an Elastic IP as soon as it is no longer required.

VPC peering provides private IP connectivity between two VPCs through the AWS network.

• I create and accept the peering connection, add routes in both VPCs, and allow the traffic in security controls.
• The VPC CIDR ranges must not overlap because AWS needs unambiguous routes between them.
• Traffic stays on AWS infrastructure, but normal cross-AZ and inter-Region data transfer charges can still apply.

VPC peering is not transitive, so one peering connection cannot be used as a router to another VPC.

• If VPC A peers with B and B peers with C, A cannot reach C through B.
• I would create the required direct peerings for a small network and maintain explicit routes for each connection.
• For many VPCs that need hub-and-spoke routing, I would evaluate AWS Transit Gateway instead of a large peering mesh.