IAM & Security

Correct answer: .

IAM's policy evaluation logic follows a default-deny model in which an explicit Deny found in any applicable policy always overrides an Allow found elsewhere, no matter how many other policies grant the same action or where those policies live in the evaluation set. This holds even when the conflicting Allow and Deny are two separate identity-based policies attached to the same principal. The option claiming the outcome depends on which policy was attached first is wrong because IAM's evaluation engine does not track or consult attachment order or timestamps when deciding an authorization outcome. The option claiming a single Allow statement is sufficient regardless of other policies is wrong because it ignores the explicit-deny override, a rule that exists precisely so a narrow restriction can safely coexist with, and take priority over, a broader grant. The option describing an interactive console prompt is wrong because policy evaluation happens automatically and silently on every API call; there is no interactive step for a principal to resolve conflicting policies at request time.

Source: AWS IAM documentation: Policy evaluation logic — Determining whether a request is allowed or denied within an account

Correct answer: .

A resource-based policy, such as an S3 bucket policy, is attached directly to the resource itself and can name a principal from an entirely different AWS account, granting that principal access without the resource owner needing to create any matching IAM identity in their own account. This is the defining feature that separates resource-based policies from identity-based ones. The option describing an identity-based policy attached only in the requesting account is wrong because a policy on the requesting principal alone cannot grant it access to a resource it does not own; the resource owner's account must independently authorize the principal, and a bucket policy is the standard way to do that. The option about creating a matching IAM user in the resource owner's account is wrong and does not reflect how cross-account authorization works; it also does nothing to identify the actual calling principal from Account A. The option involving Transfer Acceleration is wrong because that feature only changes the network path used for faster uploads and downloads to S3; it has no effect on identity or access authorization.

Source: AWS IAM documentation: Identity-based policies and resource-based policies

Correct answer: .

An IAM role attached to an EC2 instance through an instance profile lets the application on that instance retrieve automatically-rotated, short-lived credentials from the instance metadata service, so no access key ever needs to be written to disk, checked into a script, or typed in by a person. This directly satisfies a no-long-lived-keys requirement. The option involving an IAM user's keys embedded in user data is wrong because that key pair is a static, long-lived credential that persists in the instance's configuration and does not expire on its own, which is exactly what the security team wants to avoid. The option involving manual entry of an IAM user's keys is wrong for the same reason: the credential is still long-lived and additionally now depends on a human handling and storing a secret. The option storing root user keys is wrong on every count: root credentials are long-lived, unrestricted in scope, and AWS explicitly recommends never generating or using root access keys for applications at all.

Source: AWS IAM documentation: IAM roles for Amazon EC2

Correct answer: .

A permissions boundary is a managed policy attached to an IAM user or role that sets the maximum permissions that identity can ever have; any identity-based policy attached later, however permissive, is intersected with the boundary, so permissions outside the boundary — such as IAM administration or the sensitive bucket — can never take effect. This makes it the correct tool for letting teams self-manage roles within a hard ceiling. The option describing a service control policy attached to individual roles is wrong because SCPs are attached to AWS Organizations entities such as accounts or organizational units, not to individual IAM roles, so this configuration is not even possible. The option describing a manually run policy simulator is wrong because it is only an analysis tool that reports what a policy would allow; it enforces nothing and depends on a human remembering to run it every time, which is not a guarantee. The option describing a resource-based policy on every future resource is wrong because it would need to be recreated correctly on every new resource those roles might touch, which does not scale and provides no guarantee against a future oversight.

Source: AWS IAM documentation: Permissions boundaries for IAM entities

Correct answer: .

A service control policy attached to an organizational unit sets a permissions ceiling for every account under it and applies to every IAM principal in those accounts, including administrators and, by default, even the account's root user; an explicit Deny in an SCP on the CloudTrail-disabling actions cannot be overridden by any local identity-based policy, which is exactly the org-wide guarantee described. The option using a permissions boundary is wrong because a boundary must be attached to each individual role or user one at a time within a single account, so it cannot provide a single OU-wide guarantee and is easy to miss for a newly created role. The option using a resource-based policy on the trail is wrong because AWS CloudTrail trails do not support attaching resource-based policies to control who may stop or start logging in this way. The option using an IAM group is wrong because IAM groups only exist within a single account and only affect the IAM users placed in them; they cannot restrict administrators across every account in an OU, nor do they restrict roles at all.

Source: AWS Organizations documentation: Service control policies (SCPs)

Correct answer: .

Calling AWS STS to assume a role whose trust policy names Account A as a trusted principal produces temporary security credentials with a defined, bounded session lifetime that expires automatically without any manual revocation step, which is exactly the self-expiring access the security team wants. The option using a permanent IAM user and shared access keys is wrong because that credential does not expire on its own and, once shared, is difficult to fully revoke or rotate, the opposite of a short session. The option granting a resource-based policy on every resource in Account B is wrong because it would have to be created and later removed on each resource individually, it grants standing access rather than a time-bounded session, and it does not scale as resources change. The option adding the engineer's user to an IAM group inside Account B is wrong both because IAM groups cannot contain principals from another account and because group membership, like the other rejected options, does not expire on its own the way an assumed-role session does.

Source: AWS IAM documentation: Using IAM roles — AssumeRole and temporary security credentials

Correct answer: .

AWS IAM Identity Center connects to a central identity source, such as an existing corporate directory or an external identity provider, and lets administrators assign permission sets to that identity across many AWS accounts at once, so an employee signs in once and is federated into whichever accounts they are assigned, with no separate IAM user ever created per account. The option of creating an identical IAM user with the same password in every account is wrong because it is exactly the duplicated per-account identity the company wants to avoid, and it also multiplies the number of long-lived credentials that must be individually secured and rotated. The option describing Amazon Cognito user pools attached to each account's root user is wrong because Cognito user pools are designed to authenticate end users of an application, not federate workforce staff into the AWS Management Console, and attaching anything to a root user is not how Cognito or console federation works. The option describing AWS Certificate Manager is wrong because that service issues and manages TLS/SSL certificates for encrypting network traffic; it plays no role in authenticating employees or granting console access.

Source: AWS documentation: AWS IAM Identity Center — What is IAM Identity Center

Correct answer: .

IAM policies can include a Condition element that evaluates request context keys at the moment an API call is made, and aws:MultiFactorAuthPresent is the specific global condition key that is true only when the calling principal's current session was authenticated with MFA, so a policy statement conditioned on it will only take effect for MFA-authenticated sessions. The option describing a resource-based policy that checks password history is wrong because IAM policies, resource-based or otherwise, do not have access to or evaluate a principal's password history; MFA presence is a session-level fact, not a password attribute. The option describing a permissions boundary with a built-in MFA-only mode is wrong because permissions boundaries are ordinary managed policies that cap maximum permissions; there is no special MFA-enforcement mode built into the boundary feature itself, MFA must still be enforced through a Condition element. The option describing an IAM group that AWS automatically enforces is wrong because group membership is just a way to attach policies to multiple users; AWS does not automatically interpret a group's name as a security requirement, and the enforcement must still come from an explicit Condition element on a policy.

Source: AWS IAM documentation: IAM global condition context keys — aws:MultiFactorAuthPresent

Correct answer: .

This is envelope encryption: the KMS Encrypt and Decrypt operations accept only small payloads, so applications instead use GenerateDataKey to obtain a data key, encrypt the potentially large payload locally with that key, and let KMS protect only the small data key itself by returning and storing its encrypted form. This lets KMS scale to arbitrarily large data while every cryptographic key material operation still goes through KMS. The option calling this client-side master key rotation is wrong on the facts alone: AWS KMS does support automatic annual rotation of the cryptographic material behind eligible customer managed keys, so the premise that rotation is impossible is false, and the pattern described has nothing to do with rotation. The option calling this field-level encryption restricted to JSON is wrong because KMS and envelope encryption work on arbitrary binary data up to size limits set by the application's own design, not on a specific structured format. The option claiming the pattern avoids calling the KMS API entirely is wrong because GenerateDataKey (and, on decryption, a Decrypt call to unwrap the encrypted data key) are themselves KMS API calls; envelope encryption reduces how much data crosses that API, it does not eliminate the calls.

Source: AWS KMS documentation: Envelope encryption and GenerateDataKey

Correct answer: .

AWS KMS requires authorization from both the identity-based policy on the calling principal and the resource-based key policy attached to the KMS key itself, even within a single account, because the default key policy is what delegates authority to IAM in the first place; for cross-account use, the key policy in the key's own account must explicitly name and allow the external principal, or the request is denied regardless of what the caller's own identity-based policy says. The option claiming identity-based policies are simply ignored is wrong because they are still required and still evaluated; the issue is that they are insufficient alone for KMS, not irrelevant. The option suggesting the fix is to rewrite the identity-based policy as a service control policy is wrong because SCPs are guardrails that can only restrict, never grant, permissions, so converting a grant into an SCP would not create the missing authorization at all. The option claiming KMS keys never support cross-account access is wrong because that is precisely what a correctly configured key policy, naming an external account's principal, is designed to enable.

Source: AWS KMS documentation: Key policies in AWS KMS — authorizing cross-account use of a KMS key

Correct answer: .

AWS Secrets Manager provides a managed rotation workflow, including AWS-supplied Lambda rotation function templates for services like RDS, so a scheduled rotation can be configured without the team writing their own cron-based orchestration, making it the right fit for the password; Systems Manager Parameter Store SecureString parameters are a lighter-weight, encrypted option well suited to static values that do not need that managed rotation workflow. The option reversing the pairing is wrong because Parameter Store has no built-in, managed rotation orchestration comparable to Secrets Manager's; any rotation logic for a parameter would have to be built and scheduled entirely by the team itself, which contradicts the requirement that AWS manage the workflow. The option pairing Cognito and KMS is wrong because Cognito user pools authenticate end users of an application and have no facility for rotating an arbitrary database password, and KMS manages encryption keys rather than storing configuration values themselves. The option pairing Certificate Manager and S3 Object Lock is wrong because ACM only issues and renews TLS certificates, not database credentials, and S3 Object Lock is a write-once-read-many retention control unrelated to storing or serving configuration values.

Source: AWS documentation: AWS Secrets Manager rotation and AWS Systems Manager Parameter Store

Correct answer: .

AWS WAF operates at the application layer and inspects the actual content of HTTP requests, including headers, URI, and body, and it is associated with an Application Load Balancer through a web ACL that can include managed or custom rules matching patterns such as SQL injection, letting it block malicious requests before they reach the application with no code changes. The option describing GuardDuty is wrong because GuardDuty is a threat-detection service that analyzes sources like VPC Flow Logs, DNS query logs, and CloudTrail events for suspicious activity; it does not attach to a load balancer or inspect individual HTTP request payloads. The option describing Shield Advanced is wrong because Shield protects against network and transport layer (layer 3/4) DDoS attacks and provides cost protection and expert support during large attacks, but it does not offer custom content-matching rules for inspecting request bodies for patterns like SQL injection. The option describing security groups is wrong because security groups filter traffic only by IP address, port, and protocol at the network layer; they cannot parse or match against the contents of an HTTP request body.

Source: AWS WAF documentation: How AWS WAF works with web ACLs and managed rule groups

Correct answer: .

Amazon GuardDuty is a managed threat-detection service that continuously analyzes existing log sources — VPC Flow Logs, DNS query logs, and CloudTrail management and data events — against threat intelligence feeds and anomaly-detection models to generate findings, and it requires no agent to be installed on any instance because it consumes logs and events that AWS services already produce. The option describing AWS Config is wrong because Config evaluates resource configuration compliance against rules; it is not designed to analyze network flow or DNS data for malicious activity, and it does not work by scanning flow logs hourly. The option describing Systems Manager Inventory is wrong because Inventory simply catalogs metadata like installed applications and OS details on managed instances; it performs no threat analysis at all. The option describing Amazon Inspector is wrong because Inspector's actual purpose is the reverse of what is stated: it is a vulnerability management service that scans workloads for software vulnerabilities and unintended network exposure, not a tool focused on detecting active network intrusions in the way GuardDuty is.

Source: Amazon GuardDuty documentation: What is Amazon GuardDuty

Correct answer: .

AWS Shield Standard is automatically included for every AWS customer at no additional charge and protects services like CloudFront and Route 53 against common, most-frequently-occurring network and transport layer (layer 3/4) DDoS attacks; AWS Shield Advanced is an optional paid subscription that adds DDoS cost protection against scaling charges incurred during an attack, more detailed attack visibility, and 24/7 access to the AWS DDoS Response Team. The option reversing which tier is free and which is paid is wrong because it inverts the actual roles: Shield Standard, not Advanced, is the automatic free baseline, and Shield Advanced, not Standard, is the paid upgrade with the Response Team. The option substituting AWS WAF for the automatic free protection is wrong because WAF is a separate, rule-based layer 7 filtering service that customers configure themselves; it is not the automatic infrastructure-level DDoS protection that Shield Standard provides, and it additionally mislabels which Shield tier is paid. The option claiming CloudFront has no DDoS protection unless purchased separately is wrong because Shield Standard's protection for CloudFront distributions is automatic and requires no purchase or separate enablement at all.

Source: AWS Shield documentation: AWS Shield Standard vs. AWS Shield Advanced

Correct answer: .

IAM Access Analyzer is built exactly for this: you enable it for an account or an entire AWS organization, which becomes its zone of trust, and it continuously analyzes resource-based policies on supported resource types (including S3 buckets, IAM role trust policies, and KMS key policies) to generate a finding whenever access is granted to a principal outside that zone, without anyone manually reading each policy. The option describing anomaly detection from flow logs, DNS logs, and CloudTrail events is wrong because that behavioral, log-based threat detection identifies suspicious activity patterns rather than analyzing policy documents for unintended external sharing. The option describing configuration recording and rule evaluation over time is wrong because that service tracks whether a resource's configuration matches a desired state or rule, not specifically whether its resource policy exposes it to outside principals. The option describing a fixed set of periodic best-practice checks is wrong because those checks are generic and scheduled, not a continuous, policy-specific external-access analysis across every resource of the relevant types.

Source: AWS IAM documentation: Identifying unintended resource access with IAM Access Analyzer (https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)

Correct answer: .

AWS Config continuously records the configuration state of supported resources, including EBS volumes, and maintains a timeline of every configuration change; it can also evaluate resources against managed rules, such as one that checks whether a volume is encrypted, flagging noncompliant resources automatically as their configuration changes. The option describing a log of API calls is wrong because that captures who called which API and when, not the resulting configuration state of a volume or whether it complies with an encryption requirement. The option describing vulnerability scanning of instances and container images is wrong because that checks for known software vulnerabilities and network exposure, an entirely different concern from tracking configuration state and evaluating a compliance rule. The option describing a fixed set of periodically refreshed checks is wrong because it does not provide continuous, resource-specific configuration history or rule-based compliance evaluation targeted at a particular setting like volume encryption.

Source: AWS Config documentation: What Is AWS Config? (https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)

Correct answer: .

Amazon Macie is a data-security service that uses machine learning together with pattern matching to discover sensitive data such as personally identifiable information and financial information stored in S3 objects, while also maintaining an inventory of buckets and generating findings when a bucket's security posture changes, such as becoming publicly accessible. The option describing vulnerability and network-reachability scanning is wrong because that inspects workloads for known software flaws, not the content of stored objects for sensitive data. The option describing configuration evaluation against compliance rules is wrong because that checks whether a resource's settings match a desired configuration, not whether the data inside an object is sensitive. The option describing anomaly detection from log analysis is wrong because that identifies suspicious behavioral patterns in account and network activity rather than scanning object content for sensitive data types.

Source: Amazon Macie documentation: What is Amazon Macie? (https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html)

Correct answer: .

AWS Security Hub is designed to collect and normalize findings from integrated services such as GuardDuty, Macie, and Inspector into a standard finding format, correlating and prioritizing them in one dashboard, while also independently running continuous checks against security industry standards, including the CIS AWS Foundations Benchmark, to produce a security score. The option describing heavy custom rule authoring is wrong because rebuilding equivalent multi-service finding aggregation and benchmark scoring from scratch is not that service's purpose and would not genuinely reproduce this capability. The option describing patching and general operational configuration inspection is wrong because that focuses on operational management tasks like patch compliance, not consolidating security findings from other detection services. The option describing root-cause visualization of a single known finding is wrong because that tool is for deep investigation of an already-identified issue, not for aggregating findings across many services and running standards-based checks.

Source: AWS Security Hub documentation: What is AWS Security Hub? (https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)

Correct answer: .

Automatic key rotation is supported only for symmetric encryption KMS keys with AWS KMS-generated key material; the default rotation period is 365 days, but a custom rotation period anywhere from 90 to 2560 days can be specified instead. Asymmetric KMS keys are explicitly excluded from both automatic and on-demand rotation and can only be rotated manually, by creating a new key and migrating callers to it. The option claiming both key types rotate identically is wrong because it ignores this explicit exclusion of asymmetric keys from automatic rotation. The option claiming rotation is impossible without recreating the entire account is wrong because automatic rotation is a normal, supported, ongoing feature for eligible keys that never requires account-level changes. The option reversing which key type gets automatic rotation is wrong because it is the symmetric key, not the asymmetric one, that is eligible for the automatic schedule, and there is no built-in 90-day default schedule for asymmetric keys at all.

Source: AWS KMS documentation: Rotate AWS KMS keys (https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)

Correct answer: .

ACM's managed renewal is fully automated only for certificates that were originally DNS-validated and that remain currently in use by an integrated AWS service, since ACM can silently reverify domain ownership through the existing DNS records; the CloudFront-attached, DNS-validated certificate satisfies both conditions. A certificate validated by email instead requires the domain owner to click a link in a renewal notice, so it is not renewed without manual action, and an imported certificate is never eligible for ACM managed renewal under any circumstance. The option claiming every certificate renews automatically regardless of validation method or usage is wrong because it ignores both the validation-method requirement and the in-use requirement. The option favoring the imported certificate is wrong because imported certificates are explicitly excluded from managed renewal. The option claiming none of the three renew automatically is wrong because the DNS-validated, in-use certificate does renew without any manual step.

Source: AWS Certificate Manager documentation: Renewal for domains validated by DNS (https://docs.aws.amazon.com/acm/latest/userguide/dns-renewal-validation.html)

Correct answer: .

AWS best practice is to protect the root user with MFA, avoid keeping any root access keys, and perform routine and automated tasks using an IAM role or IAM user scoped with only the permissions that task requires, reserving root for the rare actions that genuinely require it. The option that keeps using root access keys for a daily script, and even adds a second one, is wrong because it directly contradicts least privilege and expands the damage a single leaked credential could do, rather than reducing it. The option that disables MFA everywhere is wrong because removing a key protection against credential compromise is not how lockout risk is managed; lockout risk is instead addressed through backup MFA devices and account-recovery procedures. The option proposing several additional root users is wrong because an AWS account has exactly one root user that cannot be duplicated; the correct way to give teams independent, scoped access is through separate IAM roles or users, not additional root accounts.

Source: AWS IAM documentation: Security best practices for the AWS account root user (https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html)

Correct answer: .

IAM natively supports registering an external SAML 2.0 identity provider as a SAML provider resource and creating an IAM role whose trust policy allows that provider's authenticated principals to call AssumeRoleWithSAML, which returns temporary security credentials scoped to the role, entirely independent of IAM Identity Center and without ever creating an IAM user for an employee. The option requiring IAM Identity Center is wrong because direct SAML federation into IAM roles predates Identity Center and works without it; Identity Center is one option among several for federation, not the only one. The option of creating an IAM user per employee and injecting a long-lived access key is wrong because it reintroduces exactly the long-lived, hard-to-rotate credentials that federation is meant to eliminate. The option of replacing the identity provider with AWS Directory Service is wrong because that service is a managed directory for different scenarios, such as domain-joined workloads, and IAM can already trust an external SAML provider directly without needing any such replacement.

Source: AWS IAM documentation: Creating IAM SAML identity providers and AWS STS AssumeRoleWithSAML (https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html)

Correct answer: .

Amazon Cognito identity pools are built exactly for this scenario: they issue temporary AWS credentials scoped to an IAM role for both unauthenticated guest identities and identities authenticated through a supported identity provider, letting an app's end users interact directly with AWS services such as S3 without the backend ever holding long-lived AWS credentials. The option describing workforce single sign-on is wrong because that service brokers employee access to AWS accounts and business applications, not temporary credentials for an app's individual end users. The option describing a long-lived IAM user access key embedded in the app is wrong because embedding such a key is the exact anti-pattern identity pools exist to avoid, since any user could extract and misuse a long-lived credential from the app. The option describing a managed Active Directory is wrong because that service supports domain-joined workloads and directory-based authentication scenarios, not issuing scoped temporary credentials to mobile app end users.

Source: Amazon Cognito documentation: Identity pools console overview (https://docs.aws.amazon.com/cognito/latest/developerguide/identity-pools.html)

Correct answer: .

aws:SecureTransport is a boolean condition key that reflects whether a request was made over SSL/TLS, so a statement can deny any request where this key is false to enforce HTTPS; aws:SourceIp evaluates the requester's IP address against a CIDR range, so a statement can deny any request whose source falls outside the corporate range. The option pairing MFA presence with organization membership is wrong because aws:MultiFactorAuthPresent only reflects whether MFA was used at authentication and has nothing to do with transport encryption, and aws:PrincipalOrgID restricts by AWS Organization membership rather than by any IP address range. The option that swaps the two correct keys is wrong because aws:SourceIp carries no information about whether a connection used HTTPS, and aws:SecureTransport carries no IP address information at all. The option pairing current time with user agent is wrong because aws:CurrentTime restricts access by date and time and aws:UserAgent inspects a client-supplied header, neither of which relates to transport encryption or the source network.

Source: AWS Identity and Access Management documentation: AWS global condition context keys (https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)