Devops and aws interview preparation Hyderabad

Question:-100 A developer accidentally commits AWS credentials to Git. What is your complete incident response process? 1.we do not touch the Git repository first priority is disabling the credential at the provider level to stop active exploitation. 2.Log into the AWS IAM Console or use the AWS CLI to change the key status to Inactive. Do not delete it yet; keeping the key identifier intact helps when parsing logs. aws iam update-access-key --access-key-id <LEAKED_KEY_ID> --status Inactive --user-name <USER_NAME> 3.If the key belonged to an IAM user, apply an explicit inline deny policy to that user to instantly terminate any ongoing API sessions initiated by attackers.    4.We Look closely for malicious resource creation, such as newly launched high-end EC2 instances (typically for crypto-mining), modified S3 bucket policies, or newly created IAM users/backdoor access keys.   5.Scan all active AWS regions. Attackers frequently spin up resources in secondary or unused regions to bypass localized monitoring dashboards.  6.Simply deleting the file and making a new commit leaves the secret visible in our repository's historical timeline. we use tools like git filter-repo or BFG Repo-Cleaner to strip the credentials from all historical commits, branches, and tags.   To learn aws&Devops from scratch ping me 9154078579

Hi I am going to start new AWS&Devops session @9:30 Am IST on 10-08-2026 the training main intension is to clear the interview by ourself ping me who are interested to join session 9154078579

Question:-98 What is Exit Status 143 in Kubernetes? 1. The number is derived from the standard Linux formula for signal-based exits: 128 + Signal Number (128 + 15 = 143)   A container was successfully terminated by a SIGTERM (Signal 15) request. 2.Exit Status 143 is often part of normal cluster maintenance and operations, rather than an application crash 3.Kubernetes scales down a deployment, removing excess replicas. 4.A new version of your application is deployed, requiring old pods to shut down. 5.A cluster node is being prepared for maintenance, causing Kubernetes to evict and reschedule pods it's Node draining     6.The kubelet detects the application is unhealthy and initiates a restart. To learn aws and devops from scratch ping me 9154078579

Question:-97 Suppose AWS Config automatically deletes any IAM User that gets created. How would you handle a business exception where a specific IAM User is required? 1.The actual deletion is handled by an AWS Systems Manager (SSM) Automation document or an AWS Lambda function. 2.Modify the code or automation document that executes the deletion to check for this tag before terminating the user.   Tag Key: ConfigExemption  Tag Value: AllowIAMUser   import boto3 iam = boto3.client('iam') def lambda_handler(event, context): # Extract username from the AWS Config evaluation event username = event['detail']['requestParameters']['userName'] # Fetch user tags tags = iam.list_user_tags(UserName=username)['Tags'] # Check for exemption for tag in tags: if tag['Key'] == 'ConfigExemption' and tag['Value'] == 'AllowIAMUser': print(f"User {username} is exempt from auto-deletion.") return # Delete user if not exempt iam.delete_user(UserName=username) 3. we need to configure Amazon EventBridge to detect when a user is created with the exemption tag. 4.Move the workload requiring the IAM User to a dedicated AWS account or Organizational Unit (OU) where this specific AWS Config rule is not deployed. To learn aws&Devops from scratch ping me 9154078579

Question:-96 How do you monitor AWS applications? Which tools, metrics, and alerts do you consider essential? we can establish a reliable, automated monitoring environment using native AWS tools alongside critical metrics and alerts. 1.Amazon CloudWatch: Acts as our core observability hub. It collects system performance data, unifies application logs, and visualizes system trends on central dashboards. 2.AWS X-Ray: Operates as our primary troubleshooting engine. It traces requests as they travel across complex microservice architectures to isolate performance bottlenecks 3.AWS CloudTrail: Serves as our governance and security auditor. It logs all API calls and user changes made within our infrastructure 4.Third-Party Platforms: Tools like Datadog, New Relic, or Dynatrace provide external alternatives. They aggregate multi-cloud metrics and deliver unified distributed tracing Below are essential Metrics to Monitor  1. Request Count / Throughput: Total volume of traffic hitting the application. 2.4xx and 5xx Error Rates: Indicates client-side request issues or server-side application faults.  3.Integration Timeouts: Delays connecting to databases (e.g., RDS) or external APIs.  4.CPU & Memory Utilization: Tracked closely via Amazon CloudWatch to ensure workloads are not starved or over-provisioned.   To learn aws&Devops from scratch ping me 9154078579

Question:-95 Explain one challenging production incident and how you resolved it in jenkins    1. A challenging production incident in Jenkins is unexpectedly dropping offline mid-build or random OutOfMemory (OOM) errors . 2.During high-load periods or long-running jobs (like Docker image builds or test suites), Jenkins agents would randomly disconnect with a java.io.IOException: Unexpected termination of channel error. 3.Java Remoting ping timeouts, or the Linux Out of Memory (OOM) killer terminating the gent process due to high resource usage. 4.For cloud-based or SSH agents, the Jenkins remoting ping thread occasionally drops the connection if a network packet is delayed. This was resolved by configuring the SSH client configuration on the agent nodes to keep connections alive automatically . Host * ServerAliveInterval 300 ServerAliveCountMax 30 5. We Need to  configure pipelines to use the Jenkins Workspace Cleanup Plugin to periodically delete old workspaces and free up local disk space. To learn aws&Devops from scratch ping me 9154078579

Question:-94 Why is the Cluster Autoscaler not scaling up even though pods are in the Pending state? 1. If a pod has strict scheduling requirements (e.g., nodeSelector, nodeAffinity, or tolerations) that do not match any available or deployable node in our cloud environment, the CA will refuse to scale up 2.If the CA requests a new node but our cloud provider limits are maxed out (e.g., AWS EC2 vCPU limit), the scale-up will fail. 3. The CA scales based purely on the resources.requests defined in the pod manifest, not actual hardware usage 4.The pod's CPU or memory requests are larger than the total allocatable capacity of the largest single node instance type available in our node groups. A pod cannot be split across multiple nodes. To learn aws&Devops from scratch ping me 9154078579

Question:-94 Why is the Cluster Autoscaler not scaling up even though pods are in the Pending state? 1. If a pod has strict scheduling requirements (e.g., nodeSelector, nodeAffinity, or tolerations) that do not match any available or deployable node in our cloud environment, the CA will refuse to scale up 2.If the CA requests a new node but our cloud provider limits are maxed out (e.g., AWS EC2 vCPU limit), the scale-up will fail. 3. The CA scales based purely on the resources.requests defined in the pod manifest, not actual hardware usage 4.The pod's CPU or memory requests are larger than the total allocatable capacity of the largest single node instance type available in our node groups. A pod cannot be split across multiple nodes. To learn aws&Devops from scratch ping me 9154078579

Hi i am going to start new aws&Devops session from scratch on 18-07-2026 @8AM-IST training main intension is to clear the interview on your own . ping me who are interested to join the session 9154078579

Question:-93 Explain the complete request flow from a browser to a Kubernetes pod. 1. The user types a domain (e.g., ://example.com). The browser queries DNS servers to find the external IP address associated with that domain. -->The request is directed to the load balancer configured in front of our Kubernetes cluster 2.Traffic reaches the cluster's ingress controller such as NGINX Ingress Controller --->The controller inspects the request's host header and path, then applies predefined routing rules to determine which internal service should handle the request. 3.The Ingress controller forwards the request to the target Kubernetes Service---->The Service provides a stable, virtual IP (ClusterIP). Depending on the Service type, it uses iptables or IPVS (IP Virtual Server) to distribute incoming connections across healthy pods. 4.To determine exactly which pods to route traffic to, the Service controller continuously checks the Kubernetes API to read the active list of EndpointSlices. 5.Once the specific Pod IP is selected, the request is handed over to the CNI (Container Network Interface) plugin (e.g., Calico, Cilium, Flannel) 6.The CNI routes the network packet through the host's virtual ethernet bridge (veth pair) directly into the target pod's isolated network namespace, where your application processes the request. To learn aws&Devops from scratch ping me 9154078579

Question:-92 How do you handle docker image versioning and tagging in production? If we don't maintain docker image versioning and tagging in production properly it can lead to broken rollbacks, untraceable bugs, and accidental environment overwrites 1.Never use the latest tag for production deployments or orchestration manifests (like Kubernetes or ECS). 2.A production-ready pipeline applies multiple tags to the exact same image ID at build time. 3.Every image must be tagged with the short Git commit hash that triggered the build. This ensures absolute traceability from the running container directly back to the source code example : my-app:sha-7a1b2c3 4.For actual releases, tag the image using Semantic Versioning (MAJOR.MINOR.PATCH) linked to your Git release tags. example: my-app:1.2.4 To learn aws&Devops from scratch ping me 9154078579

Question:-91 How would you create multiple S3 buckets in Terraform? 1. we should use the for_each meta-argument or the count meta-argument inside the aws_s3_bucket resource block. 2. Using for_each is the industry best practice because it tracks resources by a unique key (the bucket name) rather than an array index, preventing accidental deletion # Define a map of your buckets and their specific environment tags variable "s3_buckets" { type = map(object({ environment = string })) default = { "mycompany-app-dev-data" = { environment = "dev" } "mycompany-app-stage-data" = { environment = "staging" } "mycompany-app-prod-data" = { environment = "production" } } } # Create buckets dynamically resource "aws_s3_bucket" "multi_bucket" { for_each = var.s3_buckets bucket = each.key force_destroy = false tags = { Environment = each.value.environment ManagedBy = "terraform" } } To learn aws&Devops practically from scratch ping me 9154078579

Question:-90 Terraform apply failed after creating some resources. What steps will you take? 1.When a terraform apply fails terraform does not support automatic rollbacks any resources successfully provisioned before the crash remain active in our cloud environment. 2. we can freeze any automated CI/CD deployments and stop all pipelines 3.we can read the terminal output from the bottom up to locate the exact resource address, provider error code (e.g., 403 Access Denied, 409 Conflict), and source file reference 4.our primary goal is to find out if the partially created resources were successfully recorded by Terraform 5.Resources exist in the cloud but NOT in the state file because the apply process was abruptly killed (like a pipeline timeout or Ctrl+C force-kill) before Terraform could write back to the state file. 6.Manually adopt them using terraform import <resource_address> <cloud_resource_id>. Alternatively, if it is safe to do so, manually delete the orphan resources from the cloud console and let Terraform rebuild them on the next run To learn aws&Devops from scratch ping me 9154078579

Question:-89 Memory usage is normal but containers are killed. What would you check first? Standard monitoring tools (like docker stats or basic Prometheus metrics) often fail to capture sudden, millisecond-level memory spikes, non-RSS memory overhead, or host-level resource constraints 1.When containers are killed despite normal memory usage, the most likely culprit is the Out-Of-Memory (OOM) killer operating at the host level. 2.Inspect the stopped container for exit code 137. This specifically indicates that the container was forcefully terminated by an external signal (SIGKILL), usually because it exceeded a set memory limit 3.we can use the Linux man page for dmesg to check for kernel logs by running dmesg -T | grep -i -E 'oom|kill'. This will show exactly which process was terminated and why. 4.Nedd to check if your orchestrator or runtime (like Docker or Kubernetes) has strict memory limits configured. A container's memory limit might be set too low, causing it to crash before overall system memory registers high usage. 5.A failing custom liveness or readiness probe can cause the platform to restart a container even if the application process itself is not technically out of memory. To learn aws&Devops from scratch ping me 9154078579

Question:-88 Explain the complete request flow from Route 53 → ALB → EKS/EC2 1.Route 53, using a hosted zone, looks up the DNS records for our domain. It is typically configured with an Alias record that points directly to our ALB’s Fully Qualified Domain Name (FQDN). 2.Route 53 returns the IP addresses of the ALB nodes back to the user's browser. 3.The user’s browser initiates a connection to the ALB’s IP address. The ALB (which is deployed in a public subnet) acts as the primary, secure entry point for external traffic 4.The ALB evaluates incoming requests based on its configured Listeners (e.g., port 443 for HTTPS). It offloads TLS/SSL certificates and applies security group rules to validate the traffic. 5.The ALB evaluates host and path-based routing rules (e.g., /api/* or service1.example.com) to determine which Target Group the request should go to. 6.The ALB forwards the traffic directly to the node ports of our EKS worker nodes (or directly to Pod IPs if we use AWS CNI). Inside the cluster, an Ingress controller (like NGINX) or an EKS Service (ClusterIP) receives the traffic and load-balances it to the specific, healthy application Pod. 7.The ALB forwards traffic to its registered Target Group, which consists of backend EC2 instances running in private subnets. To learn aws&Devops from scratch ping me 9154078579

Question:-87 Explain about kubernetes networking architecture Kubernetes networking architecture provides a flat, routable network where all Pods can communicate with each other and with Services, regardless of their host node 1.All Pods are assigned their own IP addresses 2.Nodes run a root network namespace that bridges between the Pod interfaces. This allows all Pods to communicate with each other using their IP addresses 3.Communication does not depend on Network Address Translation (NAT), reducing complexity and improving portability. 4.Pods are assigned their own network namespaces and interfaces. All communications with Pods go through their assigned interfaces. 5.The cluster-level network layer maps the Node-level namespaces, allowing traffic to be correctly routed across Nodes. The three main types of network components in Kubernetes are Pod networking, Service networking, and Ingress/Egress networking. 1.Pod Networking: Handles direct communication between Pods. Each Pod gets a unique IP address, and Pods communicate without NAT, using CNI plugins for routing and IP management. 2. Service Networking: Provides stable virtual IPs (ClusterIP) for accessing a group of Pods. Kube-proxy manages traffic routing to healthy Pods using iptables, IPVS, or eBPF. 3. Ingress/Egress Networking: Manages external access to the cluster. Ingress controllers handle HTTP/S routing to internal Services, while Egress defines how Pods reach resources outside the cluster, often using NAT or egress gateways. To learn aws&Devops from scratch ping me 9154078579

Question:-84 How do you safely rotate IAM credentials in production without breaking active sessions? To safely rotate IAM access keys in production without downtime, we generate a secondary key, distribute and validate it, deactivate the old key, and finally delete it. 1. we can log into the AWS IAM Console or use the AWS CLI to generate a new key while the old one remains active. AWS permits up to two active access keys per IAM user at any given time. 2.Distribute the new key to your applications, configuration files, or the AWS Secrets Manager. Reload or restart services so they pick up the updated environment variables without causing active API sessions to drop. 3.we need to observe our applications to ensure they are executing successfully 4.Once traffic is routed through the new key, change the old key's status to Inactive in the AWS console or using the CLI. 5.After a sufficient buffer period (typically 14 to 90 days), safely delete the inactive key to minimize your security footprint. 6.Store credentials in encrypted parameter stores or use AWS Secrets Manager so applications pull credentials dynamically without code changes. To learn aws &Devops from scratch ping me 9154078579

Question:-83 etcd healthy but kubectl commands freezing intermittently. Why? When etcd logs report a healthy state, but kubectl commands freeze intermittently, the issue typically lies in the communication pipeline between kubectl and the kube-apiserver 1.The kube-apiserver acts as a proxy for aggregated APIs and admission webhooks. When we run a command like kubectl get, the server may block the response while waiting for a down or slow external service to reply. 2.If the API server is hitting its Kubernetes resource limits or node limits, it will intermittently freeze processing its internal connection queue. 3.kubectl checks for updated discovery APIs frequently. If our local DNS server or corporate VPN intermittently delays resolving the API server's endpoint, kubectl will freeze for several seconds before executing. 4.Need to Identify if any registered API extensions are currently in a failed state kubectl get apiservice | grep -v True To learn aws&Devops practically from scratch ping me 9154078579

Question:-85 Do you maintain a single CI/CD pipeline for all environments (Development, SIT, UAT, and Production), or do you use separate pipelines? How do you manage environment-specific configurations and deployments? Maintaining separate, disconnected pipelines for each environment introduces a high risk of configuration drift, environment-specific script bugs, and deployment inconsistencies so we can maintain a single CI/CD pipeline for all environments (Development, SIT, UAT, and Production) 1.A single master pipeline file uses distinct, sequential Stages or Jobs to isolate environments. This enables the foundational DevOps rule Build once, deploy many times 2. The pipeline compiles code, runs unit tests, and creates a single immutable build artifact (e.g., a Docker image, a ZIP folder, or a compiled binary) just once. 3.The pipeline promotes exact same artifact sequentially through the environments. we do not rebuild code from source for Production, which ensures that what we tested in UAT is identically what goes live. 4.Moving from Dev to SIT might be fully automatic upon successful automated testing, while advancing to UAT and Production requires Manual Approval Gates from QA leads or product owners. 5.Platforms like GitHub Actions and GitLab CI/CD allow to define "Environments". Variables and secrets (like DB_HOST or API_SECRET) are mapped to specific environments and only injected when that specific pipeline stage runs To learn aws&Devops from scratch ping me 9154078579

Hi I am going to start the AWS&Devops new session on 22-06-26 @7 Am IST training main intention is to clear the interview on your own ping me who are interested to join the session 9154078579