शैडोइंग अभ्यास: IAM - वीडियो के साथ अंग्रेजी बोलना सीखें

अभ्यास मोड चुनें

हर मोड पूरी स्क्रीन का अभ्यास कक्ष खोलता है।

211 वाक्य

यदि वाक्य बहुत छोटे या लंबे हों, तो समायोजित करने के लिए Edit पर क्लिक करें।

Hey everyone!

Today I'd like to walk you through AWS Identity and Access Management, or IAM.

We'll take a look at how IAM works, how it controls access to AWS resources, and some common security best practices.

Rather than thinking of IAM as just a place to create users, I want you to think of it as the authorization control plane for AWS.

As engineers, we work with IAM all the time, even when we're not opening the IAM console.

EC2 instance roles, Lambda execution roles, CI, CD deployments, and cross -account access all depend on it.

One quick detail before we start.

IAM is a global service, even though the AWS services receiving requests may be regional.

All right, let's start with the problem IAM is designed to solve.

Two, what problem does IAM solve?

Okay, let's take a look at the three columns here.

Before IAM, IAM itself, and the outcome.

On the left, imagine an environment where developers share credentials, applications store static access keys,

administrators review access manually, and delegating permissions across teams is difficult.

That's hard to secure and even harder to scale.

Those weren't the best times, right?

In the middle, IAM gives us a central way to define policies, use roles and federation, issue temporary credentials,

and apply guardrails with auditing.

On the right, those capabilities help us achieve least privilege, cross -account access, automated deployments, and traceable API calls.

Of course, IAM doesn't automatically make our permissions secure.

We still have to design them correctly.

Here's a real -world example at the bottom.

Basically, when a workflow runs, it can request an OIDC token and use that token to authenticate with AWS.

Now, AWS checks the role's trust policy to make sure the workflow is allowed to assume that role.

if everything checks out aws sts provides temporary credentials

which the workflow can then use to deploy resources based on the permissions assigned to that role

and here's the important part we don't need to store any long -lived aws access keys in github

so essentially we're moving away from permanent credentials and toward a more secure approach where access is temporary and controlled.

03. What is IAM?

All right, so what exactly is IAM?

At a high level, IAM helps control who can do what in AWS, on which resources, and under which conditions.

Look at the three blocks across the top.

First, principles.

These are the identities making requests.

IAM users, assumed roles, federated identities, and AWS services.

Second, policies.

These are the authorization rules.

The slide mentions identity -based policies, resource -based policies, trust policies,

permissions boundaries, and service control policies, or SCPs.

Third, STS and sessions stands for AWS Security Token Service,

which issues temporary credentials, and sessions can carry tags used in authorization.

Now look at the middle statement, where IAM sits.

IAM is the Global Identity and Permissions Control Plane.

When a request reaches a target AWS service, AWS evaluates the relevant authorization controls and either allows or denies the operation.

And the three labels at the bottom matter too.

Managed means AWS runs the underlying IAM infrastructure.

Global means IAM identities are associated with AWS accounts, not individual VPCs.

API first means we can manage users, roles, and policies through APIs and infrastructure as code, including Terraform.

04. How IAM works.

Request evaluation.

Alright, so now that we understand the basics of IAM, let's take a look at what actually happens when someone makes a request to AWS.

If you look at the diagram, we have four steps here.

First, we have the principle.

Basically, this is whoever or whatever is making the request.

It could be a user, an application, or an AWS service.

The request is typically signed using AWS credentials, such as an access key.

And if we're using temporary credentials, there's also a session token involved.

Now, moving to step two, we have the request context.

This is where AWS looks at what the principal is actually trying to do.

For example, which API action is being requested?

Which resource are we trying to access?

And depending on the request, AWS can also consider additional information like resource tags, source IP addresses, MFA, or organization membership.

So essentially, AWS needs to understand not just who's making the request, but also what they're trying to do and under which conditions.

All right, now step three is probably the most important one, policy evaluation.

And here's the key rule to remember.

An explicit deny always takes precedence over an allow.

So even if a role has permissions to perform an action, another policy might still block it.

For example, that could be an SCP, a permissions boundary, or a session policy.

Now, if there's no explicit deny, AWS checks whether the request has the necessary permissions.

If there's an applicable allow and no other restrictions block it, the request can proceed.

Otherwise, it's denied by default.

That's what we call an implicit deny.

Now, if you look at the bottom of the slide, there's one important thing I want you to remember.

Whenever you're troubleshooting an IAM permission issue, start with four simple questions.

Who's making the request?

What action are they trying to perform?

Which resource are they accessing?

And under what conditions?

If you can answer those four questions, you're already in a much better position to understand why AWS is allowing or denying the request.

All right, so now that we've covered how IAM evaluates requests, let's move on to the core components that make all of this work.

05. Core Components All right, so now that we've seen how IAM evaluates requests,

let's take a closer look at the main components that make all of this work.

As you can see on the slide, we have eight components here.

So let's quickly walk through each one.

First, we have IAM users.

Basically, an IAM user represents an individual identity within an AWS account.

Now, IAM users can have long -term credentials such as passwords or access keys.

But here's the thing.

In modern AWS environments, we generally try to avoid using permanent access keys, especially for applications and automated workloads.

Instead, we prefer roles and temporary credentials.

Next, we have groups.

Groups are pretty straightforward.

They allow us to organize IAM users and assign permissions to multiple users at once.

For example, instead of attaching the same policy to 10 different users, we can create a group and manage those permissions in one place.

All right, moving on to roles.

And this is probably one of the most important components in modern AWS architectures.

A role is an identity that can be assumed by an authorized principle.

For example, an EC2 instance, a Lambda function, a user from another AWS account,

or even a GitHub Actions workflow can use a role.

100

Now, let's talk about policies.

101

Policies are basically JSON documents that define permissions.

102

They specify which actions are allowed or denied, which resources those actions apply to, and sometimes additional conditions.

103

And as you can see, we have different types of policies, including identity -based and resource -based policies.

104

Now, right below that, we have trust policies.

105

And here's an important distinction.

106

A trust policy defines who is allowed to assume a role.

107

A permissions policy defines what that role is allowed to do once it's assumed.

108

So, for example, a GitHub Actions workflow.

109

Its actual permissions still depend on the policies and restrictions that apply to the role session.

110

All right, next we have STS, or Security Token Service.

111

STS is responsible for issuing temporary AWS credentials.

112

Now, moving on to Access Analyzer.

113

This is a really useful service from a security perspective.

114

It helps us identify resources that may be accessible from outside our intended trust boundaries.

115

It can also help us detect unused access and validate IAM policies.

116

And finally, we have MFA and credential management.

117

This is mainly about protecting human access, especially privileged users and the root account.

118

MFA adds another layer of authentication, while proper credential management helps reduce the risks associated with long -lived access keys.

119

Zero.

120

All right, so now let's take a look at security.

121

As you can see on the left side of the slide, we have a bad security practice.

122

Basically, we're allowing a very broad trust relationship without properly restricting who can assume the role.

123

Not exactly what we want in production, right?

124

Now, on the right, we have a much better approach.

125

And this is where the zero trust security concept comes in.

126

The main idea is pretty simple.

127

Never trust anyone by default.

128

Instead, we explicitly define who can assume the role and under which conditions.

129

Verify identities, restrict trust relationships, and follow the principle of least privilege.

130

07. Real -world use cases.

131

All right, so now let's take a quick look at some real -world use cases where IAM plays an important role in production.

132

As you can see on the slide, we have several common scenarios.

133

Healthcare workloads.

134

Here, security and audibility are especially important.

135

We use least privileged roles, CloudTrail for auditing, MFA, and controlled emergency access to protect sensitive environments and maintain separation of duties.

136

For CI -CD pipelines, we typically use OIDC Federation with GitHub, GitLab, or Jenkins to assume deployment roles without storing permanent AWS credentials.

137

For microservices, each service gets its own IAM role, with scoped access to resources like S3, SQS, SNS, or KMS.

138

For data pipelines, services like

139

Glue, EMR, and Lambda use dedicated roles with restricted S3 and KMS permissions.

140

In cross -account environments, a shared tooling account can assume roles across different AWS accounts.

141

And finally, for monitoring, we can provide read -only access to tools like Datadog using cross -account roles and external IDs where appropriate.

142

So the main takeaway here is pretty simple.

143

Regardless of the architecture, we want to avoid shared credentials, isolate permissions, and follow the principle of least privilege.

144

8 .08, Pricing and Cost Optimization, General American Transcription.

145

Let's switch to cost.

146

The headline on this slide is important.

147

IAM itself is usually not what drives a bill.

148

But here's the thing.

149

Some of the services we use alongside IAM can generate costs.

150

For example, IAM Access Analyzer offers external access analysis at no additional charge,

151

but features like unused access analysis and custom policy checks may incur charges.

152

Now let's take a look at the example at the bottom left.

153

Imagine we have 10 AWS accounts with 200 IAM roles and five CICD pipelines in each account.

154

That's 2 ,000 roles and 50 pipelines in total.

155

And the interesting part is that we don't pay for the IAM roles themselves or standard STS usage.

156

Instead, the costs come from the security, monitoring, and networking services we enable around them.

157

Now, moving over to the right, we have a few optimization strategies.

158

We can use OIDC Federation instead of permanent access keys, reuse managed policies where appropriate,

159

remove unused roles, and configure CloudTrail data events based on our actual auditing requirements.

160

We can also use

161

Access Analyzer to identify unnecessary permissions and improve lease privilege.

162

And of course, we don't want to compromise security just to save money.

163

The goal is to configure these services efficiently while maintaining the right level of protection.

164

9. Reference Architecture Alright, so now let's put everything together and look at how it works in a real -world CICD architecture.

165

As you can see on the slide, we have a pretty common deployment workflow using GitHub Actions, IAM, AWS STS, and Terraform.

166

So let's walk through it from left to right.

167

First we have GitHub Actions.

168

When a pipeline starts, GitHub can generate an OIDC token containing information about the repository and branch.

169

Next, we have the IAM role trust policy.

170

This is where AWS verifies whether the workflow is allowed to assume the role.

171

Now moving over to Terraform.

172

Terraform uses those temporary credentials to deploy infrastructure changes.

173

But remember, Terraform can only perform actions allowed by the role's permissions and other applicable security controls.

174

Now, let's take a quick look at the bottom of the diagram.

175

On the left we have S3, which stores the Terraform state.

176

Access to that bucket is restricted to authorize roles.

177

Next we have EKS, ECS, and Lambda, which represent the AWS services Terraform might deploy or update.

178

Then we have CloudTrail, which records supported AWS API activity.

179

And finally, CloudWatch provides monitoring through events and metrics.

180

So essentially all these components work together to provide a secure and auditable deployment process.

181

So essentially all these components work together to provide a secure and auditable deployment process.

182

10 Production Best Practices Checklist general American transcription.

183

Let's quickly go through some production best practices.

184

So let's start with the top five.

185

First, always prefer IAM roles and temporary credentials over permanent access keys.

186

Second, make sure your trust policies are properly scoped.

187

We want to explicitly control who can assume a role rather than allowing broad access.

188

Third, follow the principle of least privilege.

189

Fourth, implement security guardrails, such as SEPs, permissions boundaries, MFA, and controlled emergency access.

190

And fifth, enable auditing and monitoring.

191

Use CloudTrail to track IAM activity and configure alerts for potentially risky changes.

192

Now, if you look at the bottom of the slide, we have three additional areas to consider.

193

From a security perspective, protect their root account, enforce MFA, and use conditions and explicit deny policies where appropriate.

194

For reliability, remember that IAM changes can take time to propagate,

195

so we should avoid making unnecessary IAM changes during critical application operations.

196

And finally, from an operations perspective, manage IAM policies through infrastructure as code.

197

Use code reviews, validate policies, and follow consistent naming standards.

198

Final recap.

199

All right, so before we wrap up, let's quickly recap what we've covered today.

200

We started by looking at what IAM is and why it's important for managing access to AWS resources.

201

We learned how IAM evaluates requests, how policies work, and why an explicit deny always takes precedence over an allow.

202

Then we looked at security best practices, including zero trust, least privilege, temporary credentials, and MFA.

203

We also explored some real -world use cases and saw how OIDC CICD deployments without permanent AWS access keys.

204

And finally, we discussed cost optimization, auditing, and production best practices.

205

IAM isn't just about managing users and permissions.

206

It's about building a secure, scalable, and auditable access model across AWS.

207

And that's exactly what we want in production.

208

Alright, that's everything I wanted to cover today.

209

Thanks for watching!

210

Thanks, everyone.

211

I'm happy to take any questions.

ऐप डाउनलोड करें

धाराप्रवाह बोलने के लिए ज़रूरी सब कुछ

AI उच्चारण स्कोरहर वाक्य का स्कोर

IPA अभ्यासहर ध्वनि में महारत

शब्दावलीअपना शब्द भंडार बनाएँ

शब्द गेमखेलते हुए सीखें

QR स्कैन करें

Download on theApp Store Get it onGoogle Play

उसी चैनल से

अनुशंसित वीडियो

158 वाक्य

इस पाठ की शब्दावली और बोलने के सुझाव

सबसे ज़्यादा दोहराए गए शब्द ये हैं: Iam, aws, role, access, permission। इस वीडियो में शैडोइंग के लिए 211 वाक्य और 2425 शब्द हैं। बोला गया हिस्सा 18:12 लंबा है। वक्ता लगभग 133 शब्द प्रति मिनट की स्थिर गति से बोलता है, जो शैडोइंग के लिए आरामदायक है। केवल 76% शब्द अंग्रेज़ी के 3,000 सबसे आम शब्दों में से हैं, इसलिए शब्दावली कठिन है।

इस वीडियो की मुख्य शब्दावली

वीडियो के 15 सीखने लायक शब्द, उच्चारण और अर्थ के साथ:

शब्द	उच्चारण	अर्थ
temporary विशेषण	/ˈtɛmp(əˌɹ)ɛɹi/	अस्थायी
principle संज्ञा	/ˈpɹɪn.sɪ.pəl/	जड़सूत्र, असूल
resource संज्ञा	/ɹɪˈzɔːs/	संसाधन
pipeline संज्ञा	/ˈpaɪpˌlaɪn/	पाइपलाइन
infrastructure संज्ञा	/ˈɪnfɹəˌstɹʌkt͡ʃə/	अवसंरचना
architecture संज्ञा	/ˈɑː.kɪˌtɛk.t͡ʃə/	वास्तुकला, स्थापत्य
monitor संज्ञा	/ˈmɑ.nɪ.tɚ/	पर्यवेक्षक
boundary संज्ञा	/ˈbaʊndɹi/	सीमा
authorization संज्ञा	/ˌɔːθəɹaɪˈzeɪʃən/	अनुज्ञा
federation संज्ञा	/ˌfɛdəˈɹeɪ̯ʃən/	महासंघ, फ़ेडरेशन
solve क्रिया	/sɒlv/	सुलझाना, हल करना
default संज्ञा	/dɪˈfɔlt/	व्यतिक्रम
generate क्रिया	/ˈd͡ʒɛn.ə.ɹeɪt/	उपजाना
evaluation संज्ञा	/ɪˌvæljuˈeɪʃn̩/	मूल्यांकन
unnecessary विशेषण	/ʌnˈnɛs.əˌsɛɹ.i/	अनावश्यक

दोहराने लायक वाक्य

वीडियो के छोटे, पूरे वाक्य जिन्हें आप रोज़ की बातचीत में इस्तेमाल कर सकते हैं:

Which resource are we trying to access?
That's what we call an implicit deny.
Let's quickly go through some production best practices.
Alright, that's everything I wanted to cover today.
I'm happy to take any questions.

इस वीडियो का व्याकरण

वक्ता जिन संरचनाओं का सबसे अधिक प्रयोग करता है, वीडियो के असली शब्दों के साथ:

संरचना	वीडियो में
Passive voice be + past participle — ज़ोर इस पर कि क्या होता है, न कि कौन करता है	is designed · is allowed · are associated
Present perfect have/has + past participle — बीता हुआ काम जिसका असर अभी भी है	we've covered · we've seen

ध्यान देने योग्य उच्चारण

वक्ता 19 बार संक्षिप्त रूपों का प्रयोग करता है, जैसे we're, don't, we've। इन्हें वैसे ही छोटा बोलें जैसा आप सुनते हैं।

“th” की ध्वनियाँ: authorization /ˌɔːθəɹaɪˈzeɪʃən/, authorize /ˈɔθəɹaɪz/, authenticate /ɔˈθɛn.tɪ.keɪt/, authentication /ɔːˌθɛntɪˈkeɪʃn̩/
“sh” और “zh” की ध्वनियाँ: essentially /ɪˈsɛnʃəli/, authorization /ˌɔːθəɹaɪˈzeɪʃən/, federation /ˌfɛdəˈɹeɪ̯ʃən/, optimization /ˌɑptəmaɪˈzeɪʃən/, evaluation /ɪˌvæljuˈeɪʃn̩/
लंबे शब्द — बलाघात सही रखें: temporary /ˈtɛmp(əˌɹ)ɛɹi/, infrastructure /ˈɪnfɹəˌstɹʌkt͡ʃə/, architecture /ˈɑː.kɪˌtɛk.t͡ʃə/, essentially /ɪˈsɛnʃəli/, authorization /ˌɔːθəɹaɪˈzeɪʃən/

हिंदी भाषियों के लिए मुश्किल ध्वनियाँ:

/v/ और /w/ का फ़र्क़ — /v/ में ऊपर के दाँत निचले होंठ को छूते हैं, /w/ में होंठ गोल होते हैं: privilege /ˈpɹɪv.(ɪ.)lɪd͡ʒ/, evaluate /ɪˈvaljʊeɪt/, solve /sɒlv/, evaluation /ɪˌvæljuˈeɪʃn̩/, verify /ˈvɛɹɪfaɪ/
/z/ — इसे “ज” (/dʒ/) न बनाएँ: resource /ɹɪˈzɔːs/, authorization /ˌɔːθəɹaɪˈzeɪʃən/, optimization /ˌɑptəmaɪˈzeɪʃən/, unused /ʌnˈjuzd/, compromise /ˈkɑmpɹəˌmaɪz/
शब्द की शुरुआत में s + व्यंजन — पहले “इ” न जोड़ें: slide /ˈslaɪ̯d/, scope /skəʊp/, static /ˈstæt.ɪk/, straightforward /ˌstɹeɪtˈfɔː(ɹ)wə(ɹ)d/, specify /ˈspɛs.əˌfaɪ/

इस वीडियो से अभ्यास कैसे करें

पहले बिना बोले पूरा वीडियो एक बार सुनें और जो शब्द नहीं आते उन्हें लिख लें।
सामान्य गति पर एक-एक वाक्य की शैडोइंग करें और हर वाक्य तब तक दोहराएँ जब तक आपकी लय वक्ता से न मिल जाए।
अपनी आवाज़ रिकॉर्ड करें और मूल से तुलना करें, ख़ासकर temporary, principle, resource जैसे शब्दों पर ध्यान दें।

शैडोइंग तकनीक क्या है?

शैडोइंग (Shadowing) एक विज्ञान-समर्थित भाषा सीखने की तकनीक है जो मूल रूप से पेशेवर दुभाषिया प्रशिक्षण के लिए विकसित की गई थी। विधि सरल लेकिन शक्तिशाली है: आप मूल अंग्रेज़ी ऑडियो सुनते हैं और तुरंत इसे ज़ोर से दोहराते हैं — जैसे वक्ता की छाया 1-2 सेकंड की देरी से। शोध से पता चलता है कि यह उच्चारण सटीकता, स्वर, लय, जुड़ी हुई ध्वनियाँ, सुनने की समझ और बोलने की प्रवाहशीलता में काफ़ी सुधार करता है।

शैडोइंग तकनीक: पूरी चरण-दर-चरण गाइड पढ़ें →

शैडोइंग अभ्यास: IAM - वीडियो के साथ अंग्रेजी बोलना सीखें

अभ्यास मोड चुनें

ऐप डाउनलोड करें

IAM 1

OWASP Top 10 Explained

Amazon Athena explained in 120 seconds💡

The Only SaaS Moats Left in 2026

Understand Microsoft Entra ID | AZ-104 | Episode 2

Executing Monitoring, Evaluation and Learning (MEAL) | Complete Practical Guide

AI Governance Explained: Ethical, Transparent & Accountable AI for the Future

How I deploy serverless containers for free

Armchair Architects: Resiliency in the Cloud – Core Patterns

The Man Who Stole MySpace | Samy

LangChain in 5 Minutes (Explained Clearly)

Crypto Agility Explained: Protect Data from Quantum Computing Threats