Devops and aws interview preparation Hyderabad

Question:-75 What are common Grafana issues in production? Common Grafana issues in production and DevOps environments typically revolve around data source connectivity, sluggish dashboard performance, alert storms, and configuration drift. 1.Panels pulling large, unfiltered datasets from Prometheus (PromQL) or SQL databases overload backend storage. 2.Dashboards with too many active panels or auto-refresh intervals set too low trigger "Query Timeout" or freeze the browser.   3.Slow or blocked network connectivity between Grafana's backend and data sources (like Prometheus or AWS CloudWatch). 4.Deleting and recreating Grafana environments without properly provisioning data sources via YAML ruins observability. 5.A single core infrastructure outage (e.g., a shared database) generating hundreds of dependent alerts, overwhelming on-call engineers 6.Automated alerts and provisioned dashboards failing silently because the Service Account tokens expired or lack the correct permissions. 7.Grafana instances exceeding memory limits (often when generating large PDF/image reports) and being killed by Kubernetes.

Question:-74 You deployed a sidecar logging agent. Suddenly, CPU throttling spikes. Diagnose and rollback. 1.CPU throttling happens when a container exceeds its configured CPU limit.   2.A sudden increase in application logs forces the sidecar to use more processing power to parse, compress, and ship data. 3.Complex log parsing rules (like heavy regular expressions) consume massive CPU cycles under load 4.we can view container CPU metrics and look for nr_throttled or throttled_time kubectl top pods -n --containers 5. we can monitor real-time resource usage of the sidecar container kubectl top pod -n --container= 6.If production stability is at risk, execute a rollback or temporary patch immediately. kubectl rollout undo deployment/ -n

Question:-73 terraform module working in dev but failing in prod. Why? Terraform modules fail in production after working in development due to differences in permissions, environment states, or provider versions 1.Prod IAM roles might block specific actions like creating public IPs or deleting databases. 2.AWS Organizations often apply strict SCP Service Control Policies to Prod accounts that do not exist in Dev. 3.Prod variables might request larger instance sizes or disk types that hit service quotas in that region. 4.Conditional logic (count or for_each) based on environment variables might trigger untested code paths in Prod. 5.If provider versions are not locked, Prod might be downloading a newer, breaking version of a provider 6.Prod networks often have tighter security groups or firewalls that prevent resources from communicating during provisioning.

Question:-71 You need to temporarily save changes without committing. How? 1.To temporarily save our work without committing, use the git stash command. 2.git stash takes our current changes (both staged and unstaged) and stores them on a internal stack, giving a clean working directory. 3.To add a descriptive note, we can use git stash push -m "our message" 4.By default, stash only tracks modified files. Use git stash -u to include untracked files. 5.git stash pop to apply the most recent changes and immediately delete them from the stash 6.git stash apply if we want to restore the changes but keep the record in our stash for later use. 7.git stash list to see all our temporarily saved changes. For practical learning aws&Devops ping me 9154078579

Question:-70 How do you implement cross-account access in Amazon Web Services using IAM roles? Implementing cross-account access in AWS involves a "trusting" account (the resource owner) and a "trusted" account (where the users live). 1.In IAM Console Choose Create role and select AWS account as the trusted entity type. 2.Enter the Account ID of the "trusted" account (where our users are). 3.Attach Permission Policies that define what the role can do (e.g., AmazonS3ReadOnlyAccess). 4.Name the role and take note of its ARN (e.g., arn:aws:iam::Trusting-Account-ID:role/CrossAccountRole). 5.In the account where our users live, select the specific user or group that needs access. 6.Attach an Identity-based Policy (inline or managed) that allows the sts:AssumeRole action. { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::Trusting-Account-ID:role/CrossAccountRole" } } 7.Log in to the trusted account, click our username in the top right, select Switch Role, and enter the trusting account ID and role name. For practical aws&Devops learning ping me 9154078579

Question:-69 How do sidecars help in containerizing legacy applications? By running a supporting container (the sidecar) alongside the main application container (the legacy--A legacy application is an outdated software program-- app) in the same Kubernetes pod, they share resources like network and storage, allowing them to communicate via localhost and share files 1.Legacy applications often only support HTTP. A sidecar proxy (like Nginx) can handle incoming HTTPS requests and pass them to the legacy app over localhost. 2.Sidecars can act as an authentication agent (e.g., OAuth2 Proxy), validating tokens and handling user identity before passing requests to the app. 3.Instead of changing the legacy code to log to a central system, a sidecar (e.g., Fluentd) can tail log files on a shared volume and ship them to modern logging backends (Elasticsearch, Splunk). 4.Sidecars can act as adapters, polling metrics from the legacy application or reading logs and exporting them into formats compatible with Prometheus. 5.Instead of baking secrets into the image, a sidecar can pull secrets from a secure vault (like HashiCorp Vault) and populate them at runtime. For practical aws&Devops learning ping me 9154078579

Question:-68 Why should containers run as non-root? What is image immutability? 1.If a container running as root is compromised, the attacker may gain root-level access to the host machine, leading to a full system compromise. 2.Non-root containers restrict the actions an attacker can perform, such as installing malicious packages or modifying system files, reducing the overall risk. 3.Even if an application vulnerability is exploited, the limited privileges of a non-root user prevent the attacker from performing administrative tasks or accessing sensitive host resources. 4.orchestration platforms like OpenShift and Kubernetes strongly recommend or enforce running applications as non-root 5.Using a custom non-root user with a specific user ID (UID) helps avoid file permission conflicts when mounting volumes between the container and the host. Image immutability Image immutability is a software engineering principle where a container image, once built, remains completely unchangeable. If any part of the image needs an update—such as a security patch or a code change—the existing image is not modified; instead, a brand-new image is built to replace the old one For aws&Devops practical learning ping me 9154078579

Question:-67 What was the last production outage you handled? What was the root cause? I faced docker-related production outages 1.Mainly due to resource mismanagement, networking misconfigurations, or external infrastructure dependencies. 2.Docker experienced a widespread outage affecting Docker Hub, Scout, and Build Cloud due to a major failure in AWS's US-East-1 region.   3.Failed due to trigger by outages in AWS DynamoDB, EC2, and Network Load Balancers, leading to increased failure rates that ultimately took Docker services offline for over 24 hours. 4.Containers frequently hit Out-of-Memory (OOM) limits (Exit Code 137). This is often due to application memory leaks or setting limits that are too low for actual production workloads. 5.Unused images, stopped containers, and rapidly growing log files can fill the host's disk space, preventing the Docker daemon from writing state and leading to a full system hang 6.Overlay networks often fail due to MTU (Maximum Transmission Unit) mismatches between the container network and the physical host network, causing packet fragmentation and connection timeouts.   For practical aws&Devops learning ping me 9154078579

Question:-66 How can we compress the logs & rotate the logs? Without proper log rotation, log files can consume all available disk space and bring our system to its knees. Logrotate is the standard tool on Linux for automatically rotating, compressing, and removing old log files. 1.Logrotate configurations are typically found in /etc/logrotate.conf or in files within /etc/logrotate.d/ 2.we add the compress keyword to our logrotate configuration block to enable compression for rotated files. 3.we use delaycompress along with compress to postpone compression until the next rotation cycle. 4.we can use rotate to define how many compressed logs to keep before deleting them /var/log/myapp.log { daily rotate 7 compress delaycompress missingok notifempty create 0640 root adm } For practical learning aws&Devops ping me 9154078579

Question:-65 What is the role of Docker DNS and service discovery? Docker's embedded DNS and service discovery mechanism allows containers to communicate with each other using human-readable names instead of static, hardcoded IP addresses 1.Docker runs an embedded DNS server at the internal IP 127.0.0.11 for every container connected to a user-defined network 2.When a container requests a name (e.g., ping database), the embedded server checks its internal key-value store to find the corresponding container's IP on the same network 3.If the name is not found internally (like google.com), Docker's DNS forwards the request to the external DNS servers configured on the host machine. 4.By using names rather than IPs, configurations remain consistent across development, testing, and production environments. 5.Service discovery is the process by which containers automatically locate and access other network services 6. Every container is automatically registered as a DNS A record by its --name. 7.we can assign multiple containers the same network alias using the --network-alias flag 8.Services defined in a Docker Compose file can reach each other using their service names (e.g., web can connect to db) without additional setup. For practical aws&Devops learning ping me 9154078579

Hi I am going to start a new AWS&Devops session on Friday 8-05-2026 @9AM IST training main intention is to clear the interview on your own ping me who are interested to join the session 9154078579

Question:-64 How would you split a 200MB Terraform state file without breaking dependencies? 1.Splitting a large (200MB) Terraform state file requires moving resources incrementally to new state files using terraform state mv 2.Immediately we need to create a backup of the remote state file 3.we need to identify logical groupings (e.g., networking, database, services) to reduce the blast radius and team conflicts. 4.we need to create a new directory for the new state and create .tf files containing the resources we plan to move. 5.Need to use the terraform state mv command to move resources from the old state to the new state terraform state mv -state=old.tfstate -state-out=new.tfstate \ module.network.aws_vpc.main module.network.aws_vpc.main 6.we need to run terraform plan in both directories to ensure no resources are being destroyed or recreated. For practical aws&Devops learning ping me 9154078579

Question:-63 How does Docker Engine interact with container runtime? 1.The Docker Engine primarily using containerd as its high-level runtime and runc as its low-level executor. 2.A user issues a command (e.g., docker run) via the Docker CLI.The Docker Daemon (dockerd) receives this request through the Docker Engine API. It handles high-level concerns like image management and network setup. 3.The daemon sends an execution request to containerd via gRPC(Remote Procedure Call). containerd is responsible for the full container lifecycle, including image pulling and monitoring container health. 4.containerd starts a shim process for each container. This shim acts as an intermediary that keeps the container's standard input/output (STDIO) open and allows the runtime to exit after starting the container. 5.The shim invokes runc, an Open Container Initiative (OCI)-compliant runtime. runc interacts directly with the Linux kernel to create namespaces and cgroups that isolate the container. For aws&practical learning ping me 9154078579

Question:-62 How do you structure Terraform code for a team managing 100+ accounts across multiple environments like dev, staging, and production? Managing over 100 accounts across multiple environments (Dev, Staging, Production) requires a strictly structured, modular, and automated Terraform approach to avoid configuration drift and accidental destruction. 1.The best practice for this scale is a component-based module structure paired with Terragrunt, allowing you to keep configurations DRY (Don't Repeat Yourself) while keeping environment state strictly separated. 2.A popular approach for large-scale environments is a mono-repo that separates modules (reusable code) from live infrastructure (specific configuration) 3.we need to use Terragrunt to automatically configure a unique S3 backend key for every component in every region of every account Structure: bucket / env / account / region / component / terraform.tfstate 4.Instead of creating a single "application" module, break infrastructure into small, manageable units Networking Component: VPC, Subnets, Route Tables. Data Component: RDS, DynamoDB, Elasticache. App Component: EKS, ECS, Lambda. 5.When a PR is created, Atlantis runs terragrunt plan on the specific changed directory, providing visibility and requiring approval before apply. 6.we need to use Terragrunt to automatically generate the provider "aws" block for each account, assuming appropriate IAM roles For aws&Devops practical learning ping me 9154078579

Question:-61 Prod users reporting 504s, but ELB health checks are green. Explain your isolation + triage process. A 504 Gateway Timeout with green ELB health checks indicates that the load balancer can successfully reach the application (passing simple health checks), but the application is taking too long to process user requests, exceeding the ELB's Idle Timeout setting (default 60s). 1. Check HTTPCode_ELB_504_Count and TargetResponseTime in CloudWatch. If TargetResponseTime is high (approaching 60s), the backend is sluggish. 2. Need to enable ELB access logs to identify specific URLs, client IPs, or backend instances (target_status_code) returning 504s. 3.Check CloudWatch metrics for ECS tasks or EC2 instances. If CPU/memory is near 100%, instances are overwhelmed and cannot process requests. 4.Check database CPU, lock contention, or slow query logs. Often, 504s are caused by an overloaded database that the application is waiting for. 5.If the application requires long-running processes (e.g., file uploads, large data exports), increase the ELB idle timeout to exceed the maximum application processing time. For practical aws&Devops learning ping me 9154078579

Question:-60 Explain Linux server patching and how it is handled in AWS environments? 1.Linux server patching is the process of updating the operating system (OS) and installed software packages to fix security vulnerabilities, correct bugs, or add new functionality. 2.Patching involves upgrading the software packages (RPM, DEB) on a Linux system. 3.Downloads updates from repositories (e.g., yum, dnf, apt) and applies them, often requiring a service restart or a full server reboot to activate the changes. 4.AWS Systems Manager (SSM) Agent Software installed on EC2 instances that executes patch commands sent by AWS. 5.The core tool within SSM that automates scanning and installing patches. 6. we can use tags (e.g., Patch Group = Production) used to categorize instances and apply specific patch baselines to specific groups. 7.Ensure the SSM agent is installed and the EC2 instance has an IAM role attached (AmazonEC2RoleforSSM) that allows it to communicate with SSM. 8.Need to monitor the Patch Manager Dashboard to see which instances are missing patches Hi ping me for practical aws&Devops learning 9154078579

Question:-59 How do you perform zero-downtime upgrades for a stateful workload using Helm 3? 1.Performing zero-downtime upgrades for stateful workloads with Helm 3 relies on configuring Kubernetes StatefulSets and utilizing Helm’s atomic flags 2. we set spec.updateStrategy type to RollingUpdate. For StatefulSets, this replaces pods one by one in reverse ordinal order (e.g., pod-2, then pod-1, then pod-0). 3.we can use the partition parameter to perform "canary" upgrades by only updating pods with an ordinal index greater than or equal to the partition value. 4.we can define a PodDisruptionBudget in our Helm templates. This prevents Kubernetes from draining too many pods at once during node-level upgrades or maintenance.   5.use below helm upgrade command   helm upgrade --wait --atomic --timeout 10m  * use --wait to make Helm wait until all pods are in a ready state * --atomic to automatically roll back to the previous stable version if the upgrade fails or times out.  * --timeout long enough to allow for stateful initialization, such as data synchronization For practical aws&Devops learning ping me 9154078579

Question:-58 What is the difference Transit Gateway vs. VPC Peering ? 1.Transit Gateway  it is a centralized architecture with hundreds of VPCs, multi-region connectivity, hybrid cloud connections (VPN/Direct Connect). 2.VPC Peering means Connecting two VPCs for shared services, staging/production environments with low-latency needs, simple 1-to-1 data transfer. 3.Transit Gateway charges for attachment hours + data processing. VPC Peering only charges for data transfer across zones/regions, making it generally more cost-effective for simple connections 4. Transit Gateway supports hundreds of VPCs via a single hub. VPC Peering becomes difficult to manage at scale, as each VPC requires a direct link, creating a "full-mesh" 5.Transit Gateway supports it (A can talk to C via B). VPC Peering does not support transitive routing; each connection must be explicitly created.   For practical learning aws&Devops ping me 9154078579