AWS Interview Questions for Freshers

“I got into cloud during my third year when our college project needed to be online for the demo, and I ended up being the one who put it on AWS. I liked that I could build a whole working setup from a laptop, and break it and rebuild it the same afternoon. Since then I've done a few things on my own account: hosted a static portfolio on S3, run a small Flask app on EC2 behind a security group I set up myself, and built a tiny serverless API with Lambda. I also studied for a foundational cloud certification, but honestly the labs taught me more than the exam. In this role I want to learn how real teams run production systems, especially networking and automation, which I've only touched in labs.”

“Cloud computing means renting servers, storage and databases over the internet instead of buying and running your own hardware. You get them in minutes, pay for what you use, and give them back when you're done. The three models are about how much the provider manages for you. With IaaS, infrastructure as a service, you get raw building blocks like virtual machines and networks, and you manage the operating system and everything on top. EC2 is the classic example. With PaaS, platform as a service, you hand over your code and the platform runs it, so you don't patch servers. Elastic Beanstalk or Lambda fit there. SaaS is finished software you just log into and use, like web email. The further up you go, the less control you have but the less work you do.”

“A Region is a geographic area where AWS has a cluster of data centres, and each Region is independent of the others. Inside a Region there are several Availability Zones. Each zone is one or more data centres with separate power, cooling and networking, placed far enough apart that a fire or flood in one shouldn't hit the others, but close enough that the links between them are very fast. That's why you put copies of your app in two or more zones. Edge locations are different: they're many smaller sites spread around the world that CloudFront and Route 53 use to cache content and answer DNS close to the user. When I pick a Region I think about where my users are, which services are available there, and any rules about where data must be stored.”

“Vertical scaling means making one server bigger, like moving an EC2 instance to a type with more CPU and memory. It's simple, but there's a ceiling, and on EC2 you usually have to stop the instance to change its type, so there's downtime. Horizontal scaling means adding more servers and spreading traffic across them with a load balancer. There's no hard ceiling, and if one server dies the others keep going. The catch is the app should be stateless, so things like login sessions live in a shared store rather than on one server's disk. Elasticity is the cloud part: capacity grows when traffic rises and shrinks when it drops, automatically, so you're not paying for idle machines at night.”

“The idea is that AWS secures the cloud itself and I secure what I put in it. AWS looks after the physical data centres, the hardware, the network, and the layer that runs virtual machines. On EC2, everything from the operating system up is mine: patching the OS, which ports I open in the security group, who gets IAM access, encrypting data, and the app code. If I leave SSH open to the whole internet with a weak password, that's on me, not AWS. The line moves with the service. With Lambda, AWS patches the operating system and runtime, so I only own my code, its permissions and the data. With S3, AWS runs the storage, but whether a bucket is public is still my setting.”

“The root user can do anything in the account, including closing it, and you can't limit it with IAM policies, so I use it as little as possible. First I give it a long unique password and turn on MFA. I make sure it has no access keys. Then I create a separate identity for daily work, either an admin user in IAM Identity Center or an IAM user with admin rights and its own MFA, and I log in with that from then on. Next I set up a budget with an email alert so a forgotten instance can't surprise me. I'd also make sure CloudTrail is recording, so there's a log of who did what. After that I only log in as root for the few tasks that truly need it.”

“There are two statements, both Allow. The first lets them describe instances on any resource, so they can see every instance in the account in the console or CLI. The second lets them start and stop instances, but the condition says only when the instance has a tag Env with the value dev. So they can start and stop dev machines, but if they try to stop a prod instance, or one with no tag at all, it's refused. They can't terminate anything, launch new instances or change tags, because those actions aren't allowed anywhere, and in IAM anything not allowed is denied by default. That last part matters: since they can't create tags, they can't tag a prod box as dev to get around the rule.”

“First I check I'm in the right Region. Then I pick an AMI, say Amazon Linux, and a small general-purpose instance type. I create a key pair and download the private key file, because AWS won't show it again. For the network I use a public subnet with auto-assign public IP turned on, and a security group that allows port 22 from my own IP only, not from everywhere. Storage defaults are fine for a test. After it's running, I copy the public DNS name, lock down the key file's permissions, and SSH in with the right user name. For Amazon Linux it's ec2-user, for Ubuntu it's ubuntu. I've also used EC2 Instance Connect from the console when I didn't have my key with me.”

“User data is a script you give EC2 when you launch an instance. On Linux, cloud-init runs it once on the first boot, as root, so there's no need for sudo. It's handy for installing packages and starting services, so every instance comes up ready without anyone logging in. My script installs the Apache web server, starts it and enables it so it comes back after a reboot, and writes a simple page. For this to work in a browser, the security group needs port 80 open. If the page doesn't load, I SSH in and read the cloud-init output log, which shows each command and any error. In a group project I used this so any teammate could launch an identical server in a couple of minutes.”

“When you stop an EBS-backed instance, the EBS volumes stay, so the OS and my files are still there when it starts. Anything on an instance store disk is lost. The private IP inside the VPC stays the same. The public IP that AWS auto-assigned is released, and I get a new one on start, which is why my SSH command or a bookmarked link suddenly breaks. If I need a fixed public address, I attach an Elastic IP, which stays with the instance across stops. Better still for a real app is putting it behind a load balancer or a DNS name so the address doesn't matter. The instance may also land on different hardware after a start, which is actually a simple fix when the underlying host has a problem.”

“A timeout tells me my packets aren't reaching the instance at all, so it's a network problem, not a key problem. If it said 'permission denied', I'd look at the key file and user name instead. First I check the instance is running and its status checks pass, and that it actually has a public IP. Then the security group: is there an inbound rule for port 22 from my current IP? On college Wi-Fi my IP changes, and that's bitten me before. Next, the subnet's route table needs a route to an internet gateway, otherwise it's a private subnet. Then the network ACL, which might block the traffic. Last, my own network: some campus networks block port 22, so I'd try from my phone's hotspot.”

“EBS is a block storage volume, like a hard disk plugged into the instance over the network. It lives in one Availability Zone, keeps its data when you stop the instance, and you can take snapshots of it. It's what the OS and a database on EC2 normally sit on. Instance store is a disk physically on the host machine. It's very fast, and it survives a reboot, but the data is gone when you stop or terminate the instance, so I'd only use it for cache or scratch files. S3 is not a disk at all. You store whole objects through an API, it scales without limits you'd notice, and it's copied across zones. I'd use it for uploads, backups, logs and static website files.”

“I'd create a bucket, upload my HTML, CSS and images, and turn on static website hosting with index.html as the index document and an error page. The quick way to make it visible is to turn off Block Public Access for that one bucket and add a bucket policy that allows anyone to read objects. That gives me an S3 website URL, but it's HTTP only. For HTTPS and a custom domain, I'd put CloudFront in front, attach a free certificate from Certificate Manager, and point my domain at CloudFront using Route 53. The cleaner setup keeps the bucket fully private and lets only CloudFront read from it. That's what I did for my portfolio, and it also made the site load faster far from the bucket's Region.”

“With versioning on, every time you upload an object with the same key, S3 keeps the old one as a previous version instead of replacing it. When someone deletes a file normally, S3 doesn't really delete it. It adds a delete marker on top, so the file looks gone but the older versions are still there. To get it back, I list the versions, find the delete marker, and delete that marker, and the last real version becomes current again. Or I can copy an older version back over it. Two things to remember: once you turn versioning on you can only suspend it, not fully turn it off, and old versions still take up storage, so I'd add a lifecycle rule to expire them after a while.”

“First the CLI needs credentials. aws configure asks for an access key, secret key and default Region and saves them in a file in my home folder. If my organization uses single sign-on I'd use aws configure sso instead, so there's no long-lived key on my laptop. Then mb makes a bucket, and the name has to be unique across all AWS accounts, not just mine. cp uploads a single file, and the folder is just part of the object key, a prefix. ls lists what's under that prefix. sync compares my local folder with the bucket and only uploads files that are new or changed, which is how I deployed my front end build in my project.”

“CloudFront keeps copies of my files at edge locations near users, so they don't all travel back to the bucket. Each copy is kept for a cache time, set by the cache policy or the Cache-Control headers on the file. Until that time runs out, the edge keeps serving the copy it has, which is why users see the old file. The quick fix is to create an invalidation for that path, which tells the edges to drop their copy and fetch a fresh one. The better long-term fix is to put a version or a hash in the file name, like app.3f9c.js, and update the HTML to point to it. Then a new file is a new URL, so there's nothing stale to clear, and I can keep long cache times.”

“The /16 means the first 16 bits, the 10.0 part, are fixed, and the remaining 16 bits are free, so the VPC has 65,536 addresses, from 10.0.0.0 to 10.0.255.255. Subnets are smaller ranges inside it, and each subnet lives in one Availability Zone. A simple plan is /24 subnets, which gives 256 addresses each: say 10.0.1.0/24 and 10.0.2.0/24 as public subnets in two zones, and 10.0.11.0/24 and 10.0.12.0/24 as private ones. Subnets can't overlap. One thing that surprises people is that AWS reserves five addresses in every subnet, the first four and the last one, so a /24 gives 251 usable addresses. I'd also leave space unused so I can add subnets later without redoing everything.”

“Before building anything I set up a budget in AWS Budgets with an email alert at a small amount, and I keep an eye on how much of my free usage is left. Then I build habits. When I finish a lab, I terminate instances rather than just stopping them, because a stopped instance still keeps its EBS volume, and that's billed. I check for the things people forget: unattached Elastic IPs, NAT gateways, load balancers, old snapshots and idle databases. I tag everything with the project name so I can see what belongs to what. And every few days I open the billing page and look by service and by Region, because the classic mistake is launching something in a different Region and never seeing it in the console again.”

“CloudTrail records the actions taken in the account, meaning API calls. Every time someone or something creates, changes or deletes a resource, it logs who it was, when, from which IP and whether it worked. So if an instance disappeared or a security group rule changed, CloudTrail tells me who did it. CloudWatch is about health and performance. It collects metrics like CPU or request counts, stores application logs, and runs alarms that alert me when a number crosses a line. If my app is slow or throwing errors, I open CloudWatch. A simple way I remember it: CloudTrail is the security camera, CloudWatch is the dashboard. They also work together, because you can send CloudTrail logs into CloudWatch and alarm on things like a root login.”

“Running MySQL on EC2 means I'm the database admin: installing it, patching the OS and the engine, setting up backups and testing restores, and handling failover if the server dies. RDS does most of that for me. It sets up the database in a few clicks, applies patches in a maintenance window I choose, takes automatic backups so I can restore to a point in time, and can keep a standby in another zone for failover. What I still own is the schema, my queries and indexes, database users, and the security group that decides who can connect. The trade-off is less control: I can't SSH into the host or install whatever I like on it. For a college project or a small team, that trade is almost always worth it.”

“With a REST API in API Gateway using proxy integration, the whole HTTP request arrives as the event: the path, headers, query string and body. My handler reads the name from the query string, and if there are no query parameters that field comes through as None, so I default it to an empty dictionary first. The response must be a dictionary with a statusCode, headers and a body, and the body has to be a string, which is why I use json.dumps. Returning a plain dictionary as the body is the classic mistake, and API Gateway answers with a 502 error. The context object gives details like the request ID and the time left, which I'd use for logging. To test it, I'd call the endpoint with a name in the query string.”

“SQS is a queue. A producer drops messages in, they wait there, and a consumer pulls them and deletes each one after processing. If processing fails, the message becomes visible again after a timeout and gets retried. It's great for smoothing out spikes, like resizing images one at a time. SNS is publish-subscribe. You publish to a topic, and SNS pushes a copy to every subscriber straight away: a Lambda function, an email address, an HTTP endpoint or an SQS queue. SNS doesn't hold messages for a consumer to pull later the way a queue does. They combine in fan-out: when an order is placed, I publish once to an SNS topic, and it delivers to separate queues for billing, email and stock, so each one works at its own pace and retries on its own.”

“My final-year project was an attendance app for our department. The front end was a React build hosted on S3 with CloudFront in front. The API was API Gateway calling Lambda functions in Python, and the data sat in DynamoDB, because our access was simple: look up a student, write an attendance record. I chose serverless mostly because nobody wanted to look after a server during exams, and with almost no traffic at night we weren't paying for idle machines. I wrote the IAM roles so each function could touch only its own table. Looking back, I'd define it all in a template instead of clicking in the console, because rebuilding it for the demo took us a whole evening.”

“In our final-year group of four, we started with one person's account and, honestly, everyone was logging in with the same root password. When one teammate launched a big instance in the wrong Region and forgot it, we only found out from an email. I suggested we fix it. I created a separate login for each person in a group with the permissions we needed for the project, turned on MFA for everyone, and locked the root user away. I added a budget alert that emailed all four of us, and we agreed to tag every resource with the owner's name. After that, when something was left running, we could see whose it was in seconds. The lesson I took is to set up access properly on day one, not after the scare.”