AWS Interview Questions: Exploring Key Services, Concepts, and Best Practices

Q. Name 5 aws services you have used and what's the use cases?

1. Amazon EC2 (Elastic Compute Cloud)

• Serves as AWS's primary compute service providing scalable virtual machines in the cloud

• Key Use Cases:

  • Hosting production web applications and APIs

  • Running backend services and microservices

  • Supporting computational workloads and batch processing

  • Development and testing environments

• Major Advantages:

  • Flexible scaling capabilities - both vertical (instance size) and horizontal (number of instances)

  • Wide variety of instance types optimized for specific workloads (compute, memory, GPU, etc.)

  • Pay-per-use pricing model with various payment options (on-demand, reserved, spot instances)

  • Deep integration with auto-scaling groups for automatic capacity adjustment

  • Support for both Windows and Linux operating systems

2. Amazon RDS (Relational Database Service)

• Provides managed relational databases in the cloud with automated administration

• Key Use Cases:

  • Production database deployments requiring high availability

  • Web application databases requiring consistent performance

  • Business applications needing transactional databases

  • Applications requiring automated backup and recovery

• Major Advantages:

  • Automated database administration tasks (backups, patches, updates)

  • Built-in high availability with Multi-AZ deployments

  • Automated failure detection and recovery

  • Support for multiple database engines (MySQL, PostgreSQL, Oracle, SQL Server)

  • Point-in-time recovery and automated backups

3. Amazon S3 (Simple Storage Service)

• Offers scalable object storage with high durability and availability

• Key Use Cases:

  • Static website hosting

  • Application asset and media storage

  • Data backup and archiving

  • Data lakes for big data analytics

  • Content distribution with CloudFront integration

• Major Advantages:

  • Virtually unlimited storage capacity

  • 99.999999999% durability guarantee

  • Comprehensive security features (encryption, access control)

  • Lifecycle management policies for cost optimization

  • Integration with nearly every AWS service

4. Amazon ECS (Elastic Container Service)

• Manages containerized applications with full orchestration capabilities

• Key Use Cases:

  • Microservices architecture deployment

  • Long-running containerized applications

  • Batch processing workloads

  • CI/CD pipeline integration

• Major Advantages:

  • Fully managed container orchestration

  • Seamless integration with other AWS services

  • Built-in auto-scaling capabilities

  • Support for both EC2 and Fargate launch types

  • Simplified container deployment and management

5. Amazon CloudWatch

• Provides comprehensive monitoring and observability solutions

• Key Use Cases:

  • Application and infrastructure monitoring

  • Resource utilization tracking

  • Log aggregation and analysis

  • Performance monitoring and troubleshooting

  • Automated alerting and notification

• Major Advantages:

  • Centralized monitoring solution for all AWS services

  • Custom metrics and dashboards creation

  • Automated alerting based on thresholds

  • Log insights for quick troubleshooting

  • Integration with AWS Lambda for automated responses to events

  • Real-time monitoring and metrics with detailed granularity

Q. What are the tools used to send logs to the cloud environment?

Here are the key tools and methods used to send logs to AWS cloud environment:

AWS Native Tools:

• CloudWatch Logs Agent

  • Traditional agent designed specifically for AWS

  • Collects system, application, and custom logs

  • Built-in integration with CloudWatch Logs

  • Best suited for EC2 instances running Linux or Windows

• CloudWatch Unified Agent

  • Next-generation agent that replaces the older CloudWatch Logs Agent

  • Collects additional metrics along with logs

  • Supports structured logs in JSON format

  • More configurable and feature-rich than the standard logs agent

  • Can collect system-level metrics that aren't available through default CloudWatch metrics

Third-Party Tools & Services:

• Fluentd

  • Open-source data collector that can forward logs to CloudWatch

  • Highly flexible with extensive plugin ecosystem

  • Can transform and route logs to multiple destinations

  • Good for containerized environments

• Logstash

  • Part of the ELK stack but can send logs to CloudWatch

  • Rich processing capabilities for log transformation

  • Supports multiple input and output plugins

  • Good for complex log processing requirements

• Vector

  • Modern, high-performance log collector

  • Written in Rust for better performance

  • Can send logs to CloudWatch and other destinations

  • Good for high-throughput environments

Container-Specific Solutions:

• FireLens

  • AWS-native log router for ECS and EKS

  • Based on Fluentd/Fluent Bit

  • Can route logs to multiple AWS services

  • Supports custom log parsing and filtering

• AWS for Fluent Bit

  • Lightweight alternative to Fluentd

  • Officially supported by AWS

  • Ideal for containerized workloads

  • Good performance with low resource usage

SDK & API Integration:

• AWS SDK

  • Direct programmatic log submission

  • Available for multiple programming languages

  • Good for custom application logging

  • Supports batching and retry mechanisms

• CloudWatch Logs API

  • RESTful API for log submission

  • Can be used with any HTTP client

  • Supports both synchronous and asynchronous operations

  • Good for custom integration scenarios

These tools offer different advantages depending on your specific use case:

• For EC2 instances: CloudWatch Unified Agent is typically the best choice

• For containers: FireLens or Fluent Bit are recommended

• For complex log processing: Fluentd or Logstash might be better

• For high-performance requirements: Vector or Fluent Bit are good options

• For custom applications: Direct SDK integration might be most appropriate

Q. What are IAM Roles? How do you create/manage them?

IAM (Identity and Access Management) Roles are AWS security identities that define a set of permissions for making AWS service requests. Let me break this down comprehensively:

What are IAM Roles:

• A role is an AWS identity with specific permission policies that determine what the identity can and cannot do in AWS

• Unlike IAM users, roles don't have long-term credentials (passwords or access keys)

• Roles can be assumed by authorized entities (users, applications, or AWS services)

• They provide temporary security credentials for role sessions

Common Use Cases for IAM Roles:

• EC2 instance access to AWS services

• Cross-account access

• AWS service access to other AWS services

• Federation (allowing external identities to access AWS resources)

• Lambda function execution permissions

• Application access running on ECS/EKS

Creating IAM Roles:

1. Through AWS Management Console:

   • Navigate to IAM service

   • Select "Roles" and click "Create role"

   • Choose the type of trusted entity

   • Attach permission policies

   • Set role name and description

   • Review and create

2. Using AWS CLI:

# Create role
aws iam create-role --role-name MyRole --assume-role-policy-document file://trust-policy.json

# Attach policy
aws iam attach-role-policy --role-name MyRole --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

3. Using AWS CloudFormation:

Resources:
  MyRole:
    Type: 'AWS::IAM::Role'
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ec2.amazonaws.com
            Action: 'sts:AssumeRole'
      ManagedPolicyArns:
        - 'arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess'

Managing IAM Roles:

• Review and Update Permissions:

  • Regularly audit role permissions

  • Follow principle of least privilege

  • Use AWS IAM Access Analyzer

  • Monitor role usage with CloudTrail

• Best Practices:

  • Use AWS managed policies when possible

  • Create roles with minimal permissions

  • Implement role rotation

  • Use tags for better organization

  • Regular security reviews

• Key Components to Manage:

  • Trust Policy (who can assume the role)

  • Permission Policies (what the role can do)

  • Maximum session duration

  • Tags and metadata

Monitoring and Security:

• Enable CloudTrail for role activity logging

• Set up alerts for suspicious role usage

• Implement role boundaries for additional security

• Regular rotation of roles and permissions

• Use AWS Organizations for centralized role management

Common Role Types:

• Service Roles (for AWS services)

• Cross-Account Roles (for multi-account access)

• Application Roles (for application access)

• User Roles (for federation)

• Instance Roles (for EC2 instances)

Q. How to upgrade or downgrade a system with zero downtime?

Zero Downtime solutions

Achieving near-zero downtime during system upgrades or downgrades requires careful planning and execution. Here are some common strategies:

1. Blue-Green Deployment:

• This approach involves creating a completely new identical system (the "green" environment) with the upgraded/downgraded components.

• While the old system (the "blue" environment) continues serving traffic, you thoroughly test the new environment.

• Once satisfied, you switch traffic over to the green environment using a load balancer. Finally, decommission the old blue environment.

2. Rolling Upgrades/Downgrades:

• Here, you update individual components of the system one at a time, minimizing downtime.

• This can be achieved by techniques like deploying new versions behind a load balancer and gradually shifting traffic towards them.

• You can monitor the health of the new components before fully decommissioning the old ones.

3. Canary Deployments:

• Similar to rolling deployments, a canary deployment involves deploying the new version to a small subset of users or servers first.

• This allows you to identify and fix any critical issues before rolling out the update to the entire system.

• If a major problem arises, you can easily rollback the update on the canary instances with minimal impact.

4. Feature Flags:

• This strategy involves deploying new features or functionalities alongside the existing ones but keeping them disabled by default.

• You can then gradually roll out the new features to a percentage of users using feature flags.

• This allows for A/B testing and controlled rollouts, minimizing risks associated with a full system upgrade.

Choosing the Right Approach

The best strategy for your specific scenario depends on factors like:

• System Complexity: Complex systems might benefit more from a blue-green deployment for a cleaner cutover.

• Downtime Tolerance: How much downtime can your users tolerate? Rolling upgrades might be suitable for short disruptions.

• Rollback Strategy: Ensure you have a rollback plan in case of any issues during the upgrade/downgrade process.

Q. What is infrastructure as code and how do you use it?

Infrastructure as Code (IaC) is a practice where infrastructure management and provisioning is handled through machine-readable definition files rather than manual processes or interactive configuration tools. It treats infrastructure configuration like software code, allowing teams to version, test, and deploy infrastructure changes using the same practices they use for application code development.

In practical implementation, IaC tools like Terraform, AWS CloudFormation, or Ansible are used to define infrastructure components in declarative configuration files. For example, with Terraform, you can define an entire AWS infrastructure including VPCs, EC2 instances, security groups, and load balancers in HCL (HashiCorp Configuration Language) files. These files serve as a single source of truth for the infrastructure state, enabling teams to track changes, collaborate effectively, and maintain consistency across different environments. The declarative nature means you specify the desired end state, and the IaC tool determines how to achieve that state, handling the complex dependency management and resource ordering automatically.

One of the key advantages of IaC is its ability to ensure environment consistency and eliminate configuration drift. When infrastructure is managed through code, the same configuration can be reliably deployed across development, staging, and production environments. This significantly reduces the "it works on my machine" problems and makes environment provisioning reproducible and predictable. Additionally, IaC enables infrastructure automation, allowing teams to quickly spin up new environments, implement changes, and recover from disasters, all while maintaining version control and audit trails of infrastructure modifications.

The adoption of IaC also promotes DevOps practices by bringing infrastructure management into the software development lifecycle. Infrastructure changes can be reviewed, tested, and approved just like application code changes. Teams can implement continuous integration and continuous deployment (CI/CD) pipelines that include infrastructure updates, ensuring that infrastructure evolves alongside application code in a controlled and automated manner. This integration of infrastructure management with software development processes leads to faster delivery, reduced errors, and better collaboration between development and operations teams.

Q. What is a load balancer? Give scenarios of each kind of balancer based on your experience.

A load balancer is a device or software that distributes incoming network traffic across multiple servers to manage web application load efficiently. It acts as a traffic cop that sits between users and server groups, routing client requests to ensure no single server becomes overwhelmed.

The main purposes of a load balancer are:

1. High Availability - If one server fails, traffic is automatically directed to other servers

2. Scalability - Easily add or remove servers based on demand

3. Performance - Distribute load to prevent any single server from becoming a bottleneck

4. Reliability - Health checks ensure traffic only goes to healthy servers

Common types of load balancers include:

Application Load Balancer (Layer 7):

• Makes routing decisions based on application-level data like HTTP headers, URL paths

• Best for web applications needing content-based routing

• Example: Routing different types of requests (images, API calls, static content) to specialized servers

Network Load Balancer (Layer 4):

• Works at transport layer routing based on IP address and ports

• Best for extreme performance needs and static IP requirements

• Example: Database clusters, gaming servers needing ultra-low latency

Classic/Traditional Load Balancer:

• Basic round-robin distribution across server pool

• Good for simple web applications without complex routing needs

• Example: Basic websites needing simple traffic distribution

The choice of load balancer depends on factors like:

• Application architecture

• Performance requirements

• Protocol support needs

• Scaling requirements

• Cost considerations

The key benefit is it allows applications to scale and remain available by distributing work across multiple resources rather than overwhelming any single one.

Let me share my experience implementing load balancing for our quotes application:

When I deployed the quotes application, I primarily used an Application Load Balancer (ALB) with Auto Scaling to handle unpredictable traffic patterns. Initially, I set up the ALB with target groups pointing to our EC2 instances. I configured health checks to ping the /health endpoint every 30 seconds, ensuring only healthy instances received traffic. The ALB handled SSL termination using a certificate from AWS Certificate Manager, which simplified our HTTPS implementation.

For the Auto Scaling configuration, I created a launch template that included our quotes app AMI, t2.micro instances (to keep costs down during testing), and the necessary security groups. I set the Auto Scaling group to maintain a minimum of two instances for high availability and allowed it to scale up to five instances based on demand. The scaling policy I implemented triggered a new instance creation when CPU utilization exceeded 70% for more than three consecutive minutes and scaled down when it dropped below 30%. This prevented the system from scaling up and down too rapidly.

Q. What is CloudFormation and why is it used for?

AWS CloudFormation is an infrastructure as code (IaC) service that helps model and set up AWS resources in an organized and predictable way. Let me explain based on my experience:

When deploying complex applications, I used CloudFormation to create templates that described all the AWS resources needed. For instance, when setting up a three-tier web application, I created a YAML template that defined the VPC, subnets, EC2 instances, RDS database, load balancers, and security groups. Instead of manually creating each resource through the AWS console, CloudFormation automatically provisioned everything defined in the template.

The real power of CloudFormation became apparent when managing multiple environments. I maintained separate templates for development, staging, and production environments. When a change was needed, like adding a new security group rule or updating an instance type, I simply updated the template and CloudFormation handled the changes across all resources. This ensured consistency and eliminated configuration drift between environments.

One particularly useful feature I relied on was CloudFormation's stack concept. Each deployment created a stack that tracked all resources as a single unit. This made it easy to review changes, update resources, and if needed, roll back entire environments to a previous state. For example, when we once deployed a problematic configuration, I could quickly roll back the entire stack to its previous working state rather than trying to manually revert individual resources.

The version control aspect was invaluable for collaboration. By keeping templates in Git, team members could review infrastructure changes through pull requests, just like application code. This provided better visibility, documentation, and audit trails for all infrastructure modifications. CloudFormation effectively turned our infrastructure into code, making it more maintainable, repeatable, and less prone to human error.

Q. Difference between AWS CloudFormation and AWS Elastic Beanstalk?

AWS CloudFormation and AWS Elastic Beanstalk are both services provided by Amazon Web Services (AWS) that help with infrastructure management and deployment, but they have some key differences:

1. Infrastructure as Code vs. Platform as a Service (PaaS):

   • CloudFormation is an "Infrastructure as Code" service, which allows you to define your entire AWS infrastructure (e.g., EC2 instances, databases, networks, etc.) in a declarative template. This template can then be used to provision and manage the infrastructure.

   • Elastic Beanstalk, on the other hand, is a "Platform as a Service" (PaaS) offering. It abstracts away the underlying infrastructure and allows you to simply deploy your application code, while Elastic Beanstalk handles the provisioning and management of the infrastructure needed to run your application.

2. Customization and Control:

   • CloudFormation gives you more control and flexibility in defining and managing your infrastructure. You can precisely specify the resources you need, their configurations, and the relationships between them.

   • Elastic Beanstalk provides a more opinionated and streamlined experience, where it automatically provisions and manages the required infrastructure based on the platform you choose (e.g., Java, .NET, Node.js, Docker, etc.). This can be easier to get started with, but offers less customization.

3. Deployment and Scaling:

   • CloudFormation allows you to manage the entire lifecycle of your infrastructure, including deploying updates and scaling resources as needed.

   • Elastic Beanstalk automatically handles the deployment and scaling of your application, based on the configuration you provide. It can automatically scale your application up or down based on traffic.

4. Monitoring and Logging:

   • CloudFormation provides visibility into the state of your infrastructure, but you may need to set up additional monitoring and logging solutions.

   • Elastic Beanstalk integrates with other AWS services like CloudWatch to provide built-in monitoring and logging capabilities for your application.

In summary, CloudFormation is better suited for users who require more control and customization over their infrastructure, while Elastic Beanstalk is a good choice for users who want a more managed, opinionated platform to deploy and run their applications.

Q. What are the kinds of security attacks that can occur on the cloud? And how can we minimize them?

Cloud computing environments can be vulnerable to a variety of security attacks. Here are some common types of security attacks that can occur on the cloud and how you can minimize them:

1. Data Breaches: Unauthorized access to sensitive data stored in the cloud. To minimize this, use strong access controls, encrypt data at rest and in transit, and monitor for suspicious activity.

2. Distributed Denial of Service (DDoS) Attacks: Attempts to overwhelm cloud resources and make services unavailable. Mitigate this by using DDoS protection services, scaling resources automatically, and monitoring for anomalous traffic.

3. Account Hijacking: Unauthorized access to user or administrator accounts. Use multi-factor authentication, strong password policies, and limit access privileges to the minimum required.

4. Insider Threats: Malicious actions by authorized users with access to cloud resources. Implement strict access controls, monitor user activity, and have a robust incident response plan.

5. Misconfiguration: Leaving cloud resources or services improperly configured, exposing them to potential attacks. Conduct regular security audits, use Infrastructure as Code to enforce consistent configurations, and leverage cloud security services.

6. Malware Injection: Introducing malicious code into cloud environments. Use antivirus/antimalware solutions, enforce secure software development practices, and keep systems and applications up-to-date.

7. Abuse of Cloud Services: Using cloud resources for illegal or unintended purposes, such as cryptocurrency mining or launching attacks. Implement usage monitoring, billing alerts, and enforce acceptable use policies.

To minimize these security risks in the cloud, it's essential to:

• Implement robust identity and access management controls

• Encrypt data at rest and in transit

• Monitor cloud resources and activities for anomalies

• Keep software and systems up-to-date with the latest security patches

• Leverage cloud-native security services and tools

• Regularly review and update security policies and procedures

• Provide security awareness training to cloud users

• Have a well-defined incident response plan

By combining these security best practices, you can significantly reduce the risk of security attacks in your cloud environment.

Q. Can we recover the EC2 instance when we have lost the key?

Yes, it is possible to recover an EC2 instance when you have lost the key pair, but the approach will depend on the specific situation and the state of the instance.

Here are a few methods you can consider to recover the instance:

1. Create a new key pair: If the instance is in a running state, you can create a new key pair and replace the existing one. Here's how:

   • In the EC2 console, select the instance and choose "Connect".

   • In the "Connect to instance" dialog, click on the "Get password" button.

   • Use the new key pair to decrypt the password and connect to the instance.

   • Once connected, you can create a new key pair and replace the lost one.

2. Use the AWS Systems Manager (SSM) Session Manager: If the instance has the SSM Agent installed and configured, you can use the Session Manager to connect to the instance without a key pair. This is a secure way to access the instance and potentially recover the key pair.

3. Create a new instance from a snapshot: If the instance is stopped or terminated, you can create a new instance from a snapshot of the original instance. This will allow you to access the instance and potentially recover the key pair.

4. Reset the instance password: For Windows instances, you can use the "Get System Log" functionality in the EC2 console to reset the Windows password, then use that password to connect to the instance.

5. Terminate the instance and create a new one: As a last resort, you can terminate the instance and create a new one with the same configuration, if you have the necessary information stored elsewhere (e.g., in your configuration management system).

It's important to note that the specific steps may vary depending on the instance state, the operating system, and the security configuration of your environment. If you're unsure about the best approach, it's recommended to consult the AWS documentation or reach out to AWS Support for guidance.

Q. What is a gateway?

A gateway, in the context of computer networking, is a device or software application that acts as an entry point between two or more networks. It serves as a bridge that allows communication and data transfer between different network environments.

The main functions of a gateway include:

1. Routing: A gateway routes network traffic between different networks or subnets, determining the best path for the data to reach its destination.

2. Address translation: Gateways can perform network address translation (NAT), which involves converting between different address formats, such as translating between public and private IP addresses.

3. Protocol conversion: Gateways can translate between different network protocols, allowing devices or networks using incompatible protocols to communicate with each other.

4. Security: Gateways can implement security measures, such as firewalls, to control and monitor the flow of traffic between networks, protecting the internal network from external threats.

5. Access control: Gateways can enforce access control policies, restricting or allowing specific types of network traffic based on predefined rules.

Common examples of gateways include:

• Router: A network device that connects two or more networks and routes traffic between them.

• Proxy server: A gateway that acts as an intermediary between a client and a server, providing features like caching, content filtering, and security.

• Virtual private network (VPN) gateway: A gateway that securely connects remote users or sites to a private network over a public network, such as the internet.

• Application gateway: A gateway that acts as an intermediary for specific application-level protocols, like web traffic (HTTP/HTTPS) or database queries.

Gateways play a crucial role in modern computer networks, enabling seamless communication, security, and control between interconnected networks.

Q. What is the difference between the Amazon Rds, Dynamodb, and Redshift?

Amazon RDS, DynamoDB, and Redshift are all database services provided by Amazon Web Services (AWS), but they have some key differences:

1. Amazon RDS (Relational Database Service):

   • RDS is a managed service for relational databases, such as MySQL, PostgreSQL, Oracle, SQL Server, and Amazon Aurora.

   • It handles database administration tasks, like provisioning, patching, backup, and recovery.

   • RDS is well-suited for use cases that require a traditional relational database, such as web applications, e-commerce sites, and enterprise applications.

2. Amazon DynamoDB:

   • DynamoDB is a fully managed NoSQL (non-relational) database service.

   • It's designed for fast and predictable performance at any scale, making it a good choice for applications with rapidly changing data, such as mobile, web, gaming, and IoT applications.

   • DynamoDB offers key-value and document data models, and it automatically scales to meet application demands.

3. Amazon Redshift:

   • Redshift is a fully managed, petabyte-scale data warehouse service.

   • It's optimized for analytical workloads and large datasets, making it suitable for business intelligence, data warehousing, and data lake use cases.

   • Redshift uses columnar storage and massively parallel processing (MPP) to deliver high-performance querying and analytics.

In summary:

• RDS is a managed relational database service, suitable for traditional database applications.

• DynamoDB is a managed NoSQL database, optimized for fast and scalable performance.

• Redshift is a managed data warehouse service, designed for large-scale analytical workloads.

The choice between these services ultimately depends on your specific data and application requirements, such as the data model, performance needs, and the type of workload you're running.

Q. Do you prefer to host a website on S3? What's the reason if your answer is either yes or no?

I generally do not have a strong preference for hosting websites on Amazon S3 versus other hosting options. The choice of hosting platform depends on the specific requirements and characteristics of the website.

That being said, there are certain scenarios where hosting a website on Amazon S3 can be a good choice:

1. Static Website Hosting: If your website is primarily composed of static content (HTML, CSS, JavaScript, images, etc.) without any server-side processing, S3 can be an excellent option. S3 provides a simple, scalable, and cost-effective way to host and serve static content.

2. Simplicity and Scalability: S3 is a highly scalable and reliable storage service, so hosting a website on it can provide automatic scaling and high availability without the need to manage the underlying infrastructure.

3. Low Cost: For simple, static websites, hosting on S3 can be more cost-effective than using a traditional web hosting platform or setting up a dedicated web server.

4. Integration with Other AWS Services: If your website is part of a larger AWS-based infrastructure, hosting it on S3 can provide seamless integration and easier management, especially when combined with other AWS services like CloudFront (content delivery network) and Route 53 (DNS).

However, there are also scenarios where hosting a website on S3 may not be the best choice:

1. Dynamic Content and Server-side Processing: If your website requires server-side processing, database integration, or the ability to handle dynamic content, a traditional web hosting platform or a managed service like AWS Elastic Beanstalk or EC2 may be more appropriate.

2. Complexity and Customization: For more complex websites with custom requirements, such as specific server configurations, web application frameworks, or advanced content management systems, a traditional hosting solution may provide more flexibility and control.

3. Existing Infrastructure and Skills: If your team or organization already has experience and infrastructure set up for traditional web hosting, it may be more efficient to continue using those existing resources and skills.

In summary, while hosting a website on Amazon S3 can be a viable and cost-effective option for certain types of static websites, the decision ultimately depends on the specific requirements, complexity, and existing infrastructure of the project. It's important to carefully evaluate the trade-offs and choose the hosting platform that best fits the needs of your website and your organization.