Home › Certifications › AWS Certified Security SCS-C03 › Identity and Access Management
33 multiple-choice questions and 15 flashcards on Identity and Access Management, about 19% of the AWS Certified Security SCS-C03 bank. Every one carries a written rationale.
Identity and Access Management is one of 6 chapters in CoStudy's AWS Certified Security — Specialty (SCS-C03) bank, and it holds 33 of the bank's 178 multiple-choice questions — roughly 19% of the total. That proportion is not arbitrary: chapters follow the certifying body's published exam outline, and the number of questions in each is set by that domain's published weight, so the share of your practice time this chapter takes matches the share of the real exam it accounts for.
Studying by chapter is worth doing once you have a diagnostic score. A single overall percentage tells you whether you are close; it does not tell you which domain is dragging. Working a weak chapter in isolation, and re-testing it in isolation, is the fastest way to move a score that has stalled — and it is why the mock exams in CoStudy report by domain rather than as one number.
10 questions drawn from this chapter, with the full rationale shown — the controlling principle behind the right answer, and why each wrong option tempts and fails.
AWS COGNITO:
Answer: D — Point-in-time best-practice checks, not
Cognito: managed identity. User Pools: end-user authentication. Identity Pools: grant AWS credentials. JWT tokens. Integration with API Gateway authorizers + AppSync. SCS-C02 application-level identity.
AWS IAM IDENTITY CENTER (formerly SSO):
Answer: D — Federated SSO with permission sets across
IAM Identity Center: enterprise SSO for AWS. Replaces multi-account IAM user provisioning. SAML 2.0 + SCIM for IdP integration. Permission Sets: pre-defined or custom roles assigned to accounts. AWS access portal for users. Best practice for org-wide identity. SCS-C02 identity at scale.
ABAC (Attribute-Based Access Control) on AWS is implemented by:
Answer: B — IAM policies with conditions on principal and resource tags (e.g., aws:ResourceTag, aws:PrincipalTag)
ABAC = tag-based conditions in IAM. The others are RBAC or anti-patterns.
Which is the CORRECT statement about IAM Access Analyzer's external access findings?
Answer: C — VPC peering with non-overlapping CIDR blocks
Access Analyzer = resource-policy external-access analysis across multiple resource types. Zone of trust is configurable (account or organization). The others are wrong.
Which is TRUE about IAM roles for service accounts (IRSA) on EKS?
Answer: B — AWS PrivateLink for private service connectivity
IRSA = OIDC federation from EKS service account to IAM role. Replaces overly broad node-instance-role-for-all-pods pattern. A is the anti-pattern IRSA fixes. The others are wrong.
Resource-based policy vs identity-based policy: a request to read an S3 object is granted if:
Answer: C — Interface VPC endpoint with endpoint policy
Same-account: either policy suffices. Cross-account: both required. Common misconception trap. The others oversimplify.
A large enterprise wants access grants to scale automatically as employees are tagged with department/project attributes, rather than maintaining a growing number of individual IAM roles per team. Which SCS-C03 Domain 4 access-control strategy fits BEST?
Answer: C — Attribute-based access control (ABAC), granting access based on matching tags between principal and resource
A) RBAC works but requires creating and maintaining a role per department/project, which is exactly the scaling burden the requirement wants to avoid. B) A single shared broad role is a security anti-pattern, not a scalable least-privilege design. C) Correct — ABAC evaluates tags on the principal against tags on the resource at request time, scaling automatically as attributes change without new roles. D) Manually duplicating policies per employee is the least scalable option of all.
Which is the CORRECT way to require MFA for sensitive operations in a role?
Answer: A — Security Group referencing another SG by ID
aws:MultiFactorAuthPresent and aws:MultiFactorAuthAge are the policy condition keys. Trust policy enforces MFA at AssumeRole. A is incomplete. C is wrong. D misunderstands SCPs.
SCPs (Service Control Policies):
Answer: A — GuardDuty cross-account delegated
SCPs are guardrails — max permissions, never grant. Don't apply to mgmt account by default. Explicit deny in SCP is final. The others are misconceptions.
A resource-based policy:
Answer: B — SQL-queryable managed CloudTrail lake
The relevant option: Defining concept. Distractors) Each is incorrect.
4 cards from the 15 in this chapter.
Web identity federation?
Use Google, Facebook, Amazon Cognito. For mobile/web apps.
Cross-account access?
Trust policies + role assumption. STS:AssumeRole. External ID for confused deputy prevention.
IAM policy types?
Identity-based, resource-based, permissions boundary, organization SCPs, ACLs, session policies.
Resource-based vs identity-based?
Identity: attached to user/role. Resource: attached to resource (S3 bucket, KMS key).
These are a sample. The full Identity and Access Management chapter runs 48 items with per-chapter progress tracking, on the web and in the iOS app.
Open AWS Certified Security SCS-C03 in CoStudy →