IAM practice questions

A company uses multiple AWS security services — GuardDuty, Inspector, Macie, and IAM Access Analyzer — across multiple accounts. The security team needs a single console to view, prioritise, and manage all security findings from these services and third-party tools. Which AWS service provides this aggregated view?

Trap 1: Amazon GuardDuty

Amazon GuardDuty is a threat detection service that continuously analyzes VPC Flow Logs, AWS CloudTrail management events, and DNS logs using machine learning to identify malicious behavior. It generates its own findings for threats such as cryptojacking, unauthorized access, or reconnaissance, but it does not ingest or normalize findings from other services. GuardDuty acts as a finding source that Security Hub can aggregate, rather than a central aggregator.

Trap 2: Amazon CloudWatch

Amazon CloudWatch is a monitoring and observability service for collecting metrics, logs, and events from infrastructure and applications, enabling operational dashboards and alarms. It does not provide a centralized security finding aggregation layer or support the AWS Security Finding Format (ASFF) to normalize detections from multiple security services. CloudWatch focuses on resource utilization and operational health, not on consolidating threat detections from GuardDuty, Inspector, or Macie.

Trap 3: AWS Config

AWS Config is a service that records resource configuration changes and evaluates them against managed or custom rules to determine compliance with your internal policies. While Security Hub can ingest compliance findings from AWS Config, Config itself does not aggregate or correlate security detections from services like GuardDuty and Inspector. Its purpose is configuration history and compliance auditing, not unified security finding management.

A
Amazon GuardDuty
Why wrong: Amazon GuardDuty is a threat detection service that continuously analyzes VPC Flow Logs, AWS CloudTrail management events, and DNS logs using machine learning to identify malicious behavior. It generates its own findings for threats such as cryptojacking, unauthorized access, or reconnaissance, but it does not ingest or normalize findings from other services. GuardDuty acts as a finding source that Security Hub can aggregate, rather than a central aggregator.
B
Amazon CloudWatch
Why wrong: Amazon CloudWatch is a monitoring and observability service for collecting metrics, logs, and events from infrastructure and applications, enabling operational dashboards and alarms. It does not provide a centralized security finding aggregation layer or support the AWS Security Finding Format (ASFF) to normalize detections from multiple security services. CloudWatch focuses on resource utilization and operational health, not on consolidating threat detections from GuardDuty, Inspector, or Macie.
C
AWS Security Hub
Security Hub aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, and third-party tools into a unified dashboard. It uses the AWS Security Finding Format (ASFF) to normalise findings and allows centralised management across accounts.
D
AWS Config
Why wrong: AWS Config is a service that records resource configuration changes and evaluates them against managed or custom rules to determine compliance with your internal policies. While Security Hub can ingest compliance findings from AWS Config, Config itself does not aggregate or correlate security detections from services like GuardDuty and Inspector. Its purpose is configuration history and compliance auditing, not unified security finding management.

Question 2mediummultiple choice

A company needs to grant an EC2 instance permission to write to an S3 bucket. What is the most secure way to accomplish this?

Trap 1: Hardcode the IAM user access keys in the application code

Hardcoding IAM user access keys in application code is a severe security risk because the keys become embedded in source files, build artifacts, and version-control history. Any source-code leak, shared repository, or decompiled artifact exposes the long-term credentials, and they remain valid until manually revoked. Since these keys are long-lived, rotating them requires editing and redeploying the application, creating downtime and operational burden.

Trap 2: Store IAM access keys in environment variables on the EC2 instance

Storing IAM access keys as environment variables on the EC2 instance only moves the plaintext credentials from source code to runtime memory. Any process able to inspect the environment, such as through /proc/self/environ, process listings, debugging tools, or a compromised container, can capture them. Additionally, the keys are long-term, so they do not rotate automatically and remain at risk in AMI snapshots or user-data scripts.

Trap 3: Create an IAM user and configure the instance with its credentials

Creating a dedicated IAM user and installing its access keys on the instance introduces long-term static credentials that require manual rotation whenever they are exposed or for compliance. These keys are stored in files on the instance or in configuration, making them targets for exfiltration via local exploits or backups. If multiple instances share the IAM user, privilege separation is lost, and auditing individual workloads becomes difficult.

A
Hardcode the IAM user access keys in the application code
Why wrong: Hardcoding IAM user access keys in application code is a severe security risk because the keys become embedded in source files, build artifacts, and version-control history. Any source-code leak, shared repository, or decompiled artifact exposes the long-term credentials, and they remain valid until manually revoked. Since these keys are long-lived, rotating them requires editing and redeploying the application, creating downtime and operational burden.
B
Store IAM access keys in environment variables on the EC2 instance
Why wrong: Storing IAM access keys as environment variables on the EC2 instance only moves the plaintext credentials from source code to runtime memory. Any process able to inspect the environment, such as through /proc/self/environ, process listings, debugging tools, or a compromised container, can capture them. Additionally, the keys are long-term, so they do not rotate automatically and remain at risk in AMI snapshots or user-data scripts.
C
Attach an IAM role with the appropriate S3 permissions to the EC2 instance
Attaching an IAM role to the EC2 instance is the AWS-recommended approach because the instance obtains temporary, automatically rotated credentials from the instance metadata service. The AWS SDK automatically retrieves these credentials, so no long-term access keys are written to code, configuration files, or environment variables. This enforces least-privilege permissions via the role policy and eliminates manual credential rotation or management.
D
Create an IAM user and configure the instance with its credentials
Why wrong: Creating a dedicated IAM user and installing its access keys on the instance introduces long-term static credentials that require manual rotation whenever they are exposed or for compliance. These keys are stored in files on the instance or in configuration, making them targets for exfiltration via local exploits or backups. If multiple instances share the IAM user, privilege separation is lost, and auditing individual workloads becomes difficult.

Question 3mediummultiple choice

A company stores sensitive financial reports in an Amazon S3 bucket. The company's security policy mandates that all objects be encrypted at rest using an AWS KMS customer-managed key. The security team wants to ensure that only the 'Auditors' IAM role can decrypt the objects, even though the S3 bucket policy allows read access to a broader set of users. Which of the following steps must the security team take to enforce this access control?

Trap 1: Configure an S3 bucket policy that denies s3:GetObject requests…

This enforces HTTPS for all requests but does not prevent unauthorized decryption of objects. A user who has s3:GetObject permission via the bucket policy can still download the encrypted object, and if they have kms:Decrypt permission, they could decrypt it. This option does not address the requirement to restrict decryption.

Trap 2: Enable S3 Block Public Access on the bucket and attach an IAM…

Block Public Access and IAM policies control who can read the objects from S3, but they do not control who can decrypt objects encrypted with a KMS key. Any principal with s3:GetObject permission could download the encrypted object; the KMS key policy then determines if they can decrypt it. This option does not restrict decryption to only the 'Auditors' role.

Trap 3: Use S3 object-level logging to monitor access and revoke…

This is a reactive, detective control, not a preventive one. It does not enforce that only the 'Auditors' role can decrypt objects. Unauthorized decryption could occur before revocation. The requirement is to enforce access control, not just monitor it.

A
Configure the S3 bucket to use SSE-KMS encryption with the customer-managed key, and modify the KMS key policy to grant the kms:Decrypt permission only to the 'Auditors' role.
This is correct. SSE-KMS encrypts objects at rest using a KMS key. The KMS key policy controls who can use the key to decrypt objects. By restricting kms:Decrypt to the 'Auditors' role, only that role can decrypt the objects, regardless of broader S3 read permissions.
B
Configure an S3 bucket policy that denies s3:GetObject requests unless the request is encrypted in transit using HTTPS.
Why wrong: This enforces HTTPS for all requests but does not prevent unauthorized decryption of objects. A user who has s3:GetObject permission via the bucket policy can still download the encrypted object, and if they have kms:Decrypt permission, they could decrypt it. This option does not address the requirement to restrict decryption.
C
Enable S3 Block Public Access on the bucket and attach an IAM policy to the 'Auditors' role that allows s3:GetObject.
Why wrong: Block Public Access and IAM policies control who can read the objects from S3, but they do not control who can decrypt objects encrypted with a KMS key. Any principal with s3:GetObject permission could download the encrypted object; the KMS key policy then determines if they can decrypt it. This option does not restrict decryption to only the 'Auditors' role.
D
Use S3 object-level logging to monitor access and revoke permissions for any role that attempts to decrypt objects without authorization.
Why wrong: This is a reactive, detective control, not a preventive one. It does not enforce that only the 'Auditors' role can decrypt objects. Unauthorized decryption could occur before revocation. The requirement is to enforce access control, not just monitor it.

Question 4mediummultiple choice

A company uses multiple AWS accounts and wants to enforce cost governance. The company needs to set a monthly cost budget of $10,000 for each account. When an account's actual or forecasted costs exceed this budget, the company wants to automatically apply a restrictive IAM policy that prevents the creation of new resources in that account. Additionally, the company wants to receive an email notification when the budget is exceeded. Which AWS feature should the company use to meet these requirements?

Trap 1: AWS Cost Explorer

AWS Cost Explorer is a read-only analytics and visualization tool that lets you query historical cost and usage data, group by dimensions like account, service, or tag, and view forecasts. However, it has no capability to define hard spending limits, evaluate a policy condition, or initiate any automated remediation. It simply presents data for humans to interpret, so it cannot enforce the restrictive IAM policy required by the scenario.

Trap 2: AWS Cost Anomaly Detection

AWS Cost Anomaly Detection uses machine learning models to establish a baseline of normal spending and alerts you to unusual spikes or patterns, with root-cause analysis for the affected services and accounts. It is designed to detect deviations from behavior, not to enforce a strict budget ceiling, and while it can notify via SNS it cannot attach or remove IAM policies. Fixed budget enforcement is outside its purpose.

Trap 3: AWS Trusted Advisor

AWS Trusted Advisor runs a set of automated checks against your account to identify underutilized resources, service quotas, and security gaps, then provides cost optimization recommendations. These checks are advisory; Trusted Advisor can flag issues but has no mechanism to set a budget threshold or automatically apply a restrictive IAM policy when spending surpasses a limit. You would have to implement any recommended savings manually.

A
AWS Cost Explorer
Why wrong: AWS Cost Explorer is a read-only analytics and visualization tool that lets you query historical cost and usage data, group by dimensions like account, service, or tag, and view forecasts. However, it has no capability to define hard spending limits, evaluate a policy condition, or initiate any automated remediation. It simply presents data for humans to interpret, so it cannot enforce the restrictive IAM policy required by the scenario.
B
AWS Budgets
AWS Budgets enables you to set custom budgets for costs or usage and configure budget actions that automatically enforce policies or send notifications when the budget is exceeded. This directly meets the requirement for automated application of a restrictive IAM policy and email alerts.
C
AWS Cost Anomaly Detection
Why wrong: AWS Cost Anomaly Detection uses machine learning models to establish a baseline of normal spending and alerts you to unusual spikes or patterns, with root-cause analysis for the affected services and accounts. It is designed to detect deviations from behavior, not to enforce a strict budget ceiling, and while it can notify via SNS it cannot attach or remove IAM policies. Fixed budget enforcement is outside its purpose.
D
AWS Trusted Advisor
Why wrong: AWS Trusted Advisor runs a set of automated checks against your account to identify underutilized resources, service quotas, and security gaps, then provides cost optimization recommendations. These checks are advisory; Trusted Advisor can flag issues but has no mechanism to set a budget threshold or automatically apply a restrictive IAM policy when spending surpasses a limit. You would have to implement any recommended savings manually.

Question 5mediummultiple choice

A company's security policy requires that all IAM user access keys be rotated every 90 days. The security team wants to automatically identify any IAM user in the company's AWS account whose access keys are older than 90 days and trigger a notification to the security team. They need a managed AWS service that continuously evaluates the access key age against this requirement and generates findings. Which AWS service should the security team use?

Trap 1: AWS Trusted Advisor

AWS Trusted Advisor includes a best practice check for IAM key rotation, but it is an advisory service that generates recommendations. It does not continuously enforce a specific rotation policy and does not automatically flag individual non-compliant keys for remediation or custom notifications in the same way AWS Config rules do.

Trap 2: Amazon Inspector

Amazon Inspector is a vulnerability management service that performs automated security assessments on compute workloads such as Amazon EC2 instances, Amazon ECR container images, and AWS Lambda functions. It detects software vulnerabilities (CVEs) and unintended network exposure by analyzing the operating system and application packages, but it does not evaluate the configuration of IAM identities. Therefore, Inspector has no mechanism to check the age or rotation status of IAM user access keys and cannot enforce a policy requiring key rotation.

Trap 3: AWS IAM Access Analyzer

AWS IAM Access Analyzer helps identify resources in your account that are shared with an external entity by analyzing resource-based policies (e.g., S3 bucket policies, IAM role trust policies). It does not evaluate the age or rotation status of IAM user access keys.

A
AWS Trusted Advisor
Why wrong: AWS Trusted Advisor includes a best practice check for IAM key rotation, but it is an advisory service that generates recommendations. It does not continuously enforce a specific rotation policy and does not automatically flag individual non-compliant keys for remediation or custom notifications in the same way AWS Config rules do.
B
AWS Config
AWS Config is a managed service that evaluates your AWS resource configurations against desired policies. The managed rule 'access-keys-rotated' continuously checks whether active IAM access keys have been rotated within the specified maximum age (e.g., 90 days). Non-compliant resources are identified, and you can configure Amazon SNS notifications to alert the security team. This meets the requirement for continuous evaluation and automated notification.
C
Amazon Inspector
Why wrong: Amazon Inspector is a vulnerability management service that performs automated security assessments on compute workloads such as Amazon EC2 instances, Amazon ECR container images, and AWS Lambda functions. It detects software vulnerabilities (CVEs) and unintended network exposure by analyzing the operating system and application packages, but it does not evaluate the configuration of IAM identities. Therefore, Inspector has no mechanism to check the age or rotation status of IAM user access keys and cannot enforce a policy requiring key rotation.
D
AWS IAM Access Analyzer
Why wrong: AWS IAM Access Analyzer helps identify resources in your account that are shared with an external entity by analyzing resource-based policies (e.g., S3 bucket policies, IAM role trust policies). It does not evaluate the age or rotation status of IAM user access keys.

Question 6mediummultiple choice

A company is using AWS Organizations to manage multiple AWS accounts. The security team wants to ensure that users in the development accounts cannot disable AWS CloudTrail logging or delete CloudTrail trails, even if those users have full administrator permissions within their own accounts. The team needs a central mechanism that is enforced across all development accounts regardless of individual IAM policies. Which AWS feature should the security team use to meet this requirement?

Trap 1: IAM policies

IAM policies define permissions for users and roles within a single account. However, an account administrator with full permissions can modify or bypass IAM policies. Since the requirement is for central enforcement across accounts regardless of individual permissions, IAM policies alone are insufficient.

Trap 2: AWS Config rules

AWS Config rules are detective controls that evaluate the recorded configuration of AWS resources against desired policies and can trigger remediation actions like SSM automation or Lambda functions. However, they operate asynchronously after a resource change or at a set frequency, so they cannot block the initial API call that disables CloudTrail. The rule can flag the non-compliant state and even attempt to re-enable the trail, but the disabling action itself has already occurred, making this an after-the-fact response rather than a preventive guardrail. In contrast, SCPs are evaluated before any action is allowed, providing a hard boundary that AWS Config rules inherently lack.

Trap 3: Amazon CloudWatch Events

Amazon CloudWatch Events (now part of Amazon EventBridge) can react to API calls (e.g., disabling CloudTrail) by invoking a Lambda function or sending a notification, but it does not prevent the action from happening. It is a reactive tool, not a preventive guardrail.

A
Service control policies (SCPs)
Correct. SCPs are used within AWS Organizations to set permission guardrails for member accounts. They are evaluated before IAM policies, so they can block actions even for users with full administrative IAM permissions, making them ideal for centrally enforcing restrictions like preventing CloudTrail from being disabled.
B
IAM policies
Why wrong: IAM policies define permissions for users and roles within a single account. However, an account administrator with full permissions can modify or bypass IAM policies. Since the requirement is for central enforcement across accounts regardless of individual permissions, IAM policies alone are insufficient.
C
AWS Config rules
Why wrong: AWS Config rules are detective controls that evaluate the recorded configuration of AWS resources against desired policies and can trigger remediation actions like SSM automation or Lambda functions. However, they operate asynchronously after a resource change or at a set frequency, so they cannot block the initial API call that disables CloudTrail. The rule can flag the non-compliant state and even attempt to re-enable the trail, but the disabling action itself has already occurred, making this an after-the-fact response rather than a preventive guardrail. In contrast, SCPs are evaluated before any action is allowed, providing a hard boundary that AWS Config rules inherently lack.
D
Amazon CloudWatch Events
Why wrong: Amazon CloudWatch Events (now part of Amazon EventBridge) can react to API calls (e.g., disabling CloudTrail) by invoking a Lambda function or sending a notification, but it does not prevent the action from happening. It is a reactive tool, not a preventive guardrail.

Question 7easymultiple choice

A security auditor needs to know which IAM user deleted a specific S3 bucket last week, from which IP address the action was taken, and at what exact time. Which AWS service captures this information?

Trap 1: Amazon CloudWatch

Amazon CloudWatch is an operational monitoring service for collecting metrics, logs, and alarms from AWS resources and applications. It does not natively record AWS API calls; although CloudTrail can be configured to deliver management event logs to CloudWatch Logs, the event data itself originates from CloudTrail, not CloudWatch. Thus, searching CloudWatch would only reveal the logs if you had already set up that CloudTrail-to-CloudWatch integration, and the definitive caller identity and timestamp for the S3 bucket deletion still come from CloudTrail, not CloudWatch.

Trap 2: AWS Config

AWS Config records the configuration state of AWS resources over time and can show that the bucket no longer exists, but it does not capture the API event details (caller identity, IP, timestamp) the way CloudTrail does.

Trap 3: Amazon GuardDuty

Amazon GuardDuty is a machine-learning-based threat detection service, not an API audit recorder. It continuously consumes CloudTrail management events, VPC Flow Logs, and DNS logs to detect anomalies such as compromised credentials or unusual S3 access patterns. While it may flag suspicious activity related to a bucket deletion, it relies on CloudTrail's audit records as a data source and cannot serve as the authoritative queryable history of who performed the DeleteBucket call.

A
Amazon CloudWatch
Why wrong: Amazon CloudWatch is an operational monitoring service for collecting metrics, logs, and alarms from AWS resources and applications. It does not natively record AWS API calls; although CloudTrail can be configured to deliver management event logs to CloudWatch Logs, the event data itself originates from CloudTrail, not CloudWatch. Thus, searching CloudWatch would only reveal the logs if you had already set up that CloudTrail-to-CloudWatch integration, and the definitive caller identity and timestamp for the S3 bucket deletion still come from CloudTrail, not CloudWatch.
B
AWS Config
Why wrong: AWS Config records the configuration state of AWS resources over time and can show that the bucket no longer exists, but it does not capture the API event details (caller identity, IP, timestamp) the way CloudTrail does.
C
AWS CloudTrail
CloudTrail logs every API call to AWS services, capturing the IAM identity, source IP, timestamp, and operation details. Searching CloudTrail for DeleteBucket events would show exactly who deleted the S3 bucket, when, and from which IP.
D
Amazon GuardDuty
Why wrong: Amazon GuardDuty is a machine-learning-based threat detection service, not an API audit recorder. It continuously consumes CloudTrail management events, VPC Flow Logs, and DNS logs to detect anomalies such as compromised credentials or unusual S3 access patterns. While it may flag suspicious activity related to a bucket deletion, it relies on CloudTrail's audit records as a data source and cannot serve as the authoritative queryable history of who performed the DeleteBucket call.

Question 8mediummultiple choice

A healthcare organization stores sensitive patient records in Amazon S3. The organization's compliance team learns that AWS stores data from multiple customers on the same physical hardware. They are concerned that data from different customers could be mixed or accessed by another customer. Which fundamental characteristic of cloud computing explains how AWS allows customers to share physical infrastructure while keeping each customer's data logically isolated?

Trap 1: Rapid elasticity

Rapid elasticity is the cloud characteristic that lets customers transparently scale resources up or down to match demand, often automatically and within minutes, giving the illusion of unlimited capacity. This dynamic provisioning can move workloads across many underlying physical servers, but the movement does not itself create or enforce the logical separation of stored patient records. The isolation that prevents cross-tenant data exposure is an architectural property of resource pooling, not an outcome of elastic scaling.

Trap 2: On-demand self-service

On-demand self-service describes a customer's ability to provision and configure computing resources—such as EC2 instances or S3 buckets—through a web console or API without needing a human administrator at the provider. This characteristic addresses operational convenience and automation, but says nothing about how a multi-tenant physical infrastructure keeps one customer's sensitive patient records from being accessed by another. The isolation mechanism in question is fundamentally a resource pooling design, not a self-service provisioning feature.

Trap 3: Measured service

Measured service refers to the cloud provider metering resource consumption—such as compute hours, storage gigabytes, or network I/O—and billing customers on a pay-as-you-go basis. For metering to be accurate, the provider must track usage across shared physical hardware, but the accounting abstraction does not establish the data-plane isolation needed to keep patient records private. It is a billing and optimization feature, not a security control for separating tenant data on the same hosts.

A
Rapid elasticity
Why wrong: Rapid elasticity is the cloud characteristic that lets customers transparently scale resources up or down to match demand, often automatically and within minutes, giving the illusion of unlimited capacity. This dynamic provisioning can move workloads across many underlying physical servers, but the movement does not itself create or enforce the logical separation of stored patient records. The isolation that prevents cross-tenant data exposure is an architectural property of resource pooling, not an outcome of elastic scaling.
B
Resource pooling
Resource pooling allows the provider to serve multiple customers from a shared pool of physical resources while logically isolating each customer's data and workloads. AWS uses multi-tenant architectures and security controls to ensure that one customer cannot access another customer's data, even when stored on the same hardware.
C
On-demand self-service
Why wrong: On-demand self-service describes a customer's ability to provision and configure computing resources—such as EC2 instances or S3 buckets—through a web console or API without needing a human administrator at the provider. This characteristic addresses operational convenience and automation, but says nothing about how a multi-tenant physical infrastructure keeps one customer's sensitive patient records from being accessed by another. The isolation mechanism in question is fundamentally a resource pooling design, not a self-service provisioning feature.
D
Measured service
Why wrong: Measured service refers to the cloud provider metering resource consumption—such as compute hours, storage gigabytes, or network I/O—and billing customers on a pay-as-you-go basis. For metering to be accurate, the provider must track usage across shared physical hardware, but the accounting abstraction does not establish the data-plane isolation needed to keep patient records private. It is a billing and optimization feature, not a security control for separating tenant data on the same hosts.

Question 9mediummultiple choice

A financial services company must encrypt all sensitive customer data stored in Amazon S3 using an encryption key that the company manages and rotates annually. The company also needs a complete, tamper-proof record of every time the key is used (including who used it and on which object) to satisfy regulatory audit requirements. Which AWS service should the company use to meet both the key management and audit logging requirements?

Trap 1: AWS Certificate Manager (ACM)

ACM is used to provision, manage, and deploy SSL/TLS certificates for use with AWS services like Elastic Load Balancing and CloudFront. It does not provide encryption keys for S3 object encryption nor does it log key usage events.

Trap 2: AWS CloudHSM

AWS CloudHSM offers dedicated hardware security modules for customer-managed keys, appealing for its high security and FIPS 140-2 Level 3 compliance where exclusive control over key material is paramount. However, it fails to natively provide the detailed, tamper-proof audit logging of *key usage on specific S3 objects* that the scenario demands. While CloudHSM logs administrative actions, it does not integrate with CloudTrail to log every data encryption/decryption operation involving keys for S3 objects in the required granular detail.

Trap 3: AWS Secrets Manager

Secrets Manager is designed to manage secrets such as database credentials, API keys, and passwords. It can automatically rotate secrets, but it is not used to create encryption keys for S3 objects or to log key usage events.

A
AWS Certificate Manager (ACM)
Why wrong: ACM is used to provision, manage, and deploy SSL/TLS certificates for use with AWS services like Elastic Load Balancing and CloudFront. It does not provide encryption keys for S3 object encryption nor does it log key usage events.
B
AWS Key Management Service (AWS KMS)
KMS enables you to create and manage customer-managed keys (CMKs) for encrypting data at rest in S3. It also integrates with AWS CloudTrail to log every key usage request, providing the required audit trail for compliance.
C
AWS CloudHSM
Why wrong: AWS CloudHSM offers dedicated hardware security modules for customer-managed keys, appealing for its high security and FIPS 140-2 Level 3 compliance where exclusive control over key material is paramount. However, it fails to natively provide the detailed, tamper-proof audit logging of *key usage on specific S3 objects* that the scenario demands. While CloudHSM logs administrative actions, it does not integrate with CloudTrail to log every data encryption/decryption operation involving keys for S3 objects in the required granular detail.
D
AWS Secrets Manager
Why wrong: Secrets Manager is designed to manage secrets such as database credentials, API keys, and passwords. It can automatically rotate secrets, but it is not used to create encryption keys for S3 objects or to log key usage events.

Question 10mediummultiple choice

A company stores sensitive customer data in Amazon S3 buckets. The company's security policy requires that all objects in these buckets be encrypted at rest using an encryption key that the company can rotate annually and audit for usage. The company also needs to control which IAM users and roles can use, create, and manage these keys. The security team wants to use an AWS managed service to handle the key management lifecycle. Which AWS service should the company use to meet these requirements?

Trap 1: Amazon S3 server-side encryption with customer-provided keys (SSE-C)

SSE-C lets you provide your own encryption key with each S3 PUT request, and S3 applies that key to encrypt the object and discards the key after the operation. The customer is fully responsible for generating, storing, rotating, and safeguarding those keys; AWS does not manage them. Since the company wants AWS to handle key management, SSE-C would shift that burden back to the customer and is therefore not the right choice.

Trap 2: AWS Certificate Manager (ACM)

ACM provisions and manages public and private SSL/TLS certificates used to encrypt network traffic in transit, such as HTTPS connections to CloudFront or Application Load Balancers. It does not generate or manage symmetric data encryption keys used for encrypting objects at rest in S3, and ACM certificates cannot be applied to S3 bucket encryption. Therefore, ACM would not provide any data-at-rest encryption key management for the stored customer data.

Trap 3: AWS Secrets Manager

Incorrect. AWS Secrets Manager is designed to manage secrets such as database credentials and API keys. While it can help with key rotation, it is not the primary service for managing encryption keys for data at rest in Amazon S3.

A
AWS Key Management Service (KMS)
AWS KMS is a managed encryption service that lets you create customer managed keys (CMKs) used to encrypt data at rest in Amazon S3. It integrates with S3's server-side encryption (SSE-KMS) to encrypt objects transparently, and provides centralized control over key policies, automatic annual rotation, and AWS CloudTrail auditing of key usage. This gives the company a fully managed key infrastructure without having to implement or operate their own key management hardware.
B
Amazon S3 server-side encryption with customer-provided keys (SSE-C)
Why wrong: SSE-C lets you provide your own encryption key with each S3 PUT request, and S3 applies that key to encrypt the object and discards the key after the operation. The customer is fully responsible for generating, storing, rotating, and safeguarding those keys; AWS does not manage them. Since the company wants AWS to handle key management, SSE-C would shift that burden back to the customer and is therefore not the right choice.
C
AWS Certificate Manager (ACM)
Why wrong: ACM provisions and manages public and private SSL/TLS certificates used to encrypt network traffic in transit, such as HTTPS connections to CloudFront or Application Load Balancers. It does not generate or manage symmetric data encryption keys used for encrypting objects at rest in S3, and ACM certificates cannot be applied to S3 bucket encryption. Therefore, ACM would not provide any data-at-rest encryption key management for the stored customer data.
D
AWS Secrets Manager
Why wrong: Incorrect. AWS Secrets Manager is designed to manage secrets such as database credentials and API keys. While it can help with key rotation, it is not the primary service for managing encryption keys for data at rest in Amazon S3.

Question 11mediummultiple choice

A company uses AWS Organizations to centrally manage multiple AWS accounts. The security team requires a mechanism to prevent any IAM user or role in any member account from modifying Amazon S3 bucket policies to grant public access. The solution must be enforced centrally and cannot be overridden by account administrators. Which AWS feature should the company use?

Trap 1: IAM permissions boundaries

IAM permissions boundaries limit the maximum permissions for an IAM user or role, but they are applied per entity and can be overridden by other policies within the account. They do not provide a centralized guardrail across all member accounts in an organization.

Trap 2: AWS Config conformance packs

AWS Config conformance packs contain a collection of AWS Config rules and remediation actions. They can evaluate resources against policies and trigger remediation, but they do not actively prevent actions; they detect and potentially fix noncompliant resources after the fact.

Trap 3: AWS CloudTrail Insights

AWS CloudTrail Insights uses machine learning to analyze management events and detect anomalous API activity, such as unexpected changes to S3 bucket policies, by establishing a baseline of normal behavior. However, it is strictly a detective control: it records and alerts on events after they occur and does not have any capability to evaluate, deny, or block an API call in real time. Since it cannot prevent an account administrator from modifying an S3 bucket policy, it is not a centralized preventive guardrail like an SCP.

A
IAM permissions boundaries
Why wrong: IAM permissions boundaries limit the maximum permissions for an IAM user or role, but they are applied per entity and can be overridden by other policies within the account. They do not provide a centralized guardrail across all member accounts in an organization.
B
Service control policies (SCPs)
SCPs are used in AWS Organizations to centrally manage permissions across all accounts. They define the maximum available permissions and can explicitly deny actions like modifying S3 bucket policies. SCPs apply to all principals in the account and cannot be bypassed by account administrators.
C
AWS Config conformance packs
Why wrong: AWS Config conformance packs contain a collection of AWS Config rules and remediation actions. They can evaluate resources against policies and trigger remediation, but they do not actively prevent actions; they detect and potentially fix noncompliant resources after the fact.
D
AWS CloudTrail Insights
Why wrong: AWS CloudTrail Insights uses machine learning to analyze management events and detect anomalous API activity, such as unexpected changes to S3 bucket policies, by establishing a baseline of normal behavior. However, it is strictly a detective control: it records and alerts on events after they occur and does not have any capability to evaluate, deny, or block an API call in real time. Since it cannot prevent an account administrator from modifying an S3 bucket policy, it is not a centralized preventive guardrail like an SCP.

Question 12mediummultiple choice

A company's security team needs to investigate a potential security incident. They want to determine which IAM user launched a new, unauthorized Amazon EC2 instance two days ago. The team needs to see the exact timestamp, the source IP address, and the instance type that was launched. Which AWS service should the security team use to find this information?

Trap 1: AWS Config

AWS Config evaluates resource configurations against desired policies and records configuration changes, but it does not record the identity of the user who made the change. Therefore, it cannot provide the specific IAM user who launched the instance.

Trap 2: Amazon GuardDuty

Amazon GuardDuty is a continuous security monitoring service that detects threats such as unusual API activity or compromised instances. However, it does not provide a comprehensive audit log of all API calls with caller identity and timestamps for historical investigation.

Trap 3: AWS Trusted Advisor

AWS Trusted Advisor inspects your AWS environment and provides best-practice recommendations in areas like cost, performance, security, and fault tolerance. It does not log or track API calls, so it cannot show who launched a specific instance.

A
AWS Config
Why wrong: AWS Config evaluates resource configurations against desired policies and records configuration changes, but it does not record the identity of the user who made the change. Therefore, it cannot provide the specific IAM user who launched the instance.
B
AWS CloudTrail
AWS CloudTrail records all API calls, including the caller identity, timestamp, source IP address, and request parameters. This enables the security team to determine which IAM user launched the EC2 instance, when, and from where.
C
Amazon GuardDuty
Why wrong: Amazon GuardDuty is a continuous security monitoring service that detects threats such as unusual API activity or compromised instances. However, it does not provide a comprehensive audit log of all API calls with caller identity and timestamps for historical investigation.
D
AWS Trusted Advisor
Why wrong: AWS Trusted Advisor inspects your AWS environment and provides best-practice recommendations in areas like cost, performance, security, and fault tolerance. It does not log or track API calls, so it cannot show who launched a specific instance.

Question 13mediummultiple choice

A company needs to integrate their on-premises Active Directory with AWS to enable SSO for employees accessing AWS services. Which AWS service provides this federation capability?

Trap 1: Amazon Cognito

Amazon Cognito is designed for authenticating end users of customer-facing applications, not for managing employee access to AWS accounts and services. Its user pools and identity pools issue tokens for app sessions and can federate external IdPs, but they do not provide consolidated access management to AWS organizations or support IAM permission sets across multiple accounts. Therefore, Cognito would not satisfy the requirement for workforce SSO to a set of AWS accounts.

Trap 2: AWS Directory Service AD Connector

AWS Directory Service AD Connector is only a lightweight proxy that redirects directory-related requests, such as LDAP or Kerberos, from AWS workloads to your on-premises Active Directory. It does not itself perform SSO or provide identity federation; it simply makes your existing directory available to AWS services that are explicitly configured to use it. As a result, AD Connector is a supporting component that IAM Identity Center can use to reach AD, not the service that delivers cross-account SSO.

Trap 3: AWS IAM roles

While IAM roles enable permissions for AWS resources, they lack the identity brokering protocols—such as SAML 2.0 or OIDC—required to federate an external identity source like on-premises Active Directory. IAM roles are tempting because they directly grant cross-account or service access within AWS, and would be correct for delegating permissions between AWS accounts or to an already-federated user authenticated via Microsoft Entra ID.

A
Amazon Cognito
Why wrong: Amazon Cognito is designed for authenticating end users of customer-facing applications, not for managing employee access to AWS accounts and services. Its user pools and identity pools issue tokens for app sessions and can federate external IdPs, but they do not provide consolidated access management to AWS organizations or support IAM permission sets across multiple accounts. Therefore, Cognito would not satisfy the requirement for workforce SSO to a set of AWS accounts.
B
AWS IAM Identity Center
AWS IAM Identity Center is the required AWS service for workforce single sign-on. It lets you integrate with your on-premises Active Directory through a directory source such as AWS Managed Microsoft AD or AD Connector, and then define permission sets that assign users and groups to roles across multiple AWS accounts. After authenticating once with their corporate credentials, users gain access to all AWS accounts and business applications they are permitted to use, without needing separate IAM sign-ins.
C
AWS Directory Service AD Connector
Why wrong: AWS Directory Service AD Connector is only a lightweight proxy that redirects directory-related requests, such as LDAP or Kerberos, from AWS workloads to your on-premises Active Directory. It does not itself perform SSO or provide identity federation; it simply makes your existing directory available to AWS services that are explicitly configured to use it. As a result, AD Connector is a supporting component that IAM Identity Center can use to reach AD, not the service that delivers cross-account SSO.
D
AWS IAM roles
Why wrong: While IAM roles enable permissions for AWS resources, they lack the identity brokering protocols—such as SAML 2.0 or OIDC—required to federate an external identity source like on-premises Active Directory. IAM roles are tempting because they directly grant cross-account or service access within AWS, and would be correct for delegating permissions between AWS accounts or to an already-federated user authenticated via Microsoft Entra ID.

Question 14easymultiple choice

Which AWS IAM feature allows you to set the maximum permissions that IAM entities in an account can have, regardless of what their identity-based policies allow?

Trap 1: IAM Conditions

IAM conditions are optional clauses within a policy statement that evaluate request context, such as source IP address, user principal, MFA status, or time of day, to determine whether a permission applies at request time. They enable fine-grained control over when and from where a permission can be used, but they never restrict the overall breadth of permissions granted to an IAM entity. A condition can block a specific request (e.g., deny access unless MFA is present), but it does not set an upper bound on the set of actions a user or role can perform across all possible contexts. Thus, conditions are contextual gates, not maximum-permission caps, making them incorrect for the scenario described.

Trap 2: Service Control Policies (SCPs)

Service control policies (SCPs) are an AWS Organizations feature that applies to member accounts, organizational units, or the entire organization, and they set maximum permission limits for all IAM principals (users and roles) within those scopes. However, SCPs do not attach to individual IAM users or roles within an account; they operate at the account or OU level as a guardrail on the overall account's allowable permissions. In contrast, permission boundaries are attached directly to a specific IAM user or role, allowing per-entity customization of maximum permissions. Because the question targets an individual IAM entity's maximum permissions rather than an account-wide restriction, SCPs are not the correct mechanism.

Trap 3: Resource-based policies

Resource-based policies are attached directly to resources such as S3 buckets, KMS keys, or SNS topics, and they specify which principals (IAM users, roles, or AWS services) can access that specific resource. These policies grant cross-account or cross-service access, but they do not place any cap on the maximum permissions that an IAM entity can hold. Instead, they expand who can use a resource, while the requesting principal's effective permissions are still governed by its own identity-based policies and any permission boundary that may be attached. Therefore, resource-based policies cannot limit an entity's maximum permission level; they only define resource access.

A
IAM Conditions
Why wrong: IAM conditions are optional clauses within a policy statement that evaluate request context, such as source IP address, user principal, MFA status, or time of day, to determine whether a permission applies at request time. They enable fine-grained control over when and from where a permission can be used, but they never restrict the overall breadth of permissions granted to an IAM entity. A condition can block a specific request (e.g., deny access unless MFA is present), but it does not set an upper bound on the set of actions a user or role can perform across all possible contexts. Thus, conditions are contextual gates, not maximum-permission caps, making them incorrect for the scenario described.
B
Permission Boundaries
A permission boundary is a managed policy that is explicitly attached to an IAM user or role to define the absolute maximum permissions that entity can be granted. When evaluating an entity's effective permissions, AWS takes the intersection of the identity-based policies (which may grant broad access) and the permission boundary; any action not allowed by the boundary is blocked even if explicitly allowed by an attached policy. This creates a hard ceiling on the entity's permissions, ensuring that even if more permissive policies are attached, the boundary limits what the principal can actually do. Because the question asks for the mechanism that caps the maximum permissions of an IAM entity, permission boundaries are precisely the correct answer.
C
Service Control Policies (SCPs)
Why wrong: Service control policies (SCPs) are an AWS Organizations feature that applies to member accounts, organizational units, or the entire organization, and they set maximum permission limits for all IAM principals (users and roles) within those scopes. However, SCPs do not attach to individual IAM users or roles within an account; they operate at the account or OU level as a guardrail on the overall account's allowable permissions. In contrast, permission boundaries are attached directly to a specific IAM user or role, allowing per-entity customization of maximum permissions. Because the question targets an individual IAM entity's maximum permissions rather than an account-wide restriction, SCPs are not the correct mechanism.
D
Resource-based policies
Why wrong: Resource-based policies are attached directly to resources such as S3 buckets, KMS keys, or SNS topics, and they specify which principals (IAM users, roles, or AWS services) can access that specific resource. These policies grant cross-account or cross-service access, but they do not place any cap on the maximum permissions that an IAM entity can hold. Instead, they expand who can use a resource, while the requesting principal's effective permissions are still governed by its own identity-based policies and any permission boundary that may be attached. Therefore, resource-based policies cannot limit an entity's maximum permission level; they only define resource access.

Question 15mediummultiple choice

A company has 200 IAM users. The security team needs to automatically verify that every IAM user has enabled multi-factor authentication (MFA) for console access. They also need to receive a notification whenever a new user is created without MFA so they can enforce the policy. Which AWS service should the security team use to meet these requirements?

Trap 1: AWS CloudTrail

AWS CloudTrail records every API action taken in the account, such as EnableMFADevice or DeactivateMFADevice calls, creating an audit trail for investigators. However, it does not evaluate resource configurations against compliance policies or produce alerts about users currently missing MFA. To detect non-compliance with CloudTrail, you would have to build a separate system that analyzes the logs and cross-references IAM user states, which is not the purpose of the service.

Trap 2: Amazon GuardDuty

Amazon GuardDuty is an intelligent threat detection service that analyzes CloudTrail management events, VPC flow logs, and DNS logs for signs of malicious activity like compromised credentials or unauthorized access. It delivers findings about active threats, but it does not maintain a compliance inventory of IAM users or verify whether each user has MFA enabled. MFA configuration status is not part of GuardDuty's findings schema, so it cannot answer the security team's verification requirement.

Trap 3: AWS Trusted Advisor

AWS Trusted Advisor checks for security best practices, but its MFA check only covers the root account, not all IAM users. It also does not provide continuous evaluation or event-driven alerts for specific resource configuration changes.

A
AWS Config
AWS Config continuously monitors the configuration of AWS resources and evaluates them against managed rules such as iam-user-mfa-enabled. This rule checks every IAM user's MFA status and reports any user without an assigned MFA device as non-compliant, allowing the security team to receive automated notifications via Amazon SNS or EventBridge. Additionally, AWS Config can be paired with Systems Manager Automation to auto-remediate non-compliant users, making it the correct service for verifying MFA across 200 IAM users.
B
AWS CloudTrail
Why wrong: AWS CloudTrail records every API action taken in the account, such as EnableMFADevice or DeactivateMFADevice calls, creating an audit trail for investigators. However, it does not evaluate resource configurations against compliance policies or produce alerts about users currently missing MFA. To detect non-compliance with CloudTrail, you would have to build a separate system that analyzes the logs and cross-references IAM user states, which is not the purpose of the service.
C
Amazon GuardDuty
Why wrong: Amazon GuardDuty is an intelligent threat detection service that analyzes CloudTrail management events, VPC flow logs, and DNS logs for signs of malicious activity like compromised credentials or unauthorized access. It delivers findings about active threats, but it does not maintain a compliance inventory of IAM users or verify whether each user has MFA enabled. MFA configuration status is not part of GuardDuty's findings schema, so it cannot answer the security team's verification requirement.
D
AWS Trusted Advisor
Why wrong: AWS Trusted Advisor checks for security best practices, but its MFA check only covers the root account, not all IAM users. It also does not provide continuous evaluation or event-driven alerts for specific resource configuration changes.

Question 16mediummultiple choice

An application running on an Amazon EC2 instance needs to access an Amazon S3 bucket. The security team requires that no long-term access keys be stored on the instance. Which IAM feature should be used to grant the EC2 instance permission to access S3?

Trap 1: Create an IAM user and embed the access key in the application code

Creating an IAM user for an EC2 application and embedding the access key ID and secret access key directly in source code is insecure because these are long-term static credentials. If the code is committed to a repository, pushed to a CI/CD system, or packaged into an AMI, the keys can be exfiltrated and there is no automatic rotation. Unlike a role attached to the instance, you must manually rotate and manage those keys, and they grant broad permissions for as long as they remain valid.

Trap 2: Store the access key in an EC2 environment variable

Storing an IAM user's access key in an environment variable on the EC2 instance is still relying on a long-lived credential rather than temporary credentials. Any user or process on the instance, including a compromised dependency or an attacker with OS-level access, can read process environment variables via /proc/<pid>/environ, so the key is effectively available to anything running on the host. In contrast, an instance profile supplies short-lived, automatically rotated credentials from the metadata service.

Trap 3: Use an IAM group to assign the permissions to the EC2 instance

IAM groups are purely a container for IAM users; group policies are evaluated only when the IAM user making the request is a member of the group. An EC2 instance is not an IAM principal and cannot be added to a group, so assigning the group to the instance is not a valid operation. To grant permissions to an EC2 instance, you attach an IAM role to the instance profile, and the instance acquires the role's temporary credentials through the instance metadata service.

A
Create an IAM user and embed the access key in the application code
Why wrong: Creating an IAM user for an EC2 application and embedding the access key ID and secret access key directly in source code is insecure because these are long-term static credentials. If the code is committed to a repository, pushed to a CI/CD system, or packaged into an AMI, the keys can be exfiltrated and there is no automatic rotation. Unlike a role attached to the instance, you must manually rotate and manage those keys, and they grant broad permissions for as long as they remain valid.
B
Store the access key in an EC2 environment variable
Why wrong: Storing an IAM user's access key in an environment variable on the EC2 instance is still relying on a long-lived credential rather than temporary credentials. Any user or process on the instance, including a compromised dependency or an attacker with OS-level access, can read process environment variables via /proc/<pid>/environ, so the key is effectively available to anything running on the host. In contrast, an instance profile supplies short-lived, automatically rotated credentials from the metadata service.
C
Attach an IAM role to the EC2 instance
An IAM role attached to an EC2 instance (via an instance profile) provides temporary, automatically rotating credentials. The EC2 metadata service delivers these credentials to the application, eliminating the need to store any long-term access keys.
D
Use an IAM group to assign the permissions to the EC2 instance
Why wrong: IAM groups are purely a container for IAM users; group policies are evaluated only when the IAM user making the request is a member of the group. An EC2 instance is not an IAM principal and cannot be added to a group, so assigning the group to the instance is not a valid operation. To grant permissions to an EC2 instance, you attach an IAM role to the instance profile, and the instance acquires the role's temporary credentials through the instance metadata service.

Question 17mediummultiple choice

A company requires all IAM users to have multi-factor authentication (MFA) enabled for AWS Management Console access. The security team needs an automated way to continuously detect any IAM user without an MFA device and generate a compliance report. The solution must not require custom code. Which AWS service should the team use?

Trap 1: IAM Access Analyzer

IAM Access Analyzer is designed to identify resources, such as S3 buckets, IAM roles, or KMS keys, that are shared with external principals by analyzing resource-based policies. It does not inspect the authentication configuration of IAM users, including whether multi-factor authentication is enabled. Access Analyzer's purpose is to pinpoint unintended external access, not to enforce or audit MFA requirements for identities.

Trap 2: AWS Trusted Advisor

AWS Trusted Advisor includes a security check titled 'MFA on Root Account,' which only verifies that the account root user has MFA enabled. It does not evaluate MFA status for individual IAM users and does not provide customizable compliance reporting or alerting for identity configurations. Trusted Advisor is a best-practice dashboard, not a continuous, account-wide configuration compliance service, so it does not meet this requirement.

Trap 3: Amazon Inspector

Amazon Inspector is a vulnerability management service that continuously scans Amazon EC2 instances, container images in Amazon ECR, and Lambda functions for software vulnerabilities and unintended network exposure. It has no integration with IAM identity configuration and cannot read or evaluate user-level authentication settings such as MFA status. Therefore, while Inspector is useful for workload security, it is not a mechanism for enforcing or reporting on IAM user MFA compliance.

A
AWS Config
AWS Config is the appropriate service because it offers a managed rule named iam-user-mfa-enabled, which evaluates each IAM user and returns a non-compliant result if MFA is not activated. Config continuously records changes to IAM users and, when paired with conformance packs, can provide automated compliance reports and even trigger remediation actions. This satisfies the requirement without requiring any custom code.
B
IAM Access Analyzer
Why wrong: IAM Access Analyzer is designed to identify resources, such as S3 buckets, IAM roles, or KMS keys, that are shared with external principals by analyzing resource-based policies. It does not inspect the authentication configuration of IAM users, including whether multi-factor authentication is enabled. Access Analyzer's purpose is to pinpoint unintended external access, not to enforce or audit MFA requirements for identities.
C
AWS Trusted Advisor
Why wrong: AWS Trusted Advisor includes a security check titled 'MFA on Root Account,' which only verifies that the account root user has MFA enabled. It does not evaluate MFA status for individual IAM users and does not provide customizable compliance reporting or alerting for identity configurations. Trusted Advisor is a best-practice dashboard, not a continuous, account-wide configuration compliance service, so it does not meet this requirement.
D
Amazon Inspector
Why wrong: Amazon Inspector is a vulnerability management service that continuously scans Amazon EC2 instances, container images in Amazon ECR, and Lambda functions for software vulnerabilities and unintended network exposure. It has no integration with IAM identity configuration and cannot read or evaluate user-level authentication settings such as MFA status. Therefore, while Inspector is useful for workload security, it is not a mechanism for enforcing or reporting on IAM user MFA compliance.

Question 18mediummultiple choice

A company wants to identify all resources in their AWS account that are accessible from outside the account — such as S3 buckets with public access or IAM roles with external trust. Which AWS service provides this analysis?

Trap 1: Amazon Inspector

Amazon Inspector is a vulnerability management service that continuously scans Amazon EC2 instances, container images in Amazon ECR, and AWS Lambda functions for software vulnerabilities and unintended network exposure. Its findings focus on CVEs and network reachability from the internet, not on analyzing IAM resource policies to determine whether an external principal can access a resource. Inspector does not model policy logic or generate findings for cross-account access paths.

Trap 2: Amazon GuardDuty

Amazon GuardDuty is a threat detection service powered by machine learning and continuously monitors CloudTrail management events, VPC Flow Logs, and DNS logs for indicators of compromise. Its findings describe active or suspicious behavior, such as crypto mining, credential exfiltration, or unusual API calls, not the latent permissions granted by resource policies. GuardDuty cannot infer that a resource policy allows external access because it evaluates runtime activity, not the applicable policy logic.

Trap 3: AWS Config

AWS Config is a configuration assessment and compliance service that records configuration changes and evaluates resources against managed or custom rules, such as requiring S3 buckets to be private or enabling encryption. While Config can flag a bucket as noncompliant if its policy is public, it applies predefined rule evaluation rather than automated reasoning to discover all external access paths across different resource types. Config does not produce findings that list the external principal, action, and condition that make a resource accessible from outside the organization.

A
Amazon Inspector
Why wrong: Amazon Inspector is a vulnerability management service that continuously scans Amazon EC2 instances, container images in Amazon ECR, and AWS Lambda functions for software vulnerabilities and unintended network exposure. Its findings focus on CVEs and network reachability from the internet, not on analyzing IAM resource policies to determine whether an external principal can access a resource. Inspector does not model policy logic or generate findings for cross-account access paths.
B
AWS IAM Access Analyzer
AWS IAM Access Analyzer uses automated reasoning to analyze the resource policies attached to supported resources such as S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, and Secrets Manager secrets. It generates findings whenever a policy grants access to a principal from outside the account or outside your AWS Organization, identifying the external entity, actions, and conditions. This is exactly the static, policy-level analysis needed to detect resources reachable by external accounts.
C
Amazon GuardDuty
Why wrong: Amazon GuardDuty is a threat detection service powered by machine learning and continuously monitors CloudTrail management events, VPC Flow Logs, and DNS logs for indicators of compromise. Its findings describe active or suspicious behavior, such as crypto mining, credential exfiltration, or unusual API calls, not the latent permissions granted by resource policies. GuardDuty cannot infer that a resource policy allows external access because it evaluates runtime activity, not the applicable policy logic.
D
AWS Config
Why wrong: AWS Config is a configuration assessment and compliance service that records configuration changes and evaluates resources against managed or custom rules, such as requiring S3 buckets to be private or enabling encryption. While Config can flag a bucket as noncompliant if its policy is public, it applies predefined rule evaluation rather than automated reasoning to discover all external access paths across different resource types. Config does not produce findings that list the external principal, action, and condition that make a resource accessible from outside the organization.

Question 19hardmultiple choice

A customer is evaluating moving to AWS and asks about the total cost of ownership (TCO) benefits. Which of the following is NOT a factor that reduces TCO when migrating to AWS?

Trap 1: Eliminating hardware refresh cycles

Eliminating hardware refresh cycles is a well-recognized TCO benefit of cloud migration because the cloud provider continuously upgrades its underlying servers and storage without requiring the customer to purchase new equipment on a fixed lifecycle. This shifts capital expenditure (CapEx) on periodic hardware replacement to operational expenditure (OpEx) that scales with actual usage. Since this action clearly lowers long-term infrastructure costs, it cannot be the correct answer to a question asking for an item that does NOT reduce TCO.

Trap 2: Reducing data center facility costs

Reducing data center facility costs is another direct TCO advantage, as moving to the cloud removes the need for physical space, power, cooling, and on-site maintenance that are otherwise fixed expenses of running a private data center. Customers no longer pay for idle capacity or facility overhead, and instead pay only for the compute and storage resources they consume. Because this significantly lowers the total cost of ownership, it is a wrong answer for a question seeking a cost-increasing factor.

Trap 3: Pay-as-you-go pricing model

The pay-as-you-go pricing model is a foundational TCO benefit of cloud computing because it replaces large upfront infrastructure purchases with flexible per-use billing, allowing organizations to match costs exactly to actual demand. This model eliminates the expense of over-provisioning and avoids paying for idle resources, directly reducing the overall total cost of ownership. Since this is a key mechanism for achieving cloud cost savings, it cannot be the correct answer to the question.

A
Eliminating hardware refresh cycles
Why wrong: Eliminating hardware refresh cycles is a well-recognized TCO benefit of cloud migration because the cloud provider continuously upgrades its underlying servers and storage without requiring the customer to purchase new equipment on a fixed lifecycle. This shifts capital expenditure (CapEx) on periodic hardware replacement to operational expenditure (OpEx) that scales with actual usage. Since this action clearly lowers long-term infrastructure costs, it cannot be the correct answer to a question asking for an item that does NOT reduce TCO.
B
Reducing data center facility costs
Why wrong: Reducing data center facility costs is another direct TCO advantage, as moving to the cloud removes the need for physical space, power, cooling, and on-site maintenance that are otherwise fixed expenses of running a private data center. Customers no longer pay for idle capacity or facility overhead, and instead pay only for the compute and storage resources they consume. Because this significantly lowers the total cost of ownership, it is a wrong answer for a question seeking a cost-increasing factor.
C
Staff training costs for cloud technologies
Staff training costs for cloud technologies are not a TCO reduction; they are an additional upfront investment required when an organization migrates to the cloud. Existing IT staff must learn new skills such as cloud architecture, security best practices, and service-specific management, and these training expenses can actually increase total cost of ownership during the transition period. Unlike the other options, this represents a cost increase rather than a savings, making it the correct answer to the question.
D
Pay-as-you-go pricing model
Why wrong: The pay-as-you-go pricing model is a foundational TCO benefit of cloud computing because it replaces large upfront infrastructure purchases with flexible per-use billing, allowing organizations to match costs exactly to actual demand. This model eliminates the expense of over-provisioning and avoids paying for idle resources, directly reducing the overall total cost of ownership. Since this is a key mechanism for achieving cloud cost savings, it cannot be the correct answer to the question.

Question 20mediummultiple choice

A company manages multiple AWS accounts using AWS Organizations and maintains hundreds of Amazon S3 buckets across these accounts. The security team wants a service that automatically scans all S3 bucket policies and identifies any bucket that grants access to an external AWS account (an account outside the organization). The team needs to receive findings when such policies are detected and wants to review the findings in a centralized dashboard. Which AWS service should the security team use to meet these requirements?

Trap 1: AWS Trusted Advisor

AWS Trusted Advisor inspects AWS environments and provides best-practice recommendations in categories including cost, performance, security, and fault tolerance. It can check S3 bucket permissions for public access, but it does not specifically analyze policies for access granted to specific external AWS accounts, and it does not provide a continuous policy analysis dashboard for external access findings.

Trap 2: AWS Config

AWS Config evaluates the configuration of AWS resources against desired rules and tracks configuration changes. While it can be used to detect changes to S3 bucket policies, it does not natively analyze whether a policy grants access to an external AWS account. Config is more about compliance with internal rules (e.g., 'require encryption') rather than detecting external access.

Trap 3: AWS Service Catalog

AWS Service Catalog helps organizations centrally manage approved IT service catalogs and allows users to launch only pre-approved resources. It does not have any capability to analyze existing S3 bucket policies for external access. This service is used for governance and provisioning, not for post-deployment policy analysis.

A
AWS Trusted Advisor
Why wrong: AWS Trusted Advisor inspects AWS environments and provides best-practice recommendations in categories including cost, performance, security, and fault tolerance. It can check S3 bucket permissions for public access, but it does not specifically analyze policies for access granted to specific external AWS accounts, and it does not provide a continuous policy analysis dashboard for external access findings.
B
AWS IAM Access Analyzer
IAM Access Analyzer analyzes resource-based policies across supported resources (including S3 buckets) and identifies when access is granted to an external entity, such as an AWS account outside the organization. It provides a centralized console to review findings and can send alerts via AWS Security Hub or Amazon EventBridge. This directly meets the requirement to automatically detect buckets accessible to external accounts.
C
AWS Config
Why wrong: AWS Config evaluates the configuration of AWS resources against desired rules and tracks configuration changes. While it can be used to detect changes to S3 bucket policies, it does not natively analyze whether a policy grants access to an external AWS account. Config is more about compliance with internal rules (e.g., 'require encryption') rather than detecting external access.
D
AWS Service Catalog
Why wrong: AWS Service Catalog helps organizations centrally manage approved IT service catalogs and allows users to launch only pre-approved resources. It does not have any capability to analyze existing S3 bucket policies for external access. This service is used for governance and provisioning, not for post-deployment policy analysis.