Interviewer vs Candidate - Python Coding Challenge Interviewer: How would you automate a Control-M job submission without opening the GUI?
Candidate: I'd use the Control-M Automation API with Python.
Interviewer: Interesting. Walk me through it.
Candidate:
Accept Control-M server, folder, job name, and order date as command-line arguments.
Build the JSON payload dynamically.
Authenticate using an API token.
Submit the job using a simple POST request.
Validate the response.
Extract the Run ID for tracking and monitoring.
Interviewer: Why is this better than manual ordering?
Candidate: Because automation saves time, reduces human error, integrates easily with CI/CD pipelines, and enables event-driven scheduling without ever logging into the Control-M UI.
Interviewer: Can this be extended?
Candidate: Absolutely.
Trigger jobs from Jenkins, GitHub Actions, or Azure DevOps.
AWS has 200+ services. Do you really need to learn all of them? When I first looked at AWS, I thought I had to memorize every single service. S3, EC2, Lambda, ECS, IAM, Route 53, CloudWatch... the list just kept growing.
Then I realized something: You don't learn AWS by learning all the services. You learn AWS by understanding the building blocks.
S3 → A giant online cupboard. EC2 → A computer you rent. Lambda → A robot that works only when called. RDS → A database someone else manages. IAM → Who gets the keys. CloudWatch → Your system's security camera. Route 53 → The internet's address book. ECS/EKS → Managers for your containers.
Simple explanations make complex technologies easier to remember.
Which AWS service took you the longest to understand?
I am dealing with AWS first time. I am designing the architecture for our applications in organization.
I studied and designed one. I am sharing the picture so please look at it and suggest me if i missed anything in that (or) if anything to added or removed (or) if any mistakes in that.
Please suggest me how many ec2 servers need to launch for this scenario ?
This is what one of my student and I have suggested few of the changes
1) Use an Application Load Balancer (ALB) explicitly
In the diagram it says ELB. For a modern web application, use ALB in front of the web tier, especially for HTTP/HTTPS, path-based routing, and health checks.
2) Keep web tier and app tier in Auto Scaling Groups
That is correct in your diagram. Do not think in terms of fixed EC2 boxes. Think: Web tier = ASG App tier = ASG
3) Database should be Multi-AZ
Your DB placement looks fine, but for production I would strongly recommend: RDS Multi-AZ Private subnets only Backups enabled Read replica only if you really need read scaling
4) NAT Gateway per AZ
If this is production and highly available, place one NAT Gateway in each AZ. A single NAT Gateway is a single point of failure.
5) Some services in the diagram look unnecessary unless you truly need them These may be valid, but only if your application actually uses them:
CloudFormation: good for provisioning, not part of runtime architecture SES: only if your app sends email SNS: only if you need notifications/alerts/integration DynamoDB: only if you need NoSQL data PowerShell: not usually shown as an architecture component unless it is part of ops automation Cache: if needed, show it as ElastiCache (Redis/Memcached)
6) Security groups vs NACLs
Both are fine, but in most application architectures: Security Groups do most of the real work NACLs are optional and often kept simple
7) CloudFront + S3
This is good if you serve static content, images, JS/CSS, or downloads. If the app is mostly internal or not internet-facing, CloudFront may not be required.
If you have read the post till here make sure you share with your community and watch my youtube channel for any job help lnkd.in/gBWK_zpK
heydevops_telugu
25 Kubernetes Production Issues Every DevOps Engineer Should Know openinapp.link/24l9x
Most Kubernetes tutorials teach you how to deploy applications.
Production teaches you how to debug them.
Here are 25 issues that almost every DevOps Engineer encounters in real-world
Kubernetes environments:
CrashLoopBackOff
ImagePullBackOff
OOMKilled
Pending Pods
Node Not Ready
Readiness Probe Failed
Liveness Probe Failed
DNS Resolution Issues (CoreDNS)
Persistent Volume Claim (PVC) Pending
Persistent Volume Full
High CPU Utilization
High Memory Utilization
Service Not Reachable
Ingress Not Working
TLS/SSL Certificate Expired
Secrets Not Mounted Correctly
ConfigMap Changes Not Reflected
Deployment Rollout Stuck
NetworkPolicy Blocking Traffic
Horizontal Pod Autoscaler (HPA) Not Scaling
etcd Performance Bottlenecks
Kubernetes API Server Latency
Worker Node Disk Pressure / Disk Full
Failed Rolling Updates
Namespace Stuck in Terminating
Knowing the issue is only half the battle.
A skilled Kubernetes engineer should also know:
• How to identify the root cause
• Which kubectl commands to use
• What logs and events to inspect
• How to resolve the issue quickly
• How to prevent it from happening again
Over the next few weeks, I'll be creating a series where I break down each production issue with:
Symptoms
Root Cause
Debugging Commands
Resolution Steps
Best Practices
If you're preparing for DevOps interviews or managing Kubernetes clusters in production, this series will be valuable.
Which Kubernetes production issue has consumed the most hours of your life?
PS: If you are preparing for Job search then openinapp.link/24l9x
Make sure you save this post by resharing so that it stays on your linkedin wall
#Kubernetes #DevOps
5 days ago | [YT] | 36
View 0 replies
heydevops_telugu
80% of Linux work can be done with just 20 commands.
When I first started learning Linux, I thought I had to memorize hundreds of commands.
I was wrong.
Over time, I noticed the same commands kept appearing every single day.
grep
find
awk
sed
tail
top
ps
curl
chmod
df
These commands became muscle memory.
The lesson?
Don't try to learn everything.
Master the basics so well that solving problems becomes second nature.
I've attached a cheat sheet that every beginner should bookmark.
If you're learning Linux, save this post—you'll thank yourself later.
#Linux #Learning #DevOps #TechTips #Cloud
1 week ago | [YT] | 64
View 1 reply
heydevops_telugu
Interviewer vs Candidate - Python Coding Challenge
Interviewer: How would you automate a Control-M job submission without opening the GUI?
Candidate: I'd use the Control-M Automation API with Python.
Interviewer: Interesting. Walk me through it.
Candidate:
Accept Control-M server, folder, job name, and order date as command-line arguments.
Build the JSON payload dynamically.
Authenticate using an API token.
Submit the job using a simple POST request.
Validate the response.
Extract the Run ID for tracking and monitoring.
Interviewer: Why is this better than manual ordering?
Candidate: Because automation saves time, reduces human error, integrates easily with CI/CD pipelines, and enables event-driven scheduling without ever logging into the Control-M UI.
Interviewer: Can this be extended?
Candidate: Absolutely.
Trigger jobs from Jenkins, GitHub Actions, or Azure DevOps.
Order multiple folders dynamically.
Monitor execution status.
Send Teams or Slack notifications.
Build complete end-to-end workload automation.
Interviewer: You're hired.
DevOps / SRE salaries revealed - yt.openinapp.co/ylhhs
Like and Repost this with your SRE friends
1 week ago | [YT] | 33
View 0 replies
heydevops_telugu
Can You Remember These Networking Ports in Under 60 Seconds?
Here's the easiest way to remember the most common networking ports:
20-21 → FTP
20 bags + 21 boxes = File Transfer
22 → SSH
22 is your secure key to the server.
23 → Telnet
One step after SSH, but without security." (Avoid in production!)
25 → SMTP
25 delivers your emails." Think 25 = Send Mail
53 → DNS
53 translates names into IP addresses." (The Internet's phonebook.)
80 → HTTP
80 = Websites without security.
110 → POP3
110 pulls emails into your inbox.
443 → HTTPS
443 = Secure websites.Every time you see the lock icon, think 443.
3389 → RDP
3389 = Remote Desktop." Your computer, from anywhere
Quick Memory Trick:
FTP → 20-21
SSH → 22
Telnet → 23
SMTP → 25
DNS → 53
HTTP → 80
POP3 → 110
HTTPS → 443
RDP → 3389
Challenge:
Without looking back, can you name the service running on Port 53 and Port 443?
Drop your answers below
Subscribe to my telugu youtube channel - lnkd.in/g_EHQ38N
Subscribe to my english youtube channel - lnkd.in/g9x6K4Tk
Share & Save this post—you'll thank yourself before your next networking interview or certification exam.
2 weeks ago | [YT] | 36
View 1 reply
heydevops_telugu
AWS has 200+ services. Do you really need to learn all of them?
When I first looked at AWS, I thought I had to memorize every single service.
S3, EC2, Lambda, ECS, IAM, Route 53, CloudWatch... the list just kept growing.
Then I realized something:
You don't learn AWS by learning all the services.
You learn AWS by understanding the building blocks.
Think of it like building a house
Storage → S3, EBS, EFS
Compute → EC2, Lambda, ECS
Networking → VPC, Route 53, API Gateway
Databases → DynamoDB, RDS, Aurora
Monitoring → CloudWatch, CloudTrail
Security → IAM, KMS, WAF, GuardDuty
DevOps → CodeCommit, CodeBuild, CodeDeploy, CodePipeline
AI & ML → SageMaker, Lex, Rekognition
Once you understand these categories, AWS suddenly becomes much easier.
You don't have to know everything.
Start with:
EC2
S3
IAM
VPC
RDS
CloudWatch
These six services alone will help you understand the foundation of cloud computing.
Remember:
Don't chase AWS services. Learn how they work together to solve real-world problems.
That's when cloud starts making sense.
Which AWS service was the most confusing when you started? 👇
Checkout my telugu youtube channel - lnkd.in/g_EHQ38N
Checkout my english youtube channel - lnkd.in/g9x6K4Tk
PS: Found this post helpful?? Do share with your community :)
2 weeks ago | [YT] | 38
View 0 replies
heydevops_telugu
If I had to explain AWS in 1 minute
S3 → A giant online cupboard.
EC2 → A computer you rent.
Lambda → A robot that works only when called.
RDS → A database someone else manages.
IAM → Who gets the keys.
CloudWatch → Your system's security camera.
Route 53 → The internet's address book.
ECS/EKS → Managers for your containers.
Simple explanations make complex technologies easier to remember.
Which AWS service took you the longest to understand?
hashtag#AWS hashtag#CloudComputing hashtag#DevOps hashtag#Programming hashtag#TechCommunity hashtag#CloudLearning
2 weeks ago | [YT] | 39
View 0 replies
heydevops_telugu
If software had a heart, Linux would be one of its strongest beats. ❤️
Most people see websites.
Engineers see servers.
Experienced engineers see everything happening underneath.
A single click on a website triggers:
Network communication
Kernel scheduling
Web server processing
Application execution
Database queries
Response generation
All within milliseconds.
Linux makes this possible.
That's why Linux powers:
Cloud platforms
Most web servers
Databases
Containers
CI/CD pipelines
Virtualization
AI infrastructure
Edge devices
The more I learn Linux, the more I realize:
Linux isn't just an operating system.
It's the foundation on which modern computing is built.
For freshers:
Don't just learn commands.
Learn why Linux works the way it does.
That knowledge compounds throughout your career.
#Linux #Learning #DevOps #Cloud #SoftwareEngineering #Backend #TechCareers
3 weeks ago | [YT] | 29
View 0 replies
heydevops_telugu
The day I realized Kubernetes isn't as scary as its logo.
When I first heard the word Kubernetes, I thought it was something only DevOps engineers with 10+ years of experience could understand.
Then I opened a cheat sheet.
Instead of memorizing everything, I imagined a simple story.
Imagine you're managing a food delivery business.
Container = A chef preparing food.
Pod = The kitchen where one or more chefs work together.
Service = The restaurant's phone number customers always call, even if chefs change.
Deployment = The manager ensuring enough chefs are available during peak hours.
Secret = The safe where passwords and API keys are stored.
ConfigMap = The notice board with today's menu and settings.
Ingress = The main entrance guiding customers to the right restaurant.
Suddenly, Kubernetes stopped looking like a monster.
It became a system that simply answers three questions:
Where should my application run?
How can users reach it?
What happens if something breaks?
The biggest lesson I learned wasn't Kubernetes itself.
It was this:
Every complex technology becomes simple once you understand the story behind it.
As freshers, we often feel pressured to know everything.
You don't have to.
Start with one concept.
Understand why it exists.
Build one small project.
Repeat.
One day, you'll look back and realize the terms that once felt intimidating have become part of your daily vocabulary.
Learning isn't about memorizing commands.
It's about connecting concepts.
And that's where confidence begins. 🚀
Subscribe to my youtube channel for any Job help - yt.openinapp.co/pyjbh
PS: Reshare this post so that it stays on your linkedin wall
#Kubernetes #DevOps #CloudComputing #Freshers #LearningJourney
3 weeks ago | [YT] | 53
View 1 reply
heydevops_telugu
Every Linux command you run follows an incredible journey.
Power On ⚡
↓
Bootloader
↓
Kernel
↓
User Space
↓
System Calls
↓
CPU • Memory • Disk • Network
The Linux Kernel is the silent hero that manages:
Memory
Processes
File Systems
Device Drivers
Networking
Master this architecture, and Linux becomes much easier to understand.
Learning commands is good.
Understanding why they work is even better.
Happy Learning!
Subscribe to my youtube channel for any DevOps help - yt.openinapp.co/pyjbh
#Linux #DevOps #CloudComputing #Kubernetes #Programming #TechEducation #OpenSource #SysAdmin
3 weeks ago | [YT] | 24
View 1 reply
heydevops_telugu
I am dealing with AWS first time. I am designing the architecture for our applications in organization.
I studied and designed one. I am sharing the picture so please look at it and suggest me if i missed anything in that (or) if anything to added or removed (or) if any mistakes in that.
Please suggest me how many ec2 servers need to launch for this scenario ?
This is what one of my student and I have suggested few of the changes
1) Use an Application Load Balancer (ALB) explicitly
In the diagram it says ELB. For a modern web application, use ALB in front of the web tier, especially for HTTP/HTTPS, path-based routing, and health checks.
2) Keep web tier and app tier in Auto Scaling Groups
That is correct in your diagram. Do not think in terms of fixed EC2 boxes. Think:
Web tier = ASG
App tier = ASG
3) Database should be Multi-AZ
Your DB placement looks fine, but for production I would strongly recommend:
RDS Multi-AZ
Private subnets only
Backups enabled
Read replica only if you really need read scaling
4) NAT Gateway per AZ
If this is production and highly available, place one NAT Gateway in each AZ. A single NAT Gateway is a single point of failure.
5) Some services in the diagram look unnecessary unless you truly need them
These may be valid, but only if your application actually uses them:
CloudFormation: good for provisioning, not part of runtime architecture
SES: only if your app sends email
SNS: only if you need notifications/alerts/integration
DynamoDB: only if you need NoSQL data
PowerShell: not usually shown as an architecture component unless it is part of ops automation
Cache: if needed, show it as ElastiCache (Redis/Memcached)
6) Security groups vs NACLs
Both are fine, but in most application architectures:
Security Groups do most of the real work
NACLs are optional and often kept simple
7) CloudFront + S3
This is good if you serve static content, images, JS/CSS, or downloads.
If the app is mostly internal or not internet-facing, CloudFront may not be required.
If you have read the post till here make sure you share with your community and watch my youtube channel for any job help lnkd.in/gBWK_zpK
4 weeks ago | [YT] | 28
View 0 replies
Load more