CCNA Identity and Access Management Questions

The SCP uses the aws:SourceIp condition, but when accessing the Management Console, the IP address seen by AWS is the console's IP, which may not be the same as the developer's VPN IP if the console uses a proxy or if the VPN is configured incorrectly. Option A is wrong because SCPs affect all principals, including the root user. Option B is wrong because the SCP denies actions, not allows them; an explicit deny overrides allows.

Option D is wrong because the SCP denies all actions, so even if the developer has permissions, the SCP denies them.

An IAM role with S3 access attached to the EC2 instance profile provides temporary credentials via the instance metadata service, eliminating the need for long-term access keys. Option A is wrong because storing IAM user access keys on the instance is insecure and violates best practices. Option B is wrong because security groups control network traffic, not IAM permissions.

Option C is wrong because an S3 bucket policy cannot grant access based on an EC2 instance ID; the principal must be an IAM user, role, or AWS account.

IAM users need the ability to change their password to set up MFA even when MFA is not yet enabled. The policy should include an exception for the iam:ChangePassword action to allow this action without MFA. Option A would allow all actions without MFA, defeating the purpose of enforcement.

Option C is impractical as users without MFA cannot access the console to enable it. Option D removes MFA enforcement entirely, violating the requirement.

The IAM policy uses the ${aws:username} variable in the Resource element. When this policy is attached to a user, ${aws:username} resolves to that user's username, thereby restricting the actions to only that user's own access keys. Option A allows access to all users' keys.

Option B denies all AccessKey actions. Option D allows all AccessKey actions without restriction.

Many AWS SDKs require the dynamodb:DescribeTable action to retrieve table metadata such as key schema and throughput settings. Without this permission, the SDK cannot execute operations like GetItem or PutItem, resulting in an AccessDeniedException. Option A is incorrect because the policy attachment is described as correct.

Option B is incorrect because encryption permissions are not the issue here; the error is about table actions. Option D is incorrect because the instance profile is associated correctly.

The policy simulator shows an explicit deny for iam:DeleteUser, confirming that a deny statement exists in the policy. Option C is correct because the explicit deny means the policy explicitly denies iam:DeleteUser. Option A is incorrect because the simulator does not indicate that iam:CreateUser is denied.

Option B is incorrect because the explicit deny overrides any default allow. Option D is incorrect because the simulator returned an explicit deny, not errors.

Delegated administrator for AWS Organizations. This feature allows a member account to manage specified services across the organization, enabling administrative delegation for an OU. Option A (AWS Resource Access Manager) is for sharing resources.

Option B (AWS CloudTrail) is for logging API activity. Option C (AWS SSO) provides single sign-on access but not delegation of administrative tasks.

The correct answers are A and E. IAM roles can be used by federated users to grant temporary access (A), and they can be assumed by AWS services like EC2 to obtain permissions (E). Option B is false because IAM roles are global, not region-specific.

Option C is false because roles can be attached to EC2 instances via instance profiles. Option D is false because roles use temporary credentials obtained through AWS STS, not permanent access keys.

Options B and D are correct because they provide the specific actions needed: sqs:ReceiveMessage to read from SQS and logs:CreateLogStream and logs:PutLogEvents to write logs to CloudWatch Logs. Option A (logs:DeleteLogGroup) is not required for writing logs. Option C (cloudwatch:*) is overly broad and CloudWatch Logs actions are under the logs: prefix, not cloudwatch:* which covers other CloudWatch services.

Option E (sqs:SendMessage) is for sending messages, not reading.

The correct options are A and D. Option A uses an IAM policy with a condition key 'aws:MultiFactorAuthPresent' to deny actions unless MFA is present, which can be attached to users or groups. Option D uses a Service Control Policy (SCP) at the AWS Organizations level to deny actions when MFA is not present.

Option B is incorrect because a password policy does not enforce MFA usage. Option C is incorrect because requiring MFA for roles does not enforce MFA for IAM users. Option E is unrelated to IAM user MFA enforcement.

aws:RequestTag is the correct condition key because it checks the tags that are submitted in the request (e.g., during EC2 instance launch). This allows enforcement of specific tags at creation. Option A (aws:ResourceTag) checks tags on existing resources, not the request.

Option B (aws:SourceIp) is for IP-based conditions, unrelated to tags. Option C (ec2:ResourceTag) is a valid IAM condition key that checks tags on existing resources, not request tags, so it is not the correct choice for this scenario.

The condition in the policy restricts access to IP addresses within the 10.0.0.0/16 range. The user's IP address 10.1.0.5 is not in that range, so the allow statement for s3:GetObject does not apply. Since there is no applicable allow statement, the default implicit deny takes effect, resulting in denied access.

Option B is wrong because the allow only applies when the condition is satisfied. Option C is wrong because the policy is syntactically valid. Option D is wrong because there is no explicit deny statement; the denial is implicit.

The correct options are A, C, and E. Access keys, IAM roles (via STS), and SAML federation are valid authentication methods. Option B, SSH keys, are for EC2 instance access, not AWS APIs.

Option D, client certificates, are not used for AWS API authentication.

Options C and D are correct. The EC2 instance needs an IAM role with permissions to write to the bucket (D), and the bucket policy must allow the role to write (C). Option A is incorrect because a security group controls network traffic but does not grant IAM permissions.

Option B is incorrect because a VPC endpoint provides private connectivity but is not required for this task. Option E is incorrect because CloudTrail is for API logging, not application logs.

AWS Security Token Service (STS) is specifically designed to issue temporary credentials for IAM users or federated users. Option A is incorrect because IAM is for managing users and roles, not for generating temporary credentials directly. Option B is incorrect because AWS Cognito is for user identity and authentication; while it can use STS to get temporary credentials, the primary service for issuing temporary credentials is STS.

Option D is incorrect because KMS is for encryption key management.

Options B and D are correct. B: A bucket policy can grant cross-account access to a specific user. D: A role in Account B can be assumed by the user in Account A.

Option A is wrong because IAM policies in Account A cannot grant access to resources in another account; the resource account must also grant access. Option C is wrong because SCPs are used in AWS Organizations to set permissions boundaries, not to grant access across accounts. Option E is wrong because you cannot attach an IAM policy to an S3 bucket; you use bucket policies instead.

The correct steps are to enable MFA for each IAM user (E), create an IAM policy that denies all actions if `aws:MultiFactorAuthPresent` is false (A), and attach the policy to all IAM users or groups (C). Enabling MFA per user is a prerequisite. The policy enforces MFA usage by denying API calls when MFA is not present.

Attaching the policy ensures it applies to users. Option B (CloudTrail) is for auditing, not enforcement. Option D (password policy) does not enforce MFA for console access; it only sets password requirements.

To rotate access keys, the user needs to create a new access key (iam:CreateAccessKey) and delete the old one (iam:DeleteAccessKey). Therefore, options B and E are correct. Option A (iam:GetAccessKeyLastUsed) is not required for rotation.

Option C (iam:ListAccessKeys) is not strictly required, though it may be useful. Option D (iam:UpdateAccessKey) can change the status of a key but is not necessary for rotation.

The condition likely specifies 'ec2:InstanceType' equals 't2.micro', so if the user tries to launch any other type, the action is denied. Option B is irrelevant because the policy allows the action. Option C is not a common condition.

Option D is unrelated.

The correct answer because it grants only the necessary actions (s3:GetObject and s3:PutObject) on the specific buckets (my-bucket for read, my-other-bucket for write), adhering to the principle of least privilege. Option A is incorrect because it allows both GetObject and PutObject on all buckets (*/*), which is too permissive. Option B grants full S3 access (*) to all resources, violating least privilege.

Option D only allows PutObject on my-bucket instead of my-other-bucket, failing to meet the write requirement.

An SCP can be applied at the organization, OU, or account level to deny all actions if MFA is not present, ensuring enforcement across all users and roles, including the root user. Option A is wrong because it only applies to the root user. Option B is wrong because CloudTrail logs do not enforce MFA.

Option C is wrong because an IAM policy can be attached to users, groups, or roles but can be bypassed if not attached universally; an SCP provides broader, unavoidable enforcement.

Aws:SourceVpc. This condition key allows you to restrict requests to originate from a specific VPC ID. Option A, aws:RequestedRegion, restricts region, not VPC.

Option B, aws:VpcSourceIp, is not a valid condition key. Option D, aws:SourceIp, restricts source IP address, not VPC.

The IAM policy allows 'iam:CreateUser' and 'iam:CreateAccessKey', which enables users to create new IAM users and programmatic access keys, leading to unauthorized access and privilege escalation. Option B is incorrect because the policy does not grant permissions to disable CloudTrail logging. Option C is incorrect because creating users/keys does not allow decrypting data in S3.

Option D is incorrect because it does not allow modifying VPC security groups.

The policy denies all S3 actions when the request is not using HTTPS (i.e., aws:SecureTransport is false). Option A is incorrect because the policy does not deny all S3 access; it only denies non-HTTPS requests. Option B is incorrect because the policy does not require MFA; it denies non-HTTPS requests.

Option C is incorrect because the policy does not allow anything; it denies non-HTTPS requests. Option D correctly states that the policy denies S3 access if the request is not using HTTPS.

AWS CloudTrail records API calls for auditing purposes, making it the correct service for logging access to S3 buckets. Option A is incorrect because Amazon GuardDuty is a threat detection service, not a logging service. Option B is incorrect because Amazon Inspector assesses vulnerabilities.

Option C is incorrect because AWS Config tracks resource configuration changes, not API calls.

Aws:MultiFactorAuthPresent is the condition key used to verify whether the requesting user authenticated using multi-factor authentication (MFA). In a trust policy, this condition ensures that only MFA-authenticated users from Account A can assume the role in Account B. Option A (aws:SourceIp) is incorrect because it checks the source IP address, not MFA status.

Option C (aws:RequestedRegion) is incorrect because it restricts based on the AWS region, not MFA. Option D (aws:UserAgent) is incorrect because it checks the user agent string of the request, not MFA.

Kms:ViaService ensures the KMS request is made through an integrated AWS service (in this case, S3), and aws:SourceIp restricts the request to a specific IP address range. Option A is incorrect because kms:GrantOperations is used for managing grants, not for restricting based on IP or service. Option B is incorrect because kms:CallerAccount checks the account number of the caller, not the IP.

Option C is incorrect because kms:EncryptionContext is used to specify encryption context, not for IP restrictions.

To assume a role in another AWS account, the external account must have an IAM user or role with permissions to call the sts:AssumeRole API for the target role ARN. Option D correctly describes this requirement. Option A is incorrect because MFA is not a required step unless specified in the role's trust policy.

Option B is incorrect because the external account does not need to create a new role; it only needs a principal (user or role) with the appropriate permissions. Option C is incorrect because the trust policy is attached to the role in the target account, not the external account.

The correct best practices are A, C, and E. Using IAM roles for EC2 instances (A) eliminates the need for long-term access keys. Deleting unused access keys (C) reduces risk.

Rotating access keys regularly (E) limits exposure if keys are compromised. Option B is incorrect because long-lived access keys increase risk; they should be rotated. Option D is incorrect because embedding access keys in application code is insecure; use IAM roles instead.

The policy does not allow s3:ListBucket, so it is implicitly denied; but the simulator shows 'explicitDeny' because there might be an attached policy that denies it. However, in this simulation, the policy only allows s3:GetObject, so ListBucket is not allowed. The 'explicitDeny' could be due to an SCP or a different policy attached to the user.

Option A is wrong because the resource ARN is correct. Option B is wrong because the policy does not include ListBucket. Option D is wrong because the action is spelled correctly.

The Resource element specifies the ARN of the S3 bucket. Option A is wrong because Principal specifies who gets access, not the resource. Option B is wrong because Action specifies allowed actions.

Option D is wrong because Condition specifies when the policy applies.

IAM policies can use 'aws:ResourceTag' in the Condition element to restrict access based on tags attached to the S3 bucket. Option A ('aws:PrincipalTag') is used to restrict based on tags attached to the principal (user/role), not the resource. Option B ('aws:SourceTag') is not a valid condition key in IAM.

Option C ('aws:RequestTag') is used to require specific tags on the request itself, not on the resource.

A bucket policy with the aws:SecureTransport condition denies any request that does not use HTTPS, enforcing encryption in transit. Option A is incorrect because SSE-S3 only encrypts data at rest, not during transmission. Option B is incorrect because CloudTrail logs access but does not enforce encryption.

Option D is incorrect because an IAM policy can deny non-HTTPS requests, but enforcing this at the bucket policy level is more direct and applies to all principals accessing the bucket.

An IAM policy with a condition that denies console access unless MFA is present enforces MFA for all IAM users. Option A is incorrect because account settings do not enforce MFA for individual users. Option C is incorrect because a password policy cannot require MFA.

Option D is incorrect because SCPs apply to accounts or OUs, not to individual IAM users, and are not the best way to enforce MFA per user.

A service role is an IAM role that a service assumes to perform actions on your behalf. Option A is correct. Option B is wrong because a service-linked role is a special type of service role, but not all service roles are service-linked.

Option C is wrong because an instance profile is used for EC2. Option D is wrong because a permissions boundary is used to set maximum permissions.

Even though the policy allows the ec2:RunInstances action on the instance resource, the RunInstances API call requires permissions for other resources such as Amazon Machine Images (AMI), security groups, and key pairs. Without explicit permissions for these resources, the API call fails with an AccessDenied error. Option B is incorrect because the condition specifies t2.micro, matching the developer's request.

Option C is incorrect because the policy does not restrict by region. Option D is incorrect because there is no explicit deny; the denial is due to missing resource permissions.

Aws:MultiFactorAuthPresent is the IAM condition key that checks whether multi-factor authentication (MFA) was used for the request. Option A (aws:SourceIp) is incorrect because it checks the IP address of the requester, not MFA status. Option C (aws:UserAgent) is incorrect because it checks the user agent string, not MFA.

Option D (aws:CurrentTime) is incorrect because it checks the date and time of the request, not MFA.

The user cannot perform PutItem because the SCP denies all DynamoDB actions, and an explicit deny in an SCP overrides any allow from IAM policies. Option A is incorrect because SCPs apply to all principals in the OU and deny overrides allow. Option C is incorrect because SCPs apply to all accounts in the OU, not just the root account.

Option D is incorrect because the SCP does not need an explicit allow; it is deny-by-default for actions not explicitly allowed, but here it has an explicit deny, which overrides any allow.

Customer managed keys give you full control over the key lifecycle and policies. AWS managed keys are created and managed by AWS but allow you to view and audit usage. AWS owned keys are fully managed by AWS and used across many accounts.

Custom key store keys are stored in a CloudHSM cluster under your control. Distractors swap the definitions of customer and AWS managed keys.

The explicit deny on the 'confidential' folder overrides the allow from the first statement, causing the download to fail. Option A is incorrect because deny overrides, not requiring admin. Option B is incorrect because the ability to access other objects does not apply here.

Option C is incorrect because the first statement allows GetObject generally, but the explicit deny on the specific path overrides it. Option D is correct because the deny applies to the object's path.

It uses cross-account IAM roles, allowing developers in the development account to assume a role in the production account using AWS Security Token Service (STS). This provides temporary, least-privilege credentials without sharing long-term access keys. Option B is insecure because sharing access keys creates long-term credentials that are hard to rotate and manage.

Option C is incorrect: a VPN provides network connectivity but does not grant IAM access. Option D is incorrect because IAM users are account-specific; duplicating users across accounts does not enable cross-account access.

The condition restricts access to the IP range 10.0.0.0/16, and the user's IP is outside that range, so access is denied. Option A is incorrect because the policy does not need an explicit deny; the condition fails, resulting in an implicit deny. Option B is incorrect because the condition key is valid and misspelling would not cause this behavior.

Option D is incorrect because the policy allows s3:GetObject only if the condition is met, which it is not.