AWS Engineer interview questions

I would give each Availability Zone separate public, private application, and isolated data subnets from a nonoverlapping CIDR.

• A /16 VPC can reserve one /20 per subnet tier and AZ, leaving address space for growth without renumbering.
• Internet-facing load balancers use the public subnets, workloads use private subnets, and databases stay in isolated subnets with no default internet route.
• Each private subnet routes through a NAT gateway in the same AZ so an AZ failure does not create a cross-AZ egress dependency.

AWS first selects the most specific matching prefix, then applies route priority rules when prefixes are identical.

• A route for 10.20.4.0/24 wins over 10.20.0.0/16 regardless of whether its target is a Transit Gateway, peering connection, or network interface.
• For the same prefix, a static route normally wins over a propagated route, while the local VPC route cannot be removed or overridden by a less specific entry.
• I validate both forward and return route tables because stateful security groups do not repair asymmetric routing through a stateful appliance.

I use gateway endpoints for private S3 or DynamoDB access and interface endpoints for services exposed through AWS PrivateLink.

• A gateway endpoint adds prefix-list routes to selected route tables and has no hourly endpoint charge.
• An interface endpoint creates private IP addresses in chosen subnets, uses security groups, private DNS, and incurs hourly plus data-processing charges.
• Endpoint policies restrict which resources callers can reach, but IAM and resource policies still decide whether each API call is authorized.

I would place the provider service behind a Network Load Balancer and publish a VPC endpoint service for approved consumers.

• Consumers create interface endpoints in their own subnets, so neither side needs routable CIDRs, VPC peering, or broad network access.
• I require explicit endpoint connection acceptance unless an allow list safely automates it, and I restrict the service with IAM principals where supported.
• Private DNS needs ownership verification and consumer-side private DNS enablement so the service name resolves to endpoint IPs.

I would separate routing domains with multiple Transit Gateway route tables and associate each attachment with the table for its trust zone.

• Spoke attachments propagate to a shared-services table only where connectivity is required, rather than using one fully meshed route table.
• A production table can route shared-service prefixes to their attachment while omitting routes to development spokes, creating isolation by absence of a route.
• I plan symmetric paths through inspection VPC appliances and enable appliance mode when flows must remain on the same zonal firewall path.

I choose the policy from the traffic decision the application actually needs, not from the number of endpoints.

• Weighted records split traffic by configured ratios for canaries, while latency records choose the AWS Region with the lowest measured network latency.
• Failover records combine primary and secondary targets with health evaluation, whereas geolocation records choose by the requester's geographic origin and need a default.
• DNS TTL controls how quickly clients observe a change, but recursive resolver caching means Route 53 routing is not an instant connection drain.

I would use Route 53 Resolver inbound and outbound endpoints with conditional forwarding rules over Direct Connect or VPN.

• On-premises DNS forwards private AWS zones to inbound endpoint IPs placed in at least two Availability Zones.
• VPCs associate outbound rules such as corp.example.com with outbound endpoints that forward queries to on-premises DNS servers.
• Security groups allow UDP and TCP port 53 as appropriate, while stateless network ACLs must also allow DNS queries to destination port 53 and return traffic to ephemeral client ports in the reverse direction.

I choose an ALB for HTTP-aware routing and an NLB for layer-four performance, static IP needs, or protocols beyond HTTP.

• An ALB can route by host, path, header, or query string and integrates with WAF, while an NLB forwards TCP, TLS, UDP, or TCP_UDP flows.
• Terminating TLS at the load balancer centralizes ACM certificates and policy, but re-encryption to HTTPS targets protects the load balancer-to-workload hop.
• TLS passthrough on an NLB preserves end-to-end termination at the application but gives up ALB request inspection and managed HTTP routing.

A trust policy defines who may assume the role, while permissions policies define what an assumed role session may do.

• The trust policy is a resource-based policy on the role and names principals plus conditions such as ExternalId, source account, or OIDC claims.
• For a same-account IAM user or role named directly as a principal, the trust policy can be sufficient to allow AssumeRole without a separate identity-policy allow, subject to its conditions.
• Cross-account assumption normally requires an identity-policy allow for sts:AssumeRole on the caller and matching target trust; permissions boundaries, SCPs, session policies, and any explicit deny can still restrict assumption or the resulting session.

Role chaining creates a new role session from temporary credentials, and a session policy can only narrow the new session's permissions.

• A chained role session is limited to a maximum duration of one hour even if the target role allows a longer session.
• The effective permissions are the intersection of the role policies and inline or managed session policies passed to STS.
• I pass session tags for attribute-based controls and mark only required tags as transitive when another chained role must receive them.

I use a permissions boundary as the maximum permission set for delegated role or user creation, not as a policy that grants access.

• A platform role can let a team create application roles only when each new role carries a prescribed boundary.
• Effective identity permissions are the intersection of attached identity policies and the boundary, so adding AdministratorAccess cannot exceed the boundary.
• Resource policies, SCPs, session policies, and explicit denies still participate separately, so I test the complete authorization path with Policy Simulator or CloudTrail.

An SCP sets the maximum available permissions for principals in member accounts but does not grant any API permission itself.

• An action must be allowed by the applicable SCP and by IAM, while an explicit deny in either layer wins.
• A permissions boundary limits a specific principal; an SCP limits affected accounts or organizational units, including newly created roles inside them.
• SCPs do not restrict the management account and do not directly change resource-based permissions for principals outside the organization.

I prefer a target-account role with a narrow trust policy and least-privilege permissions, assumed by a named source principal.

• The source principal needs sts:AssumeRole permission, and the target trust policy restricts the principal plus conditions such as aws:PrincipalOrgID when appropriate.
• For a third-party caller I require a unique ExternalId to reduce confused-deputy risk, but it is not a secret or a substitute for principal restriction.
• Direct resource policies can suit S3 or KMS, yet an assumed role gives consistent temporary credentials and a clear CloudTrail session identity.

Envelope encryption protects data with a generated data key and protects that data key with a KMS key.

• The application calls GenerateDataKey, encrypts the payload locally with the plaintext data key, stores the encrypted data key beside the ciphertext, and discards the plaintext key.
• Decryption sends the encrypted data key to KMS, then uses the returned plaintext data key locally, avoiding a KMS call for every data block.
• The KMS key policy must enable the principal or IAM delegation, and encryption context conditions can bind decrypt permission to a specific application or resource.

I would store the credential in Secrets Manager and use a rotation Lambda that advances the secret through the documented staging labels.

• The function creates AWSPENDING, updates the database user, verifies the pending credential, then moves AWSCURRENT only after the test succeeds.
• Alternating-user rotation can reduce the gap where old connections and new credentials overlap, provided the database privileges stay equivalent.
• Applications fetch the current secret at runtime with bounded caching and retry authentication after cache refresh instead of embedding a value at deployment.

I would define several compatible instance types and combine a stable On-Demand base with diversified Spot capacity.

• Attribute-based instance selection or explicit overrides keep vCPU, memory, and architecture compatible with the application image.
• Capacity-optimized Spot allocation reduces interruption risk, while the On-Demand base covers the minimum capacity required for steady traffic.
• Scaling uses a target metric such as ALB requests per target, and instance refresh rolls new versions while preserving a configured healthy percentage.

I would treat each numbered launch template version as an immutable release artifact and pin the Auto Scaling group to an explicit version at every promotion.

• The pipeline creates a new numbered version with the tested AMI and configuration, records that number with the release, and updates the ASG only after validation; production never references `$Latest` or `$Default`.
• Each promotion starts an instance refresh with defined minimum healthy capacity, warmup, alarms, and checkpoints after small percentages, so the pipeline evaluates service health during each pause and cancels a bad rollout.
• If a checkpoint or alarm rejects the release, I roll the refresh back to the last known-good pinned version and verify every instance against that version; automatic rollback can enforce the same path because neither ASG state uses a dynamic version reference.

Lifecycle hooks pause instance launch or termination so automation can finish work before Auto Scaling continues.

• A launch hook can install configuration, register an external agent, or warm a large cache before completing with CONTINUE.
• A termination hook can drain work or export local state, while the load balancer deregistration delay separately handles in-flight requests.
• EventBridge or SNS delivers the event to automation, and a heartbeat extends the timeout only for bounded work rather than hiding a stuck process.

I choose Fargate when per-task isolation and low host operations matter, and ECS on EC2 when host control or sustained utilization justifies fleet management.

• Fargate bills requested task vCPU and memory, removes node patching, and supports straightforward capacity providers for serverless tasks.
• EC2 can be cheaper for dense steady workloads and supports specialized AMIs, GPUs, daemon-style agents, and broader instance choices.
• Both use ECS services, task definitions, IAM task roles, and load balancing, so I keep deployment artifacts portable where platform features allow it.

AWS runs the highly available Kubernetes API server and etcd control plane, while I manage cluster access, workloads, networking, add-ons, and worker capacity.

• The control plane spans multiple Availability Zones and exposes configurable public and private API endpoints with Kubernetes audit and API logs available to CloudWatch.
• I still configure EKS access entries and access policies, RBAC, Pod Security controls, network policies, and secrets handling.
• Core add-ons such as VPC CNI, CoreDNS, and kube-proxy need compatible versions and planned upgrades even when installed as EKS managed add-ons.