IAM
누가 무엇을 할 수 있는지 정의. 키를 심는 선택지는 항상 오답
이게 뭔가요? / What is this?
IAM은 서버나 소프트웨어가 아니라, "누가 무엇을 할 수 있는가"를 정의해 두는 AWS 전체의 권한 규칙 체계(추상적 개념)입니다. 건물의 출입 카드 발급 사무소이자 규정집이라고 생각하면 되며, 실제 문이나 자물쇠가 아니라 "이 카드로는 몇 층까지 들어갈 수 있다"는 규칙 자체를 관리합니다.
개요 / Overview
IAM은 사용자·그룹·역할·정책으로 AWS 리소스 접근을 제어합니다. 시험의 IAM 문제는 대부분 "장기 액세스 키를 어딘가에 저장한다"는 오답 선택지를 걸러내고 역할 기반 임시 자격 증명을 고르는 연습입니다.
동작 원리 / How it works
IAM 요청이 들어오면 AWS는 항상 같은 순서로 평가합니다 — 기본은 거부(implicit deny), 어디든 명시적 Deny가 있으면 즉시 거부, 그렇지 않고 Allow가 있으면 허용입니다. 여기에 SCP(조직 상한), 권한 경계(위임 상한), 리소스 정책(리소스 쪽 허용), 세션 정책이 겹치면 최종 권한은 이들의 교집합입니다. 그래서 "정책을 더 넓혔는데도 안 된다"는 문제의 원인은 대개 상위 경계입니다.
역할은 신뢰 정책(누가 이 역할을 맡을 수 있는가)과 권한 정책(맡으면 무엇을 할 수 있는가) 두 장으로 이루어집니다. AssumeRole을 호출하면 STS가 만료 시간이 있는 임시 자격 증명을 발급하고, 이 만료성이 장기 액세스 키보다 안전한 근본 이유입니다.
시험은 무엇을 보는가 / What the exam is testing
IAM 76문제의 공통 패턴은 "장기 자격 증명을 어딘가에 저장하는 선택지를 골라내 버리기"입니다. 그다음이 범위 좁히기 — 리소스 ARN 지정, 조건 키(PrincipalOrgID, SourceIp, MFA), 교차 계정은 역할 수임입니다. 기능이 같아 보이는 선택지가 여럿이면 권한 범위가 가장 좁은 쪽이 정답입니다.
시험 포인트 / Exam points
EC2·Lambda·ECS가 AWS 서비스를 호출할 때는 역할을 붙입니다. 교차 계정 접근도 역할 수임(AssumeRole)이 정답이며, 계정마다 IAM 사용자를 만드는 선택지는 오답입니다.
명시적 Deny가 모든 Allow를 이깁니다. 기본은 암묵적 거부이며, SCP·권한 경계·리소스 정책이 겹치면 교집합만 허용됩니다.
aws:PrincipalOrgID로 조직 내부만, aws:SourceIp로 특정 대역만, aws:MultiFactorAuthPresent로 MFA 사용자만 허용하는 식으로 조건을 좁힙니다.
루트는 MFA를 켜고 액세스 키를 삭제한 뒤 일상 작업에 쓰지 않습니다. 루트로 작업하라는 선택지는 언제나 오답입니다.
자주 틀리는 함정 / Common traps
계정마다 IAM 사용자를 만들어 교차 계정 접근을 푸는 선택지 — 역할 수임이 정답입니다.
SCP가 권한을 부여한다고 보는 것 — SCP는 상한만 정하며 실제 부여는 IAM 정책이 합니다.
AdministratorAccess나 Action:*/Resource:* 를 붙이는 선택지 — 최소 권한 위반으로 거의 항상 오답입니다.
AWS IAM
Defines who may do what; any option embedding keys is wrong
이게 뭔가요? / What is this?
IAM is not a server or piece of software — it is the abstract system of rules across all of AWS that defines who is allowed to do what. Think of it as a building ID-badge office and its rulebook combined: it is not a door or a lock itself, it manages the rules like "this badge opens doors up to floor 5."
개요 / Overview
IAM controls access through users, groups, roles, and policies. Most IAM questions are an exercise in rejecting options that store long-lived access keys and choosing role-based temporary credentials instead.
동작 원리 / How it works
Every IAM request is evaluated in the same order: implicit deny by default, immediate denial if any explicit Deny applies, otherwise allowed if an Allow applies. Layer on SCPs (organisation ceiling), permission boundaries (delegation ceiling), resource policies (allow from the resource side), and session policies, and the effective permission is their intersection. That is why "I widened the policy and it still fails" usually traces to a higher boundary.
A role has two documents: a trust policy (who may assume it) and permission policies (what they can do once assumed). Calling AssumeRole makes STS issue credentials with an expiry, and that expiry is the fundamental reason roles beat long-lived access keys.
시험은 무엇을 보는가 / What the exam is testing
The shared pattern across 76 IAM questions is discarding any option that stores long-lived credentials. Next comes narrowing: specific resource ARNs, condition keys (PrincipalOrgID, SourceIp, MFA), and AssumeRole for cross-account. Among functionally equal options, the narrowest scope wins.
시험 포인트 / Exam points
Attach roles when EC2, Lambda, or ECS call AWS services. Cross-account access is solved by AssumeRole, not by creating IAM users in each account.
An explicit Deny beats every Allow. The default is implicit deny, and where SCPs, permission boundaries, and resource policies overlap only the intersection is allowed.
Narrow access with condition keys: aws:PrincipalOrgID for the organization, aws:SourceIp for an address range, aws:MultiFactorAuthPresent for MFA-authenticated callers.
Enable MFA on root, delete its access keys, and never use it for daily work. Any option telling you to use root is wrong.
자주 틀리는 함정 / Common traps
Solving cross-account access by creating IAM users in each account — AssumeRole is the answer.
Treating an SCP as granting permission — it only sets a ceiling; IAM policies grant.
Attaching AdministratorAccess or Action:* on Resource:* — almost always wrong on least privilege.
AWS SAA Hub Pro는 독립 학습 자료이며 Amazon Web Services, Inc.의 공식 서비스가 아닙니다. 시험 정책과 서비스 사양은 AWS 공식 문서를 기준으로 확인하세요.