AWS इंजीनियरों के लिए GCP: आपके AWS के सहज ज्ञान कैसे काम करते हैं (और कहाँ वे टूट जाते हैं)

यदि आप AWS में पारंगत हैं और अब Google Cloud को देख रहे हैं, तो अच्छी खबर यह है कि आपके लगभग 80% सहज ज्ञान सीधे स्थानांतरित हो जाते हैं: चीजों को व्यवस्थित करने के लिए एक पदानुक्रम है, एक्सेस देने का एक भूमिका-आधारित तरीका है, कीलेस CI के लिए एक OIDC कहानी है, और एक "अपने स्टेट बैकएंड को कोल्ड-स्टार्ट करें" बूटस्ट्रैप प्रक्रिया है। बुरी खबर बाकी 20% है - और यह कुछ उच्च-ट्रैफ़िक वाले स्थानों पर केंद्रित है जहाँ AWS वाला काम करने से स्पष्ट त्रुटि के बजाय भ्रमित करने वाली अस्वीकृति मिलती है। यह पोस्ट अनुवाद परत है: वही काम जो आप AWS में करते हैं, GCP में किए गए, जिसमें आने वाली बाधाओं को उजागर किया गया है।

संक्षेप में, यदि आप केवल एक पैराग्राफ पढ़ते हैं तो: GCP का पदानुक्रम (organization -> folder -> project -> resource) AWS Organizations -> OU -> account -> resource पर स्पष्ट रूप से मैप होता है, लेकिन तीन चीजें आपकी मांसपेशी स्मृति को तोड़ देती हैं। IAM एक केवल-अनुमति नीति है जो संसाधन ट्री से बंधी होती है और नीचे की ओर विरासत में मिलती है - उपयोगकर्ता से कोई नीति संलग्न नहीं होती है। एक project की सेवा APIs सभी बंद स्थिति में शुरू होती हैं, और जब तक आप प्रत्येक को सक्षम नहीं करते, तब तक कुछ भी काम नहीं करता। और आप भूमिकाएँ नहीं मानते, आप service accounts का प्रतिरूपण करते हैं, जो स्वयं अपनी एक्सेस नीति वाले संसाधन हैं। नीचे सब कुछ इन्हीं का विस्तार करता है।

सबसे बड़ा बदलाव: अनुमतियाँ ट्री पर रहती हैं, पहचान पर नहीं

AWS में, मानसिक मॉडल "एक पहचान से एक नीति संलग्न करें" है। आप एक उपयोगकर्ता या एक भूमिका बनाते हैं, उस पर JSON लगाते हैं, और अनुमति प्रिंसिपल के साथ यात्रा करती है। संसाधन नीतियाँ मौजूद हैं, लेकिन पहचान-संलग्न नीति गुरुत्वाकर्षण का केंद्र है।

GCP इसे उलट देता है। एक IAM नीति बाइंडिंग का एक सेट है - (member, role) जोड़े - जो संसाधन पदानुक्रम में एक नोड से जुड़े होते हैं (organization, folder, project, या एक व्यक्तिगत resource)। नीति एक्सेस की जा रही चीज़ पर रहती है, न कि एक्सेस करने वाली पहचान पर। किसी भी बिंदु पर आपकी प्रभावी एक्सेस उस नोड तक रूट से विरासत में मिली हर बाइंडिंग का संघ है। folder स्तर पर एक समूह को roles/compute.admin प्रदान करें और उस folder के तहत हर project इसे विरासत में प्राप्त करेगा।

यदि आपने Azure RBAC का उपयोग किया है तो यह परिचित लगेगा - यह नीचे की ओर विरासत के साथ भूमिका-एट-ए-स्कोप है। वह नियम जो आपको बचाता है:

जब GCP किसी चीज़ को अस्वीकार करता है, तो "उपयोगकर्ता पर नीति" की तलाश बंद कर दें। org, folder, project, या resource पर बाइंडिंग देखें - और याद रखें कि यह नीचे की ओर विरासत में मिलता है, इसलिए महत्वपूर्ण अनुमति तीन स्तर ऊपर हो सकती है।

कुछ विशिष्ट बातें जो AWS से भिन्न हैं:

• भूमिकाएँ तीन ग्रेड में आती हैं। Primitive भूमिकाएँ (roles/owner, roles/editor, roles/viewer) मोटे विरासत वाले तिकड़ी हैं - वास्तविक संपत्तियों में उनसे बचें। Predefined भूमिकाएँ वे बारीक-दानेदार प्रति-सेवा भूमिकाएँ हैं जिनका आपको वास्तव में उपयोग करना चाहिए (roles/storage.objectViewer, roles/compute.instanceAdmin.v1, ...)। Custom भूमिकाएँ आपकी हैं जब पूर्वनिर्धारित सेट बहुत व्यापक हो।
• आधार मॉडल योगात्मक और केवल-अनुमति वाला है। AWS में हर नीति में Effect: Deny बुना हुआ नहीं होता है। प्रभावी एक्सेस केवल अनुमतियों का संघ है।
• अस्वीकृति एक अलग परत है। जब आपको वास्तव में एक कठोर "कभी नहीं, अनुदान की परवाह किए बिना" की आवश्यकता होती है, तो आप एक IAM deny policy लिखते हैं - एक अलग ऑब्जेक्ट जो org/folder/project से जुड़ा होता है जिसे अनुमतियों से पहले मूल्यांकन किया जाता है। यह एक इनलाइन Deny स्टेटमेंट के सबसे करीब है, लेकिन यह जानबूझकर आउट-ऑफ-बैंड है।
• गार्डरेल्स फिर से एक तीसरी चीज़ हैं: Organization Policy Service। constraints/compute.vmExternalIpAccess या constraints/iam.disableServiceAccountKeyCreation जैसे प्रतिबंध SCPs के GCP एनालॉग हैं। वे org/folder/project पर संलग्न होते हैं, नीचे की ओर विरासत में मिलते हैं, और प्रतिबंधित करते हैं कि क्या मौजूद हो सकता है या कॉन्फ़िगर किया जा सकता है बजाय इसके कि कौन क्या कॉल कर सकता है। "SCP-आकार के गार्डरेल" के बारे में सोचें, न कि "IAM भूमिका" के बारे में।

तो जहाँ AWS आपको IAM के भीतर एक अनुमति/अस्वीकृति व्याकरण देता है, GCP इस काम को अनुमति बाइंडिंग, अस्वीकृति नीतियों और org-नीति बाधाओं में फैलाता है। परिणाम समान, तंत्र तीन।

सब कुछ एक project है - और इसकी APIs बंद स्थिति में शुरू होती हैं

project GCP की मूलभूत इकाई है। यह एक AWS account का मोटा एनालॉग है: एक अलगाव सीमा, एक IAM स्कोप, और एक बिलिंग लक्ष्य एक साथ। लेकिन एक project एक account की तुलना में कहीं अधिक हल्का है - बनाने में सस्ता, हटाने में आसान, दर्जनों में बनाने के लिए अभिप्रेत है। मुहावरेदार पैटर्न प्रति वातावरण प्रति वर्कलोड एक project है (app-qa, app-prod), न कि टैग द्वारा विभाजित कुछ साझा accounts।

projects के बारे में तीन बातें जिनका कोई स्पष्ट AWS समकक्ष नहीं है:

• एक project के तीन पहचानकर्ता होते हैं, और अंतर परेशान करते हैं। project ID एक विश्व स्तर पर अद्वितीय, मानव-चुनी हुई, अपरिवर्तनीय स्ट्रिंग है (acme-app-prod-7f3a) - यह वह है जिसे आप लगभग हर कमांड और संसाधन पथ में डालते हैं। project number एक विश्व स्तर पर अद्वितीय पूर्णांक है जिसे GCP असाइन करता है। display name परिवर्तनीय और कॉस्मेटिक है। ID को ध्यान से चुनें; आप इसे कभी नहीं बदल सकते।
• Service APIs डिफ़ॉल्ट रूप से बंद होती हैं। यह सबसे आम पहले दिन की समस्या है। VM बनाने से पहले, आप compute.googleapis.com सक्षम करते हैं; एक बकेट से पहले, storage.googleapis.com; और इसी तरह, प्रति project। GCP पर आपकी पहली "अस्वीकृति" आमतौर पर एक गुम IAM भूमिका नहीं होती है - यह API [compute.googleapis.com] not enabled on project होती है। AWS में, सेवाएँ बस मौजूद होती हैं; GCP में, हर project एक खाली स्लेट होता है और आप ठीक वही सतह चालू करते हैं जिसका आप उपयोग करना चाहते हैं। (Terraform में यह google_project_service है; CLI से, gcloud services enable।)
• Projects प्राकृतिक ब्लास्ट-रेडियस और कोटा सीमा हैं। कोटा, बजट और अधिकांश डिफ़ॉल्ट प्रति project होते हैं, इसलिए एक प्रयोग के लिए एक नया project शुरू करना सामान्य, सस्ता कदम है - न कि AWS account जैसी औपचारिकता।

Service accounts: आप प्रतिरूपण करते हैं, आप मानते नहीं हैं

AWS में, एक भूमिका अनुमतियों का एक सेट है जिसे एक प्रिंसिपल STS के माध्यम से मानता है, जो एक ट्रस्ट नीति द्वारा नियंत्रित होता है। GCP में समकक्ष कार्यवाहक service account (SA) है, और यह इस तरह से अलग तरह से काम करता है जो हर AWS इंजीनियर को भ्रमित करता है।

एक service account एक पहचान और एक संसाधन दोनों है। इसका एक ईमेल (deployer@acme-app-prod.iam.gserviceaccount.com) है, यह एक project के अंदर रहता है, और - महत्वपूर्ण रूप से - इसकी अपनी IAM नीति है जो यह नियंत्रित करती है कि इसका उपयोग कौन कर सकता है। वह दूसरा आधा हिस्सा है जिसमें कोई AWS रिफ्लेक्स नहीं है:

• एक service account के रूप में कार्य करने के लिए, एक प्रिंसिपल को SA पर ही एक भूमिका की आवश्यकता होती है - roles/iam.serviceAccountTokenCreator (कम समय तक चलने वाले टोकन बनाने और उसका प्रतिरूपण करने के लिए) या roles/iam.serviceAccountUser (इसे आपके द्वारा बनाए जा रहे संसाधन से जोड़ने के लिए, जैसे VM या Cloud Run सेवा)। यह दो-तरफा अनुदान है जिसे AWS के लोग भूल जाते हैं: आपके CI प्रिंसिपल को व्यापक project अधिकार देना बेकार है यदि वह deployer SA नहीं बन सकता।
• आप एक SA का प्रतिरूपण एक टोकन (generateAccessToken) मांगकर करते हैं, न कि ट्रस्ट-नीति हैंडशेक के साथ एक भूमिका मानकर। प्रतिरूपण करने की अनुमति SA संसाधन पर एक साधारण IAM बाइंडिंग के रूप में रहती है - कोई अलग ट्रस्ट दस्तावेज़ नहीं होता है।
• Service account keys मौजूद हैं और आपको उनसे ज्यादातर बचना चाहिए। एक डाउनलोड की गई JSON कुंजी एक लंबे समय तक चलने वाली क्रेडेंशियल और एक क्लासिक लीक वेक्टर है; कई orgs पहले उल्लिखित बाधा के माध्यम से org-व्यापी कुंजी निर्माण को अक्षम करते हैं। कीलेस विकल्प वे हैं जिनकी आपको तलाश करनी चाहिए।
• कीलेस CI Workload Identity Federation है - AWS के OIDC फेडरेशन जैसा ही OIDC विचार। आपके GitHub Actions या बाहरी वर्कलोड एक OIDC टोकन प्रस्तुत करते हैं, एक वर्कलोड आइडेंटिटी पूल जारीकर्ता पर भरोसा करता है, और GCP एक SA के लिए अल्पकालिक क्रेडेंशियल वापस देता है। कोई संग्रहीत रहस्य नहीं। (GKE के अंदर, एनालॉग Workload Identity है, जो एक Kubernetes service account को एक Google service account से बांधता है - AWS के IRSA का सीधा प्रतिरूप।)

एक-पंक्ति अनुवाद: एक AWS भूमिका जिसे आप ट्रस्ट नीति के माध्यम से मानते हैं वह एक GCP service account बन जाती है जिसे आप SA पर एक टोकन-निर्माता बाइंडिंग के माध्यम से प्रतिरूपित करते हैं।

पहचान डोमेन: Cloud Identity, Workspace, और org

GCP पहचान को संसाधनों से अलग करता है, लेकिन Azure की तुलना में कहीं अधिक धीरे से। organization node एक सत्यापित डोमेन के विरुद्ध बनाया जाता है जो एक Cloud Identity या Google Workspace account के स्वामित्व में होता है। वह निर्देशिका - उपयोगकर्ता और समूह - Admin console (admin.google.com) में प्रशासित होती है, जो Cloud console से एक अलग सतह है जहाँ आप संसाधनों का प्रबंधन करते हैं।

• उपयोगकर्ता और समूह निर्देशिका में बनाए जाते हैं; IAM में एक्सेस प्रदान की जाती है। आप "GCP उपयोगकर्ता" उस तरह से नहीं बनाते जिस तरह से आप AWS में एक IAM उपयोगकर्ता बनाते हैं। मानव Cloud Identity/Workspace में मौजूद होता है (या आपके IdP से फेडरेटेड होता है), और आप उन्हें - आदर्श रूप से एक समूह के रूप में - संसाधन ट्री पर IAM बाइंडिंग में संदर्भित करते हैं। सर्वोत्तम अभ्यास समूहों के लिए बाइंडिंग है, कभी भी व्यक्तिगत उपयोगकर्ताओं के लिए नहीं।
• AWS के पास जैसा कोई स्वतंत्र "IAM users" स्टोर नहीं है। बाहरी IdPs (Okta, Entra ID, और इसी तरह) Cloud Identity में फेडरेट होते हैं; यह कार्यबल एक्सेस के लिए सामान्य है।
• याद रखने योग्य दो फुटगन: विशेष सदस्य allUsers (शाब्दिक रूप से इंटरनेट पर कोई भी, अप्रमाणित) और allAuthenticatedUsers (किसी भी Google account वाला कोई भी व्यक्ति)। किसी भी एक को भूमिका से बांधना ही बकेट के गलती से सार्वजनिक होने का तरीका है। उनके साथ वैसा ही व्यवहार करें जैसा आप S3 बकेट नीति पर Principal: "*" के साथ करते हैं।

ढीली सादृश्यता: organization और उसका Cloud Identity डोमेन मोटे तौर पर "IAM Identity Center की निर्देशिका के साथ जुड़ा हुआ एक AWS Organization" है - लेकिन दिन-प्रतिदिन का संसाधन कार्य ट्री पर IAM बाइंडिंग के माध्यम से होता है, न कि पहचान-संलग्न नीति के माध्यम से।

बिलिंग एक अलग ऑब्जेक्ट है जिसे आप projects से लिंक करते हैं

GCP में एक billing account अपना स्वयं का संसाधन है - यह org -> folder -> project पदानुक्रम में एक नोड नहीं है। Projects एक billing account से लिंक होते हैं (प्रत्येक project ठीक एक से), और एक एकल billing account कई projects को वित्त पोषित कर सकता है।

• इसका अपना IAM है। roles/billing.admin, roles/billing.user, roles/billing.creator billing account पर रहते हैं, आपके संसाधन भूमिकाओं से अलग। विशेष रूप से, एक नए project को एक billing account से जोड़ने के लिए आपको उस billing account पर roles/billing.user की आवश्यकता होती है - केवल व्यापक project अधिकार यह काम नहीं करेंगे।
• "मैं डिप्लॉय कर सकता हूँ" आपको "मैं एक शुल्क योग्य project बना सकता हूँ" के बारे में कुछ नहीं बताता है। एक ऐसा project स्थापित करने के लिए जिस पर शुल्क लग सकता है, आपको resourcemanager.projectCreator (org/folder पर) और billing.user (billing account पर) दोनों की आवश्यकता होती है। दूसरे को छोड़ दें और project निर्माण आधा सफल हो जाता है, जिससे एक ऐसा project बनता है जो वास्तव में कुछ भी नहीं चला सकता।

यह Azure की कठोर वाणिज्य-प्लेन दीवार से नरम है - GCP बिलिंग Cloud IAM से जुड़ी हुई है, इसलिए यह पूरी तरह से अलग दुनिया के बजाय समान gcloud और Terraform सतहों में दिखाई देती है। लेकिन यह अभी भी अलग भूमिकाओं वाला एक अलग ऑब्जेक्ट है, और यह अक्षम APIs के बाद दूसरा सबसे आम "लेकिन मैं एक एडमिन हूँ" आश्चर्य है।

नाम, ID, और एक नेटवर्किंग आश्चर्य

प्रत्येक GCP resource का एक सापेक्ष संसाधन नाम होता है जैसे projects/acme-app-prod/zones/us-central1-a/instances/web-1 (और एक पूरी तरह से योग्य //compute.googleapis.com/... रूप)। project ID हर लॉग लाइन और API कॉल के साथ यात्रा करती है - वही काम जो AWS में एक ARN का account करता है - इसलिए, Azure की तरह, आपके संसाधन नाम वह छोड़ सकते हैं जो project पहले से ही एन्कोड करता है। वही छोटे नाम आपके -dev, -qa, और -prod projects में सुरक्षित रूप से दोहराए जा सकते हैं।

नेटवर्किंग की एक महत्वपूर्ण बात जिसे पहले ही उजागर करना चाहिए, क्योंकि यह चुपचाप AWS के सहज ज्ञान का उल्लंघन करती है: GCP में एक VPC नेटवर्क एक वैश्विक संसाधन है, और इसके सबनेट क्षेत्रीय हैं। AWS में एक VPC एक क्षेत्र तक सीमित होता है; GCP में एक VPC हर क्षेत्र में फैला होता है, और आप इसके अंदर क्षेत्रीय सबनेट बनाते हैं। क्षेत्रीय सबनेट के साथ एक एकल वैश्विक VPC डिफ़ॉल्ट है, न कि एक विदेशी बहु-क्षेत्रीय सेटअप - VPC पीयरिंग के लिए न पहुँचें जो एक सबनेट आपको पहले से ही देता है।

AWS -> GCP त्वरित मानचित्र

पहले महीने के लिए इसे अपने पास रखें:

• Organization -> organization। वही विचार, लेकिन GCP org आपके Cloud Identity/Workspace डोमेन से बंधा हुआ है।
• Organizational Unit (OU) -> folder। नेस्टेबल ग्रुपिंग नोड; folders में folders हो सकते हैं।
• Account -> project। अलगाव, IAM, और बिलिंग इकाई - लेकिन हल्का और डिस्पोजेबल, दर्जनों में बनाया गया।
• SCP (गार्डरेल) -> Organization Policy constraint एक org/folder/project स्कोप पर - प्रतिबंधित करता है कि क्या मौजूद हो सकता है या कॉन्फ़िगर किया जा सकता है, नीचे की ओर विरासत में मिलता है।
• IAM identity-attached policy -> एक ट्री नोड पर IAM binding (member, role)। उपयोगकर्ता पर कोई नीति नहीं; अनुदान संसाधन पर रहता है और नीचे की ओर विरासत में मिलता है।
• IAM भूमिका जिसे आप मानते हैं (STS + ट्रस्ट नीति के माध्यम से) -> service account जिसका आप प्रतिरूपण करते हैं (SA पर एक टोकन-निर्माता बाइंडिंग के माध्यम से)। दो-तरफा अनुदान याद रखें।
• स्पष्ट Deny स्टेटमेंट -> IAM deny policy - एक अलग ऑब्जेक्ट, अनुमतियों से पहले मूल्यांकन किया जाता है।
• IRSA (IAM Roles for Service Accounts) -> Workload Identity (GKE) / Workload Identity Federation (बाहरी CI) - वही OIDC विचार, कीलेस।
• "सेवा बस उपलब्ध है" -> पहले प्रति project इसकी API सक्षम करें (google_project_service)। कोई AWS समकक्ष नहीं।
• लॉग में ARN -> संसाधन नाम (projects/<id>/...); project संदर्भ संरचित है, नाम-एन्कोडेड नहीं।

Terraform स्टेट को बूटस्ट्रैप करना, अनुवादित

यह एक ऐसी जगह है जहाँ आपकी AWS रनबुक लगभग काम करती है, फिर शून्य कदम पर टूट जाती है।

आप जिस AWS बूटस्ट्रैप को जानते हैं: प्रबंधन account में एक state backend को कोल्ड-स्टार्ट करें (स्थानीय state, फिर backend को स्वयं में माइग्रेट करें), प्रति-OU backends की state को उस रूट backend में रखें, और अपने स्वयं के backends का उपयोग करके सदस्य accounts बनाएं। वह अपरिवर्तनीय जो इसे साफ बनाता है वह यह है कि आप हमेशा प्रबंधन account से बूटस्ट्रैप कर सकते हैं, क्योंकि यह हमेशा मौजूद रहता है और एक S3 बकेट रख सकता है।

GCP उस अपरिवर्तनीय को उत्पत्ति पर उसी तरह तोड़ता है जैसे Azure करता है: हमेशा मौजूद रहने वाला ऑब्जेक्ट organization है, लेकिन एक org नोड संसाधन नहीं रख सकता। एक GCS बकेट एक project में रहता है, और एक project को एक पैरेंट और (कुछ भी वास्तविक करने के लिए) एक बिलिंग लिंक और सक्षम APIs की आवश्यकता होती है। तो GCP का "रूट account" एक सीड project है जिसे आप जानबूझकर ताज पहनाते हैं - मुहावरेदार नाम prj-bootstrap या एक Cloud Foundation Toolkit सीड project जैसा कुछ है।

अनुवादित प्रवाह, जब org और एक billing account पहले से मौजूद हों (सामान्य मामला):

1. एक कोल्ड-स्टार्ट, हमेशा के लिए: सीड project को अनिवार्य रूप से बनाएं (gcloud projects create), उस पर बूटस्ट्रैप APIs सक्षम करें (cloudresourcemanager, cloudbilling, serviceusage, iam, storage), बिलिंग लिंक करें, और स्थानीय Terraform state के साथ GCS state बकेट बनाएं - फिर init -migrate-state को उस बकेट में माइग्रेट करें।
2. org-स्तर की भूमिकाओं वाला एक बूटस्ट्रैप service account: इसे resourcemanager.projectCreator, billing.user, और आपकी org-नीति/IAM एडमिन भूमिकाएँ organization नोड पर प्रदान करें, ताकि यह हर डाउनस्ट्रीम project को बना और नियंत्रित कर सके।
3. बाकी सब एक सामान्य अप्लाई है: अतिरिक्त projects, folders, और उनके संसाधन Terraform द्वारा उस बूटस्ट्रैप SA का प्रतिरूपण करके बनाए जाते हैं, प्रत्येक project की state एक GCS backend में एक prefix के तहत रहती है।

बिल्कुल खरोंच से, क्रम मजबूर है - पहले सीड project, दूसरा state बकेट - क्योंकि एक backend एक GCS बकेट है और एक बकेट को रहने के लिए एक project की आवश्यकता होती है। और Azure की तरह एक छोटी सी चिकन-एंड-एग समस्या है: google प्रोवाइडर को कुछ भी करने के लिए एक project और सक्षम APIs की आवश्यकता होती है, इसलिए आप वह पहला project बनाते हैं और एक अनिवार्य gcloud कॉल के साथ उसकी APIs को सक्षम करते हैं, फिर बाद में इसे Terraform में अपनाते हैं। ( terraform-google-modules/bootstrap मॉड्यूल ठीक इसी सीड-project-प्लस-SA प्रक्रिया को पैकेज करता है।)

और यहीं पर GCP वास्तव में AWS मांसपेशी स्मृति की तुलना में सरल है: सीड-project में backend प्लस सदस्य में संसाधन को AWS हब-एंड-स्पोक ट्रस्ट मशीनरी की कोई आवश्यकता नहीं है - कोई backend role_arn नहीं, कोई प्रोवाइडर assume_role नहीं, कोई दो-तरफा ट्रस्ट नीतियां नहीं। सही भूमिकाओं वाला एक org-स्तर का service account org-व्यापी काम करता है क्योंकि IAM नीचे की ओर विरासत में मिलता है; प्रोवाइडर project सेट करके projects के बीच "हॉप" करता है; और यह impersonate_service_account सेट करके डिप्लॉयर पहचान बन जाता है। क्रॉस-project एक पैरामीटर है, न कि एक ट्रस्ट वार्ता। (आप इसे बाद में कस्टम भूमिकाओं, प्रति-project SAs, और समर्पित CI पहचानों के साथ कसेंगे - लेकिन तब भी यह स्कोप पर भूमिका बाइंडिंग है, कभी भी ट्रस्ट-नीति हैंडशेक नहीं।) यदि आप किसी भी पक्ष को कोडिफाई करने में गहराई से जाना चाहते हैं, तो HashiCorp Terraform Authoring & Operations Pro परीक्षा ठीक इन्हीं स्टेट और प्रोवाइडर पैटर्न के इर्द-गिर्द बनी है।

वे चार स्थान जहाँ आपके AWS के सहज ज्ञान आपको सक्रिय रूप से गुमराह करेंगे

यदि आप बाकी सब कुछ भूल जाते हैं, तो इन्हें याद रखें:

1. उपयोगकर्ता पर कोई नीति नहीं है। पहचान से जुड़े JSON की तलाश बंद करें। अनुमतियाँ org, folder, project, या resource पर (member, role) बाइंडिंग हैं, और वे नीचे की ओर विरासत में मिलती हैं। आपको जिस अनुदान की आवश्यकता है वह तीन स्तर ऊपर हो सकता है।
2. जब तक आप API सक्षम नहीं करते, तब तक कुछ भी काम नहीं करता। एक नए project पर आपकी पहली 403 आमतौर पर API not enabled होती है, न कि एक गुम भूमिका। हर सेवा बंद होती है जब तक आप उसे प्रति project चालू नहीं करते।
3. आप service accounts का प्रतिरूपण करते हैं, आप भूमिकाएँ नहीं मानते। और SA अपनी स्वयं की एक्सेस नीति वाला एक संसाधन है - आपके प्रिंसिपल को व्यापक project अधिकार देना बेकार है यदि SA पर एक टोकन-निर्माता बाइंडिंग नहीं है।
4. बिलिंग एक अलग ऑब्जेक्ट है। "मैं कुछ भी डिप्लॉय कर सकता हूँ" का मतलब "मैं एक शुल्क योग्य project बना सकता हूँ या एक billing account लिंक कर सकता हूँ" से कुछ नहीं है। अलग संसाधन, अलग भूमिकाएँ - billing account पर billing.user, project एडमिन नहीं।

कौन से प्रमाणन प्रत्येक पक्ष को ड्रिल करते हैं

क्लाउड गवर्नेंस - पदानुक्रम, पहचान, गार्डरेल और स्टेट - दोनों क्लाउड पर आर्किटेक्चर और प्रशासन परीक्षाओं की रीढ़ है, इसलिए उनके लिए अध्ययन करना उपरोक्त अवधारणाओं को समझने का सबसे तेज़ तरीका भी है। यदि आपके पास पहले से ही AWS क्रेडेंशियल है, तो उसी पंक्ति में Google Cloud वाला आपका अगला स्वाभाविक कदम है।

AWS पक्ष पर (वह ज्ञान जिससे आप अनुवाद कर रहे हैं):

• AWS Certified Cloud Practitioner (CLF-C02) - accounts, IAM, और Organizations की नींव।
• AWS Certified Solutions Architect - Associate (SAA-C03) - IAM, मल्टी-अकाउंट संरचना, और कोर आर्किटेक्चर।
• AWS Certified Solutions Architect - Professional (SAP-C02) - मल्टी-अकाउंट Organizations, SCPs, और बड़े पैमाने पर क्रॉस-अकाउंट एक्सेस।
• AWS Certified Security - Specialty (SCS-C03) - IAM गहराई, SCPs, और कुंजी प्रबंधन।

Google Cloud पक्ष पर (वह ज्ञान जिसमें आप अनुवाद कर रहे हैं):

• Google Cloud Digital Leader - foundational स्तर पर organizations, projects, IAM, और billing।
• Google Cloud Associate Cloud Engineer - दिन-प्रतिदिन का प्लेन: projects, IAM बाइंडिंग, service accounts, और gcloud।
• Google Cloud Professional Cloud Architect - org/folder/project पदानुक्रम, लैंडिंग-जोन डिज़ाइन, और बड़े पैमाने पर गवर्नेंस।
• Google Cloud Professional Cloud Security Engineer - IAM गहराई, org नीति, service-account सुरक्षा, और कुंजी प्रबंधन।

यदि आप आज AWS-प्रमाणित हैं तो एक व्यावहारिक मार्ग: शब्दावली को मैप करने के लिए Cloud Digital Leader से शुरू करें, फिर Associate Cloud Engineer पर जाएं (जो project-और-IAM प्लेन में रहता है जिसका आप सबसे अधिक उपयोग करेंगे), और Professional Cloud Architect या Professional Cloud Security Engineer जोड़ें, यह इस बात पर निर्भर करता है कि आपका काम आर्किटेक्चर या सुरक्षा की ओर झुकता है।

निष्कर्ष

GCP AWS से कठिन नहीं है - यह अलग तरह से फैक्टर किया गया है। AWS अनुमतियों को पहचानों से जोड़ता है, आपको सब कुछ चालू के साथ एक भारी account देता है, और अधिकांश अधिकार को IAM में समेटता है। GCP अनुमतियों को एक संसाधन ट्री पर लटकाता है जो नीचे की ओर विरासत में मिलता है, आपको सस्ते डिस्पोजेबल projects देता है जो खाली स्लेट के रूप में शुरू होते हैं, और भूमिकाएँ मानने के बजाय आपको service accounts का प्रतिरूपण कराता है। अवधारणाओं का एक बार अनुवाद करें - नीतियां पहचानों से ट्री पर जाती हैं, accounts अपनी APIs बंद होने के साथ projects बन जाते हैं, भूमिकाएँ service accounts बन जाती हैं जिनका आप प्रतिरूपण करते हैं, और बिलिंग एक अलग ऑब्जेक्ट है जिसे आप लिंक करते हैं - और बाकी शब्दावली है। इसे ऊपर दिए गए प्रमाणपत्रों के साथ अभ्यास करें, और वे हिस्से जो मनमानी अस्वीकृतियों जैसे लगते थे, एक सुसंगत, जानबूझकर डिजाइन के रूप में पढ़ने लगेंगे।