15 AWS DevOps Interview Questions That TCS Frequently Asks 🚀
15 AWS DevOps Interview Questions That TCS Frequently Asks 🚀
Complete Interview Preparation Guide With Production Scenarios, Commands, Troubleshooting and Candidate-Style Answers
Preparing for an AWS DevOps interview? Memorising AWS definitions is a start, but interviewers often want to know how you would use those services when a production system starts misbehaving.
Imagine an application running on AWS. Traffic suddenly increases, some requests return HTTP 503, and the deployment pipeline has just released a new version. The interviewer asks:
How would you troubleshoot the load balancer?
How would you scale the application?
How would you roll back the deployment?
How would you ensure Terraform does not accidentally replace production infrastructure?
These are not isolated questions. They test whether you understand how cloud infrastructure, CI/CD, security and troubleshooting work together.
This guide covers 15 important interview topics across three sections:
☁️ AWS Cloud Fundamentals
🔄 CI/CD and Continuous Delivery
🏗️ Terraform and Infrastructure as Code
For every question, follow the same eight-part framework:
🧠 Simple Concept
❓ Why Do We Need It?
⚙️ How Does It Work?
🏢 Production Example
💻 Command / Configuration
🚨 Common Interview Trap
🎯 Candidate-Style Answer
🧠 Memory Trick
The objective is simple: understand the concept, explain the technical details, and demonstrate how you would apply it in a real environment.
Note: These are relevant AWS DevOps interview-preparation questions, not a verified list of questions guaranteed to be asked by TCS.
SECTION 1: AWS Cloud Fundamentals ☁️
Question 1: What Is the Difference Between an Application Load Balancer and a Network Load Balancer?
🧠 Simple Concept
An AWS load balancer distributes incoming traffic across multiple targets.
An Application Load Balancer (ALB) works at Layer 7 and understands application-level traffic such as HTTP and HTTPS.
A Network Load Balancer (NLB) works primarily at Layer 4 and handles network traffic such as TCP, UDP and TLS according to its supported listener configuration.
❓ Why Do We Need It?
A single server can become overloaded when too many users access an application. A load balancer distributes traffic and can direct requests away from unhealthy targets.
The choice depends on whether you need application-aware routing or high-performance network-level load balancing.
⚙️ How Does It Work?
ALB supports host-based and path-based routing.
NLB routes connections based on network-level information and listener configuration.
Both can use target health checks to help avoid sending traffic to unhealthy targets.
🏢 Production Example
An e-commerce application has separate API and web services.
The ALB routes /api requests to the API target group and other requests to the web target group.
A separate TCP-based service that needs Layer 4 load balancing and static IP addresses may be better suited to an NLB.
💻 Command / Configuration
Example ALB listener rule:
IF path = /api/*
THEN forward to API target groupUseful troubleshooting commands:
aws elbv2 describe-load-balancers
aws elbv2 describe-target-health \
--target-group-arn <target-group-arn>Replace the placeholder with the actual target group ARN.
🚨 Common Interview Trap
Do not say that an NLB is simply a faster ALB. They operate at different layers and serve different requirements.
Also remember that an unhealthy target can result from application failures, incorrect health-check paths, security rules or connectivity problems.
🎯 Candidate-Style Answer
“An ALB works at Layer 7 and supports application-aware routing, such as host-based and path-based routing for HTTP and HTTPS. An NLB operates primarily at Layer 4 and is suitable for high-performance TCP, UDP and TLS traffic. I select the load balancer based on protocol requirements, routing needs, performance and architecture.”
🧠 Memory Trick
ALB = Application logic. NLB = Network-level traffic.
Question 2: How Does Auto Scaling Work in AWS?
🧠 Simple Concept
Amazon EC2 Auto Scaling automatically adjusts the number of EC2 instances according to configured policies and capacity limits.
❓ Why Do We Need It?
Traffic changes throughout the day. A fixed number of instances may be insufficient during peak demand and unnecessarily expensive during quiet periods.
Auto Scaling helps balance availability, performance and cost.
⚙️ How Does It Work?
Define a launch template.
Create an Auto Scaling group.
Configure minimum, desired and maximum capacity.
Define scaling policies and monitoring metrics.
Configure health checks and Availability Zone distribution.
Monitor scaling activity and application health.
🏢 Production Example
An application normally runs three instances. When demand increases and a target-tracking policy detects sustained high CPU utilisation, the Auto Scaling group increases capacity.
When demand falls, it can scale in while respecting the minimum capacity.
💻 Command / Configuration
Example target-tracking policy concept:
{
"TargetValue": 50.0,
"PredefinedMetricSpecification": {
"PredefinedMetricType": "ASGAverageCPUUtilization"
}
}This illustrates a target of 50% average CPU utilisation. The actual policy must be associated with the correct Auto Scaling group and configured using the relevant AWS API or CLI command.
Inspect scaling activity:
aws autoscaling describe-scaling-activities \
--auto-scaling-group-name <asg-name>🚨 Common Interview Trap
Adding instances does not automatically fix every performance problem. A database bottleneck, memory leak or slow external API may remain the root cause.
🎯 Candidate-Style Answer
“I use an EC2 Auto Scaling group with launch templates, health checks and scaling policies. I configure capacity limits and distribute instances across Availability Zones. I also monitor application metrics because scaling the compute tier alone cannot resolve every bottleneck.”
🧠 Memory Trick
Launch, Monitor, Scale, Verify.
Question 3: What Is the Difference Between Security Groups and Network ACLs?
🧠 Simple Concept
Both control network traffic in a VPC, but they operate at different levels.
Security groups: Stateful controls associated with supported network interfaces.
Network ACLs: Stateless controls applied at the subnet level.
❓ Why Do We Need It?
They help restrict communication between application components and reduce unauthorised access.
⚙️ How Does It Work?
Security groups:
Allow rules only, without explicit deny rules.
Automatically allow response traffic for permitted connections.
Commonly define which application components can communicate.
Network ACLs:
Support allow and deny rules.
Evaluate rules in numerical order.
Require inbound and outbound traffic to be considered separately.
🏢 Production Example
A web application receives HTTPS traffic through an ALB. The application security group permits traffic from the ALB security group on the application port.
The database security group permits connections only from the application tier on the required database port.
💻 Command / Configuration
Example security group rule concept:
Type: Custom TCP
Port: 8080
Source: Application Load Balancer security groupInspect security groups:
aws ec2 describe-security-groups \
--group-ids <security-group-id>🚨 Common Interview Trap
Do not confuse a security group’s stateful behaviour with a network ACL’s stateless behaviour.
Also, opening database ports to 0.0.0.0/0 just to resolve a connection issue is not acceptable troubleshooting.
🎯 Candidate-Style Answer
“Security groups provide stateful, resource-level traffic controls, while network ACLs provide stateless subnet-level controls. I generally use security groups to define application communication paths and network ACLs for additional subnet-level restrictions where required.”
🧠 Memory Trick
Security group = Stateful. Network ACL = Stateless.
Question 4: How Do You Secure an S3 Bucket?
🧠 Simple Concept
Amazon S3 is object storage used for application assets, logs, backups, reports and data archives.
Securing a bucket means controlling who can access objects, protecting data and auditing activity.
❓ Why Do We Need It?
Misconfigured permissions can expose confidential files or allow unauthorised modification or deletion.
⚙️ How Does It Work?
Use multiple layers of protection:
Enable S3 Block Public Access unless public access is explicitly required.
Apply least-privilege IAM and bucket policies.
Configure encryption at rest and TLS in transit.
Enable versioning where recovery is needed.
Monitor access and configure appropriate audit logging.
Use lifecycle policies for retention and storage-cost management.
🏢 Production Example
An application uploads reports to a private S3 bucket. Its IAM role can write only to a specific prefix, while an authorised reporting service can read the required objects.
No permanent access key needs to be embedded in the application source code.
💻 Command / Configuration
Check public-access-block settings:
aws s3api get-public-access-block \
--bucket <bucket-name>Example bucket-level configuration:
{
"BlockPublicAcls": true,
"IgnorePublicAcls": true,
"BlockPublicPolicy": true,
"RestrictPublicBuckets": true
}These settings should be applied using the appropriate S3 API or CLI command and reviewed against the application’s access requirements.
🚨 Common Interview Trap
Encryption does not replace access control. A bucket can be encrypted and still be improperly exposed.
🎯 Candidate-Style Answer
“I secure S3 using Block Public Access, least-privilege IAM and bucket policies, encryption, TLS and appropriate logging. I also review versioning, retention and lifecycle requirements, and grant access only to authorised identities.”
🧠 Memory Trick
Block, Restrict, Encrypt, Monitor.
Question 5: What Is the Difference Between an Internet Gateway and a NAT Gateway?
🧠 Simple Concept
An Internet Gateway provides a path between a VPC and the internet when the routing and addressing configuration allows it.
A NAT Gateway enables private-subnet resources to initiate outbound connections without allowing unsolicited inbound internet connections to those resources.
❓ Why Do We Need It?
Public-facing components may need internet connectivity, while private application servers and databases should generally have more restricted exposure.
⚙️ How Does It Work?
Public subnet routes eligible internet-bound traffic through an Internet Gateway.
A private subnet can route outbound IPv4 internet traffic through a NAT Gateway.
Route tables determine which path traffic follows.
🏢 Production Example
An ALB is deployed in public subnets. Application instances run in private subnets and use a NAT Gateway when they need to download updates.
The database remains in private subnets with no direct internet route.
💻 Command / Configuration
Inspect VPC route tables:
aws ec2 describe-route-tables \
--filters Name=vpc-id,Values=<vpc-id>Typical routing concept:
Public subnet:
0.0.0.0/0 -> Internet Gateway
Private subnet:
0.0.0.0/0 -> NAT GatewayThe exact routes depend on the architecture. NAT Gateway placement, availability and cost also require consideration.
🚨 Common Interview Trap
A NAT Gateway does not make a private instance publicly addressable. It provides outbound connectivity, not general inbound access.
🎯 Candidate-Style Answer
“An Internet Gateway provides internet connectivity for appropriately routed public resources. A NAT Gateway allows private-subnet resources to initiate outbound IPv4 internet connections without exposing them directly to unsolicited inbound connections. I design routing according to the security requirements of each subnet.”
🧠 Memory Trick
IGW = Public internet path. NAT = Private outbound path.
Question 6: How Does Route 53 Failover Routing Work?
🧠 Simple Concept
Amazon Route 53 is a DNS service that can direct users to endpoints using routing policies.
Failover routing uses primary and secondary records to support DNS-based endpoint failover.
❓ Why Do We Need It?
If a primary application endpoint becomes unavailable, DNS failover can help direct new DNS responses towards a secondary endpoint.
⚙️ How Does It Work?
Configure primary and secondary records.
Configure suitable health checks where supported by the architecture.
Associate the appropriate failover policy.
Verify the primary and secondary endpoints.
Test failover and recovery.
🏢 Production Example
An application has a primary endpoint in one AWS Region and a standby endpoint in another. When the configured health check detects that the primary endpoint is unhealthy, Route 53 can return the secondary endpoint according to the failover configuration.
💻 Command / Configuration
Inspect DNS records:
aws route53 list-resource-record-sets \
--hosted-zone-id <hosted-zone-id>Validate DNS resolution:
dig example.com🚨 Common Interview Trap
DNS failover does not guarantee instant recovery. DNS caching, TTLs, application connections, data replication and secondary-environment readiness all affect the recovery time.
🎯 Candidate-Style Answer
“I configure Route 53 failover records with suitable health checks and primary and secondary endpoints. I also test DNS behaviour, replication, application readiness and recovery procedures because DNS configuration alone does not guarantee disaster recovery.”
🧠 Memory Trick
Primary fails, secondary responds, recovery must be tested.
Question 7: What Are the Different EBS Volume Types?
🧠 Simple Concept
Amazon Elastic Block Store provides persistent block storage for EC2 workloads.
Different volume types suit different performance and cost requirements.
❓ Why Do We Need It?
A general application server, high-performance database and large sequential data-processing workload may need different storage characteristics.
⚙️ How Does It Work?
Common volume types include:
gp3: General-purpose SSD for many application workloads.
io2: Provisioned IOPS SSD for demanding I/O workloads.
st1: Throughput-optimised HDD for suitable sequential workloads.
sc1: Cold HDD for suitable infrequently accessed workloads.
🏢 Production Example
A typical web application may use gp3. A database with demanding IOPS requirements may need io2, while a large sequential processing workload may suit a throughput-optimised HDD.
💻 Command / Configuration
Inspect EC2 volumes:
aws ec2 describe-volumes \
--filters Name=volume-type,Values=gp3,io2Example Terraform configuration:
resource "aws_ebs_volume" "app_data" {
availability_zone = "ap-south-1a"
size = 50
type = "gp3"
encrypted = true
}The Availability Zone must be compatible with the intended EC2 attachment.
🚨 Common Interview Trap
Do not choose storage based on capacity alone. IOPS, throughput, latency, durability and cost all matter.
🎯 Candidate-Style Answer
“I choose an EBS volume according to the workload’s IOPS, throughput, latency and cost requirements. I monitor actual performance and validate the volume configuration rather than selecting a type simply because it is the default.”
🧠 Memory Trick
Capacity + IOPS + Throughput + Cost.
Question 8: Why Prefer IAM Roles Over IAM Users for Applications?
🧠 Simple Concept
IAM roles provide temporary credentials to authorised AWS workloads through supported identity mechanisms.
❓ Why Do We Need It?
Long-lived access keys can be exposed through source code, build logs, configuration files or developer machines.
Temporary credentials reduce the need to distribute and manage permanent secrets.
⚙️ How Does It Work?
Attach an IAM role to an EC2 instance.
Use supported workload identity mechanisms for containers.
Define least-privilege permissions.
Restrict the role’s trust policy.
Audit permissions and access.
For EKS, appropriate options include EKS Pod Identity or IAM Roles for Service Accounts, depending on the cluster setup.
🏢 Production Example
An EC2 application needs to read objects from a particular S3 bucket. The instance receives temporary credentials through its IAM role instead of storing an AWS access key in an environment file.
💻 Command / Configuration
Inspect an IAM role:
aws iam get-role \
--role-name <role-name>Example policy concept:
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::example-bucket/reports/*"
}This policy fragment is illustrative. It must be attached through the appropriate IAM policy configuration, and the role must be trusted by the intended workload.
🚨 Common Interview Trap
Creating a role is not enough. The trust policy and permissions policy must both be correct.
🎯 Candidate-Style Answer
“I prefer IAM roles for AWS workloads because they provide temporary credentials and reduce reliance on long-lived access keys. I apply least privilege, restrict trust relationships and audit permissions regularly.”
🧠 Memory Trick
Role = Temporary credentials + least privilege.
SECTION 2: CI/CD and Continuous Delivery 🔄
Question 9: What Are the Stages of a CI/CD Pipeline?
🧠 Simple Concept
A CI/CD pipeline automates the process of validating, packaging and deploying software changes.
❓ Why Do We Need It?
Manual deployments are repetitive and error-prone. Automation improves consistency, traceability and release speed.
⚙️ How Does It Work?
A typical pipeline includes:
Source checkout.
Build and dependency resolution.
Unit and integration testing.
Static code analysis.
Security and dependency scanning.
Container image creation.
Image publication.
Staging deployment.
Verification and approval, where required.
Production deployment and monitoring.
🏢 Production Example
A developer merges code into the main branch. Jenkins runs tests and security scans, builds a Docker image, publishes it to Amazon ECR and deploys it to a staging environment.
After verification and any required approval, the release is promoted to production.
💻 Command / Configuration
Example pipeline stages:
pipeline {
agent any
stages {
stage('Test') {
steps {
sh 'make test'
}
}
stage('Build') {
steps {
sh 'docker build -t my-app:latest .'
}
}
stage('Security Scan') {
steps {
sh 'trivy image my-app:latest'
}
}
}
}This is a simplified example. Production pipelines should use controlled image tags, secure credentials, appropriate scan-failure policies and a reliable publishing and deployment process.
🚨 Common Interview Trap
A pipeline that only builds and deploys code is not automatically a safe delivery pipeline. Testing, security, deployment verification and rollback are also important.
🎯 Candidate-Style Answer
“I design CI/CD pipelines to automate testing, security scanning, packaging and deployment. I use immutable artifacts, secure credentials, environment-specific configuration, deployment verification and a documented rollback strategy.”
🧠 Memory Trick
Code → Test → Scan → Build → Deploy → Verify.
Question 10: What Is the Difference Between Blue-Green and Canary Deployment?
🧠 Simple Concept
Both approaches reduce release risk, but they introduce a new application version differently.
Blue-green: Switch traffic between two environments.
Canary: Gradually increase traffic to the new version.
❓ Why Do We Need It?
Deploying a new version to every user at once can expose the entire application to a faulty release.
Controlled deployment strategies help teams detect problems before all traffic is affected.
⚙️ How Does It Work?
Blue-green deployment prepares a second environment, tests it and switches traffic when ready.
Canary deployment initially directs a small percentage of traffic to the new version and expands the rollout when health metrics remain acceptable.
🏢 Production Example
For a web application, the team deploys the new version to a green environment and verifies it before switching traffic.
For a high-traffic API, the team might initially route 5% of traffic to the new version and monitor latency and error rates before increasing the percentage.
💻 Command / Configuration
Kubernetes rollout status:
kubectl rollout status deployment/my-app
kubectl get deployment my-app
kubectl get podsThese commands help verify deployment progress. Implementing blue-green or canary traffic shifting requires suitable deployment and routing configuration; the commands alone do not create either strategy.
🚨 Common Interview Trap
Rollback can be complicated by database schema changes, background jobs and external side effects. Switching traffic back does not reverse every data change.
🎯 Candidate-Style Answer
“Blue-green deployment maintains two environments and switches traffic between them. Canary deployment exposes the new version to a small percentage of traffic and increases it gradually based on health metrics. I choose the strategy according to risk, observability, infrastructure cost and rollback requirements.”
🧠 Memory Trick
Blue-green = Switch. Canary = Gradually expose.
Question 11: How Do You Perform a Deployment Rollback?
🧠 Simple Concept
A rollback restores a previously working application version or configuration when a release causes problems.
❓ Why Do We Need It?
Even well-tested deployments can fail because of production traffic, configuration differences or unexpected dependencies.
A rollback plan reduces the time spent operating a faulty version.
⚙️ How Does It Work?
Detect a problem through metrics, alerts or health checks.
Pause further rollout.
Determine whether the new release caused the issue.
Restore the previous known-good version.
Verify service recovery.
Investigate the root cause.
Document corrective actions.
🏢 Production Example
A release causes HTTP 5xx errors to increase. The team pauses the rollout, restores the previous container image and verifies application health before investigating the faulty change.
💻 Command / Configuration
For a Kubernetes Deployment:
kubectl rollout status deployment/my-app
kubectl rollout history deployment/my-app
kubectl rollout undo deployment/my-appRun the commands against the correct cluster, namespace and deployment. Confirm that the previous ReplicaSet is still available and that the rollback is compatible with database and dependency changes.
🚨 Common Interview Trap
Rollback is not simply running one command. You must verify recovery, assess database compatibility and communicate the incident appropriately.
🎯 Candidate-Style Answer
“I use deployment health checks and release metrics to detect failures, pause further rollout and restore the last known-good version. After recovery, I verify application functionality, investigate the root cause and improve the pipeline to prevent recurrence.”
🧠 Memory Trick
Detect → Stop → Roll Back → Verify → Learn.
Question 12: How Do You Deploy Across Multiple Environments?
🧠 Simple Concept
Applications move through environments such as development, testing, staging and production.
The goal is to promote a tested artifact while managing environment-specific configuration and permissions separately.
❓ Why Do We Need It?
Different environments have different resources, credentials and access requirements. Inconsistent deployment processes create configuration drift and unexpected production failures.
⚙️ How Does It Work?
Build the artifact once.
Promote the same immutable artifact.
Keep secrets outside source code.
Separate environment configuration.
Use suitable approval gates.
Verify deployments after release.
Maintain auditability and rollback capability.
🏢 Production Example
A container image built from a specific commit is published to a registry. The same image digest is deployed to staging and then production after verification.
Environment-specific endpoints and settings are supplied separately.
💻 Command / Configuration
Example image promotion concept:
docker build -t my-app:1.2.0 .
docker tag my-app:1.2.0 \
<registry>/my-app:1.2.0
docker push <registry>/my-app:1.2.0In production, use controlled version tags and preferably record the image digest to ensure the same artifact is promoted across environments.
🚨 Common Interview Trap
Do not rebuild different images independently for staging and production if the goal is to promote the exact same tested artifact.
🎯 Candidate-Style Answer
“I separate environment configuration and permissions while promoting the same immutable artifact through the pipeline. I use automated testing, approvals where required, secure secret management and post-deployment verification to reduce configuration drift and deployment risk.”
🧠 Memory Trick
Build once. Promote safely. Verify everywhere.
SECTION 3: Terraform and Infrastructure as Code 🏗️
Question 13: What Is a Terraform State File?
🧠 Simple Concept
Terraform state records the relationship between Terraform configuration and the infrastructure Terraform manages.
❓ Why Do We Need It?
Terraform uses state to understand which resources it manages and to calculate changes during future plans and applies.
⚙️ How Does It Work?
Terraform compares the desired configuration with the tracked state and the observed infrastructure to determine the changes needed.
State may contain sensitive information, so it must be protected.
🏢 Production Example
A team manages a VPC, subnets, security groups and an EKS cluster through Terraform. State allows Terraform to track those resources and plan subsequent changes.
If the state is lost or incorrectly modified, infrastructure management can become more complicated and risky.
💻 Command / Configuration
Useful commands:
terraform init
terraform plan
terraform state list
terraform state show <resource-address>Use terraform state show only when you are authorised to access the state information. Avoid exposing state output in public logs or shared screenshots.
🚨 Common Interview Trap
Terraform state is not merely a backup file. It is part of Terraform’s resource-tracking mechanism and may contain sensitive values.
🎯 Candidate-Style Answer
“Terraform state maps configuration to managed infrastructure and helps Terraform calculate changes. For team environments, I use a remote backend with appropriate access controls, recovery and locking capabilities, and treat the state file as sensitive data.”
🧠 Memory Trick
Configuration = Desired state. State file = Resource tracking.
Question 14: How Do You Manage Terraform Remote State?
🧠 Simple Concept
Remote state stores Terraform state in a shared backend instead of relying on a local file on one engineer’s machine.
❓ Why Do We Need It?
Teams and CI/CD pipelines need a consistent state location. Shared state helps prevent engineers from independently managing different local copies of the same infrastructure state.
⚙️ How Does It Work?
For AWS environments, an S3 backend can store state centrally.
A sound design considers:
IAM access restrictions.
Encryption.
Versioning and recovery.
State locking.
Appropriate separation between environments.
Secure access from CI/CD pipelines.
Current Terraform versions support S3-native state locking using the use_lockfile backend option. Older DynamoDB-based locking configurations are deprecated for this purpose in current Terraform guidance.
🏢 Production Example
Multiple engineers manage the same VPC. The team configures a remote S3 backend with restricted access and state locking to reduce the risk of conflicting Terraform operations.
💻 Command / Configuration
Example backend configuration:
terraform {
backend "s3" {
bucket = "company-terraform-state"
key = "production/network/terraform.tfstate"
region = "ap-south-1"
encrypt = true
use_lockfile = true
}
}The bucket must exist before Terraform initialises this backend. Configure appropriate bucket permissions, versioning and recovery controls separately.
Then initialise:
terraform init
terraform plan🚨 Common Interview Trap
Remote state alone does not guarantee safety. Incorrect IAM permissions, missing recovery controls and poorly separated environments can still create serious problems.
🎯 Candidate-Style Answer
“I use a remote backend for shared Terraform state, restrict access through IAM, enable encryption and versioning, and configure supported state locking. This improves collaboration and recovery while reducing the risk of conflicting infrastructure changes.”
🧠 Memory Trick
Remote backend + access control + locking + recovery.
Question 15: Explain Terraform Modules and Workspaces.
🧠 Simple Concept
A Terraform module is a reusable collection of Terraform configuration.
A Terraform workspace provides a separate state instance for the same configuration.
❓ Why Do We Need It?
Modules reduce duplication and standardise infrastructure patterns. Workspaces can help manage multiple instances of a configuration where that model is appropriate.
⚙️ How Does It Work?
A root module can call reusable child modules for components such as VPCs, EKS clusters and IAM roles.
Workspaces maintain separate state instances, but they do not automatically provide complete isolation of credentials, configuration, access controls or infrastructure.
🏢 Production Example
A platform team creates reusable modules for VPC networking and EKS. Application teams use those modules with environment-specific inputs.
Production and development use suitable state separation and access controls instead of relying on workspace names alone for security.
💻 Command / Configuration
Example module usage:
module "network" {
source = "./modules/vpc"
vpc_cidr = "10.0.0.0/16"
env_name = "dev"
}Workspace commands:
terraform workspace list
terraform workspace new dev
terraform workspace select devThe module inputs must match the variables defined by the actual module. Use workspaces only where their state-separation model fits the architecture.
🚨 Common Interview Trap
Do not claim that separate workspaces automatically create separate AWS accounts, permissions or security boundaries.
For production environments with different ownership, access or lifecycle requirements, separate root configurations and backend state arrangements may be more appropriate.
🎯 Candidate-Style Answer
“Terraform modules package reusable infrastructure configuration, while workspaces provide separate state instances for a configuration. I use modules to standardise infrastructure and choose state separation based on environment boundaries, security, ownership and lifecycle requirements.”
🧠 Memory Trick
Module = Reuse. Workspace = Separate state instance.
Final Interview Preparation Checklist 🎯
Before your interview, practise explaining each topic without reading your notes.
For every question, make sure you can:
🧠 Explain the concept in simple language.
❓ Describe the problem it solves.
⚙️ Explain the technical workflow.
🏢 Give a realistic production example.
💻 Write or interpret a relevant command or configuration.
🚨 Identify a common mistake or limitation.
🎯 Deliver a clear candidate-style answer.
🧠 Recall the main idea using a memory trick.
Most importantly, connect the topics. For example, an application deployed through CI/CD may run behind an ALB, scale through an Auto Scaling group, access S3 through an IAM role and use Terraform-managed infrastructure.
That is the level of understanding that turns separate service definitions into a complete DevOps architecture.
Final Thoughts 🚀
AWS DevOps interviews are not just about knowing service names. They test whether you can connect architecture, automation, security, troubleshooting and recovery.
Use these 15 questions as a foundation. Practise the commands in a test environment, understand why each configuration exists, and be ready to explain the trade-offs.
Learn the concept. Practise the scenario. Explain the decision.
That is how interview preparation becomes practical engineering knowledge.
Disclaimer: This article is for educational and interview-preparation purposes. The commands and configurations are examples and should be adapted and tested before use in production.
Hashtags
#AWS #AWSDevOps #DevOps #DevOpsEngineer #AWSInterview #TCS #Terraform #CICD #Jenkins #CloudComputing #InfrastructureAsCode #CloudSecurity #Automation #SRE #Kubernetes
Follow Me
If you enjoyed this article and would like more practical DevOps, Cloud, Kubernetes, AWS, Terraform, CI/CD, and Software Engineering content, feel free to connect with me on LinkedIn.
Arvind Verma is free today. But if you enjoyed this post, you can tell Arvind Verma that their writing is valuable by pledging a future subscription. You won't be charged unless they enable payments.
© 2026 Arvind Verma
548 Market Street PMB 72296, San Francisco, CA 94104