50 AWS Interview Questions and Answers for Java Developers

Create an IAM role in the destination account with the required S3 permissions and a trust policy allowing the source principal to assume it. The Java application uses STS AssumeRole to obtain temporary credentials. The destination bucket policy and any KMS key policy must also permit the intended cross-account access where required.

Use a coordinated credential rotation strategy, potentially with Secrets Manager rotation and RDS Proxy. Ensure applications can obtain refreshed credentials and recreate database connections when necessary. Test overlapping credential validity, connection-pool behavior, and recovery during rotation before enabling automation.

Check whether the bucket notification matches the object's event type, key prefix, and suffix. Verify Lambda invocation permissions and inspect CloudWatch logs and invocation metrics. Review asynchronous invocation failures, retry behavior, and configured failure destinations where applicable.

Each ECS task maintains its own connection pool, so scaling task count increases total potential database connections. For example, 20 tasks with a maximum pool size of 20 can request up to 400 connections. Review RDS connection limits, HikariCP settings, transaction duration, and whether RDS Proxy would improve connection management.

Configure bounded connection timeouts and retry transient connection failures at safe application boundaries. Allow the connection pool to discard invalid connections and establish new ones after the database endpoint resolves to the active instance. Keep transactions idempotent where retries are possible and monitor failover recovery time.

Use a versioned migration tool such as Flyway or Liquibase and ensure migrations are coordinated across deployments. Prefer backward-compatible schema changes so old and new application versions can operate during rolling updates. Separate destructive changes into later releases after dependent application versions have been retired.

When the visibility timeout expires, the message can become available to another consumer even if the first consumer is still processing it. This can cause concurrent duplicate processing. Set an appropriate timeout or extend message visibility during long-running operations, while preserving idempotent processing.

Use the transactional outbox pattern to persist the order and an outgoing event in the same database transaction. A separate publisher sends committed outbox events to SQS and records successful publication. Consumers must handle duplicate delivery because a crash can occur after publishing but before marking the event complete.

Scale consumers using queue backlog, age of oldest message, and measured processing throughput rather than CPU alone. Use ECS Service Auto Scaling or another suitable worker-scaling mechanism. Cap concurrency based on downstream database and API capacity to avoid moving the bottleneck into dependent systems.

Configure partial batch response handling using ReportBatchItemFailures. Return the identifiers of failed messages so successfully processed messages can be removed from the queue. For FIFO queues, stop processing after the relevant failure and report failed and unprocessed messages to preserve ordering.

Lambda can scale concurrent execution environments rapidly, with each environment potentially opening database connections. Use RDS Proxy where suitable, reuse connections across warm invocations, and limit Lambda concurrency. For high-volume workloads, consider buffering requests through SQS to control database write pressure.

Check whether the Lambda function's subnets have a valid outbound network path through a NAT gateway or another appropriate route. Verify security groups, network ACLs, DNS resolution, and API connectivity. A Lambda function attached to a public subnet does not automatically receive a public IP address for internet access.

Verify the target group's health-check path, port, protocol, and expected response codes. Check Spring Boot's listening address, server port, startup duration, and container health configuration. Inspect task logs, security groups, target registration, and health-check grace periods.

Run multiple healthy tasks behind an Application Load Balancer and configure deployment capacity to maintain service availability. Use readiness checks to prevent routing traffic to tasks before initialization completes. Enable graceful shutdown, connection draining, and backward-compatible database migrations during overlapping application versions.

Maintain separate production and replacement environments, each running a defined application version. Validate the replacement environment before shifting traffic through a supported deployment mechanism such as CodeDeploy with load balancer integration. Monitor health and business metrics, then redirect traffic to the previous environment if the new release fails.

Deploy application instances across multiple Availability Zones behind a load balancer. Use a database configuration supporting appropriate cross-zone failover and avoid storing critical state on individual application instances. Test failure scenarios, capacity requirements, health checks, and recovery procedures rather than assuming Multi-AZ deployment alone guarantees availability.

Correlate CloudWatch metrics, application logs, and distributed traces to identify slow dependencies. Inspect ALB target response time, RDS latency, connection pools, and external API calls. Use request correlation identifiers and tracing instrumentation to distinguish network delays from database or application bottlenecks.

CPU utilization alone may not represent actual service capacity when requests have different processing costs. Consider ALB requests per target, latency, CPU, memory, and custom application metrics. Configure scaling thresholds, cooldown behavior, and minimum capacity based on load testing and downstream resource limits.

Define recovery time objective and recovery point objective before selecting a disaster recovery strategy. Use appropriate RDS backups, cross-Region replication or recovery mechanisms, and S3 replication where required. Maintain infrastructure definitions, secure backup access, and regularly test restoration and failover procedures.

Create appropriate VPC endpoints for the required AWS services, such as gateway endpoints for S3 and interface endpoints for SQS. Configure route tables, endpoint policies, security groups, and private DNS where applicable. Verify that the application's IAM role and resource policies still permit the required operations.

Deploy stateless Spring Boot services across multiple Availability Zones using ECS or EC2 behind an Application Load Balancer. Use RDS with appropriate high availability, S3 for images, and SQS for asynchronous order and notification processing. Apply IAM least privilege, transactional outbox and idempotency patterns, autoscaling, CloudWatch monitoring, secure secrets management, and tested recovery procedures.