क्लाउड इंजीनियरिंग के इंटरव्यू काफी पहले ही ट्रिविया क्विज होना छोड़ चुके हैं। 2026 में लगभग कोई नहीं पूछता कि S3 बकेट और EBS वॉल्यूम में क्या फर्क है। वे आपके हाथ में एक टूटा हुआ VPC थमा देते हैं, या ऐसा Terraform प्लान जो प्रोडक्शन डेटाबेस मिटाने पर तुला है, या रात तीन बजे वाला पेजर सिनेरियो, और देखते हैं कि आप सोचते कैसे हैं। "मैं गूगल कर लेता" तभी गिना जाता है जब आप बता सकें कि क्या सर्च करते और क्यों।
यह गाइड उन सवालों को कवर करती है जिनका सामना क्लाउड इंजीनियर कैंडिडेट अभी सच में कर रहे हैं, AWS, Azure और GCP तीनों पर, और हर सवाल को कैसे संभालें इसका छोटा नोट भी।
2026 में क्लाउड इंजीनियर इंटरव्यू असल में क्या जांचते हैं
यह टाइटल बहुत सारा अंतर छिपा लेता है। 30 लोगों के स्टार्टअप में "क्लाउड इंजीनियर" का मतलब है एक अकेले इंसान की प्लेटफॉर्म टीम, जो Terraform, CI/CD और ऑन-कॉल सब जोड़ रही है। बैंक में वही टाइटल गहरी नेटवर्किंग, कंप्लायंस गार्डरेल और लैंडिंग जोन के काम का मतलब रखता है। जॉब डिस्क्रिप्शन को इम्तिहान का हिस्सा मानकर पढ़िए, क्योंकि लूप उसी तरफ झुकता है जिसमें वह टीम डूबी हुई है।
अंदर के संकेत हमेशा वही रहते हैं। इंटरव्यूअर चार चीजें जांचते हैं: क्लाउड का आपका मानसिक मॉडल (रीजन, अवेलेबिलिटी जोन, एक AZ बंद होने पर क्या-क्या गिरता है); इन्फ्रास्ट्रक्चर ऐज कोड की पकड़ (ज्यादातर Terraform, कुछ जगह CloudFormation और Bicep); ऑपरेशनल सूझबूझ, क्योंकि लागत, सिक्योरिटी और भरोसेमंदी अब अलग से जुड़ी चीजें नहीं बल्कि पूरे-पूरे राउंड हैं; और अनिश्चितता में कम्युनिकेशन, क्योंकि क्लाउड की समस्याएं धुंधली होती हैं और मजबूत कैंडिडेट अपनी मान्यताएं बोलकर बताते चलते हैं।
इंटरव्यू प्रोसेस: असली राउंड
2026 में ज्यादातर क्लाउड लूप चार से छह चरणों के होते हैं, और कुछ लूप देख लेने के बाद इनका आकार पहले से पता चल जाता है।
- रिक्रूटर स्क्रीन (20 से 30 मिनट)। लॉजिस्टिक्स, सैलरी रेंज, और आपने असल में किन क्लाउड पर काम शिप किया है। साफ बोलिए: "तीन साल मुख्य रूप से AWS पर, कुछ GCP" गोलमोल "क्लाउड का अनुभव" से बेहतर है।
- टेक्निकल फोन स्क्रीन (45 से 60 मिनट)। किसी हायरिंग मैनेजर या सीनियर इंजीनियर के साथ लाइव बातचीत: तेज रफ्तार बुनियादी सवाल और एक-दो सिनेरियो।
- हैंड्स-ऑन या टेक-होम। अब यही मुख्य राउंड बनता जा रहा है। एक Terraform मॉड्यूल लिखिए, जानबूझकर तोड़े गए डिप्लॉयमेंट को डीबग कीजिए, या एक छोटी सर्विस खड़ी करके छोटा आर्किटेक्चर नोट लिखिए।
- सिस्टम डिजाइन राउंड (60 मिनट)। एक टिकाऊ और लागत का ध्यान रखने वाला सिस्टम डिजाइन कीजिए। शुद्ध सॉफ्टवेयर रोल के मुकाबले इसमें एल्गोरिदम बहुत कम और ट्रेडऑफ तथा फेल्योर डोमेन बहुत ज्यादा होते हैं।
- व्यवहार / इंसिडेंट राउंड (45 मिनट)। किसी आउटेज, किसी माइग्रेशन, किसी सिक्योरिटी फैसले पर हुए मतभेद के बारे में बताइए। अक्सर यह आपके संभाले किसी असली इंसिडेंट में गहरी खुदाई बन जाता है।
सवाल
बुनियादी बातें
मुझे शुरू से आखिर तक बताइए कि जब कोई यूजर Application Load Balancer के पीछे बैठे ऐप तक पहुंचता है तो क्या-क्या होता है। कैसे संभालें: DNS रिजॉल्यूशन, TLS टर्मिनेशन, लोड बैलेंसर का टारगेट ग्रुप और हेल्थ चेक, रास्ते में पड़ने वाले सिक्योरिटी ग्रुप और सबनेट, फिर कंप्यूट और उसका डेटा स्टोर से जुड़ाव। साथ में बताइए कि हर हिस्सा कहां फेल हो सकता है।
रीजन और अवेलेबिलिटी जोन का फर्क समझाइए, फिर एक AZ खोने को ध्यान में रखकर डिजाइन कीजिए। कैसे संभालें: दोनों की कसी हुई परिभाषा दीजिए, फिर नतीजा दिखाइए। स्टेटफुल सर्विस के लिए मल्टी-AZ (RDS Multi-AZ, तीन AZ में कोरम), और लोड बैलेंसर के पीछे फैला हुआ स्टेटलेस कंप्यूट। यह भी साफ कीजिए कि मल्टी-रीजन एक अलग और महंगी बातचीत है, जो RTO और RPO पर टिकी है, कोई डिफॉल्ट नहीं।
शेयर्ड रिस्पॉन्सिबिलिटी मॉडल क्या है, और इंजीनियर इसमें कहां गलती करते हैं? कैसे संभालें: प्रोवाइडर क्लाउड को सुरक्षित रखता है, आप उसमें जो डालते हैं उसे। आम चूक यह मान लेना है कि मैनेज्ड सर्विस का मतलब मैनेज्ड सिक्योरिटी है। कोई पब्लिक S3 बकेट या हद से चौड़ा IAM आपकी समस्या है, प्रोवाइडर की नहीं।
इन्फ्रास्ट्रक्चर ऐज कोड
आपका terraform plan प्रोडक्शन का RDS इंस्टेंस मिटाकर दोबारा बनाना चाहता है। आप क्या करेंगे?
कैसे संभालें: apply मत कीजिए। प्लान पढ़कर पता कीजिए कि कौन सा एट्रिब्यूट रिप्लेसमेंट पर मजबूर कर रहा है (कोई न बदलने वाला फील्ड, कोई इंजन वर्जन, कोई AZ बदलाव)। काम में लाइए create_before_destroy, lifecycle ब्लॉक, और state mv या import, रिकवरी के औजार की तरह। प्रोड प्लान में destroy दिखना काम रोक देने वाली घटना है।
तीन एनवायरनमेंट में पंद्रह इंजीनियरों के लिए आप Terraform state कैसे संभालेंगे?
कैसे संभालें: रिमोट बैकएंड (S3 के साथ DynamoDB लॉकिंग, या Terraform Cloud), हर एनवायरनमेंट के लिए अलग state, और ब्लास्ट रेडियस पर काबू ताकि स्टेजिंग का कोई बदलाव कभी प्रोड state को छू न सके। लीस्ट प्रिविलेज वाले CI क्रेडेंशियल और शेड्यूल किए गए plan से ड्रिफ्ट पकड़ने पर अलग से नंबर, जो diff आने पर फेल हो जाए।
नेटवर्किंग, सिक्योरिटी और IAM
दो AZ में पब्लिक और प्राइवेट सबनेट वाला एक VPC डिजाइन कीजिए, और रूटिंग समझाइए। कैसे संभालें: इसे बनाकर दिखाइए। VPC के लिए एक CIDR ब्लॉक, इंटरनेट गेटवे तक जाने वाले पब्लिक सबनेट, NAT गेटवे से बाहर जाने वाले प्राइवेट सबनेट, और हर टियर के लिए अलग रूट टेबल। अगला सवाल तय है: प्राइवेट इंस्टेंस पब्लिक इंटरनेट के बिना क्लाउड API तक कैसे पहुंचेंगे (VPC एंडपॉइंट)?
प्राइवेट सबनेट में बैठा एक EC2 इंस्टेंस इंटरनेट तक नहीं पहुंच पा रहा। आप इसे कैसे डीबग करेंगे? कैसे संभालें: यह ढांचेदार ट्रबलशूटिंग का सवाल है, ट्रिविया का नहीं। परतों में बाहर की तरफ बढ़िए: सिक्योरिटी ग्रुप का egress, नेटवर्क ACL, सबनेट का रूट टेबल, NAT गेटवे की सेहत और IGW तक उसका रूट, फिर DNS। इसे एक चेकलिस्ट की तरह बोलकर बताइए और हर कदम पक्का करने वाला टूल भी नाम लीजिए (reachability analyzer, flow logs)।
किसी एप्लिकेशन को एक S3 बकेट का रीड एक्सेस चाहिए। आप यह कैसे देंगे?
कैसे संभालें: कंप्यूट पर एक IAM रोल (इंस्टेंस प्रोफाइल, EKS पर IRSA, या वर्कलोड आइडेंटिटी) जिस पर उसी बकेट और प्रीफिक्स तक कसी हुई पॉलिसी लगी हो। जाल वाले जवाब, यानी ऐप के भीतर लंबे समय तक चलने वाली एक्सेस key, या s3:* और Resource: *, छूते ही फेल हो जाते हैं। "least privilege" बोलकर कहिए।
क्लाउड नेटिव ऐप के सीक्रेट आप कहां रखते हैं और कैसे बदलते हैं? कैसे संभालें: कोई मैनेज्ड सीक्रेट स्टोर (Secrets Manager, Parameter Store, या Vault), जिससे वर्कलोड की अपनी आइडेंटिटी के जरिए रनटाइम पर सीक्रेट लिए जाएं, कभी git में कमिट न हों और न ही इमेज में पकाए जाएं। नियम यह है कि ऐप कभी कोई स्थिर, लंबे समय तक चलने वाला क्रेडेंशियल अपने पास न रखे।
ऑपरेशन, भरोसेमंदी और लागत
प्रोडक्शन की लेटेंसी अभी तीन गुना हो गई है और आपको पता नहीं क्यों। अपने पहले दस मिनट बताइए। कैसे संभालें: यह इंसिडेंट रिस्पॉन्स का संकेत है। पहले स्वीकार कीजिए और सबको बताइए, गोल्डन सिग्नल पढ़िए (लेटेंसी, ट्रैफिक, एरर, सैचुरेशन), हाल के डिप्लॉय देखिए, और जब तक कस्टमर तकलीफ में हैं तब तक रूट कॉज ढूंढने के बजाय राहत देने को तरजीह दीजिए (रोलबैक, स्केल आउट)। शांत रहना घबराने से बेहतर है।
ट्रैफिक बदले बिना महीने का बिल 40 प्रतिशत बढ़ गया। आप वजह कैसे ढूंढेंगे? कैसे संभालें: कॉस्ट एलोकेशन टैग, सर्विस और अकाउंट के हिसाब से बंटा कॉस्ट एक्सप्लोरर, और वही पुराने अपराधी (लावारिस वॉल्यूम, खाली बैठे लोड बैलेंसर, क्रॉस-AZ या egress ट्रांसफर, बेकाबू ऑटोस्केलिंग ग्रुप, भूले हुए डेव एनवायरनमेंट)। लागत को एक इंजीनियरिंग मेट्रिक मानिए जिसके मालिक तय हों।
बैकअप और डिजास्टर रिकवरी को लेकर आपका तरीका क्या है, और आपको कैसे पता कि वे काम करते हैं? कैसे संभालें: पहले RTO और RPO तय कीजिए, फिर उन्हें किसी रणनीति से जोड़िए (स्नैपशॉट, क्रॉस-रीजन रेप्लिकेशन, कोड से दोबारा खड़ा हो सकने वाला इन्फ्रा)। जो लाइन असर करती है: जिस बैकअप को आपने कभी रिस्टोर नहीं किया, वह बैकअप नहीं, उम्मीद है।
व्यवहार और इंसिडेंट की गहराई
आप जिस सबसे बुरे प्रोडक्शन इंसिडेंट का हिस्सा रहे, उसके बारे में बताइए। उसमें आपकी भूमिका क्या थी, और बाद में क्या बदला? कैसे संभालें: कोई असली इंसिडेंट चुनिए और उसे इस ढांचे में रखिए: स्थिति, आपके अपने कदम, समाधान, और उसके बाद हुआ सिस्टम स्तर का फिक्स तथा बिना दोषारोपण वाला पोस्टमॉर्टम। वे जिम्मेदारी और सीख खोज रहे हैं, यह नहीं कि आपने कभी कुछ तोड़ा है या नहीं।
किसी ऐसे मौके का वर्णन कीजिए जब आप किसी सिक्योरिटी या आर्किटेक्चर फैसले से असहमत थे। कैसे संभालें: दिखाइए कि आप डेटा के साथ असहमत हो सकते हैं और फिर फैसले के साथ खड़े हो सकते हैं। परिपक्व रूप वह है जिसमें आपकी बात नहीं मानी गई और सब ठीक ही रहा, न कि वह कहानी जिसमें आपने चुपचाप कोई जुगाड़ खड़ा कर लिया।
आम गलतियां जो क्लाउड इंजीनियर कैंडिडेट को डुबो देती हैं
- ट्रेडऑफ बताए बिना सर्विस के नाम गिनाना। "मैं Kubernetes इस्तेमाल करूंगा" कोई जवाब नहीं है। ECS क्यों नहीं, या Lambda, या एक सादा ऑटोस्केलिंग ग्रुप? इस रोल में सूझबूझ चाहिए, शब्दावली नहीं।
- लागत को नजरअंदाज करना। बारह यूजर वाले किसी अंदरूनी टूल के लिए पांच रीजन का एक्टिव-एक्टिव डिजाइन करना बताता है कि आपने कभी कोई बिल नहीं संभाला।
- बहाना मारना। जिस सर्विस को आपने इस्तेमाल नहीं किया उस पर बहाना दूसरे ही फॉलो-अप में बिखर जाता है। "मैंने Aurora प्रोड में नहीं चलाया, पर मैं इस पर ऐसे सोचूंगा" ज्यादा भरोसा कमाता है।
- फिक्स का अंदाजा लगाना। टूटे VPC वाले सवाल में सही अंदाजा भी किस्मत ही लगता है। परत दर परत, बोलकर की गई ट्रबलशूटिंग काबिलियत लगती है।
- सिक्योरिटी को बाद की चीज मानना। डिजाइन राउंड में IAM और सीक्रेट को आखिर के लिए छोड़ देना 2026 में लाल झंडा है।
तैयारी कैसे करें (और लाइव कोपायलट कहां काम आता है)
सिर्फ पढ़िए मत, बनाइए। एक फ्री टियर अकाउंट खोलिए, ऐसा Terraform मॉड्यूल लिखिए जो पब्लिक और प्राइवेट सबनेट वाला VPC खड़ा करे, फिर जानबूझकर रूटिंग तोड़िए और ठीक कीजिए। यह अकेला अभ्यास ऊपर के एक तिहाई सवाल कवर कर लेता है।
सिनेरियो वाले सवालों की बोलकर प्रैक्टिस कीजिए, क्योंकि क्लाउड इंटरव्यू बोलकर समझाने को इनाम देते हैं। "इंसिडेंट के पहले दस मिनट" वाले जवाब को तब तक दोहराना कि वह बहने लगे, उन सर्विस लिमिट को रटने से बेहतर है जिन्हें आप देख सकते हैं। अपने इतिहास को व्यवहार वाले सवालों से भी जोड़िए: एक आउटेज की कहानी, एक माइग्रेशन, एक मतभेद, ढांचे में और तैयार।
लाइव राउंड के लिए, जहां सवाल आपके पूरा जवाब गढ़ने से भी तेज आते हैं, एक रियल-टाइम कोपायलट धार कम कर देता है। GhostPilot Chrome साइड पैनल में चलता है और इंटरव्यू सुनता है, और सवाल आते ही एक स्ट्रक्चर्ड प्रॉम्प्ट सामने रख देता है: डीबगिंग वाले सवाल में कौन सी परतें जांचनी हैं, डिजाइन वाले सवाल में कौन से ट्रेडऑफ गिनाने हैं, और लागत या सिक्योरिटी का वह पहलू जो दबाव में भूल सकते हैं। यह आपको ढांचा देता है, पढ़ने के लिए स्क्रिप्ट नहीं, इसलिए जिया हुआ अनुभव आप ही अपनी आवाज में डालते हैं। और जानकारी ghostpilotai.com पर।
FAQ
एंट्री लेवल क्लाउड इंजीनियर इंटरव्यू के लिए मुझे किस पर ध्यान देना चाहिए? चौड़ाई से ज्यादा बुनियाद पर। किसी एक क्लाउड के मुख्य कंप्यूट, स्टोरेज और नेटवर्किंग हिस्सों को पक्का जानिए, IAM और शेयर्ड रिस्पॉन्सिबिलिटी मॉडल समझिए, और एक बुनियादी Terraform कॉन्फिग लिखिए। जूनियर लूप स्केल की कमियां माफ कर देते हैं, बशर्ते आपकी बुनियाद ठोस हो।
2026 में मुझे कितने क्लाउड सर्टिफिकेशन चाहिए? एक एसोसिएट लेवल सर्टिफिकेशन (जैसे AWS Solutions Architect Associate) रिज्यूमे स्क्रीन पार करने में मदद करता है, खासकर जब अनुभव ज्यादा न हो। उसके बाद सर्टिफिकेशन का फायदा तेजी से घटने लगता है। एक छोटा Terraform पोर्टफोलियो और एक असली प्रोजेक्ट, जिस पर आप बात कर सकें, बैज की दीवार से बेहतर है।
क्या क्लाउड इंजीनियर इंटरव्यू में अब भी LeetCode जैसी कोडिंग होती है? सॉफ्टवेयर रोल से कम, पर बिल्कुल नहीं ऐसा भी नहीं। कठिन एल्गोरिदम से ज्यादा हल्की स्क्रिप्टिंग मानकर चलिए (लॉग पार्स करने या किसी API को कॉल करने के लिए Python या Bash)। प्लेटफॉर्म और SRE की तरफ झुके रोल में कोई डेटा स्ट्रक्चर वाला सवाल जुड़ सकता है, पर हावी IaC और सिनेरियो डिजाइन ही रहते हैं।
क्लाउड इंजीनियर का इंटरव्यू DevOps या SRE इंटरव्यू से कैसे अलग है? ओवरलैप काफी है। क्लाउड इंजीनियर प्रोविजनिंग, IaC और प्रोवाइडर सर्विस की तरफ झुकता है। SRE भरोसेमंदी के गणित, SLO और ऑन-कॉल की सख्ती की तरफ। DevOps CI/CD और डेवलपर एक्सपीरियंस की तरफ। एक ही लूप अक्सर तीनों के लिए चलता है, और जो चीज हर जगह मजबूत कैंडिडेट को डुबोती है वह है ट्रेडऑफ के बजाय सर्विस के नाम गिनाना।
GhostPilot AI आजमाएं
क्लाउड इंटरव्यू तेज चलते हैं और सिनेरियो वाले सवालों का शायद ही कोई एक साफ जवाब होता है, और ठीक यहीं एक रियल-टाइम प्रॉम्प्ट आपको दबाव में ढांचे में बनाए रखता है। GhostPilot Chrome साइड पैनल में चलता है, इसलिए जब आप एक टैब शेयर करते हैं तो यह कैप्चर होने वाली चीज का हिस्सा नहीं होता, और वैकल्पिक Windows डेस्कटॉप ऐप Windows 10 (बिल्ड 2004 या उसके बाद) और Windows 11 पर स्क्रीन कैप्चर में नहीं दिखता। 10 मिनट के लाइव सेशन और अनलिमिटेड AI जवाब के साथ फ्री शुरू कीजिए, $29 में Session Pass लीजिए (दो-दो घंटे के तीन पूरे इंटरव्यू, एक बार, कोई सब्सक्रिप्शन नहीं), या $59/माह या $192/साल ($16/माह सालाना बिलिंग पर) में Pro लीजिए।