IAM Policy practice questions

A company is designing a data lake on Amazon S3. Data is ingested from multiple sources and stored as Parquet files partitioned by date. The company needs to ensure that only authorized users can access the data, and that the data is encrypted at rest. Which TWO actions should the company take to meet these requirements? (Choose TWO.)

Trap 1: Use client-side encryption before uploading to S3.

Client-side encryption protects data before upload but places key management entirely on the company, and it does nothing to enforce which users may access objects. It is tempting because it satisfies encryption at rest, yet SSE-KMS with bucket policies and IAM handles both authorisation and encryption natively.

Trap 2: Enable S3 server access logging.

Server access logging records requests made to the bucket for auditing purposes; it neither restricts access to authorised users nor encrypts stored objects. It is tempting because logging sounds security-related, but the requirement is authorisation and encryption at rest, which logging cannot deliver.

Trap 3: Use a bucket ACL to grant access to the data lake.

Bucket ACLs grant coarse read/write permissions to predefined grantee groups and cannot express the fine-grained, identity-based authorisation the scenario needs. They are tempting as a legacy S3 access mechanism, but IAM policies with bucket policies provide the required least-privilege control.

A
Enable default encryption with SSE-KMS on the S3 bucket.
SSE-KMS default encryption ensures every object written to the bucket is encrypted at rest using AWS KMS keys, satisfying the encryption requirement. It also enables granular key policies and audit trails via CloudTrail, supporting control over who can decrypt the data lake contents.
B
Use client-side encryption before uploading to S3.
Why it fails: Client-side encryption protects data before upload but places key management entirely on the company, and it does nothing to enforce which users may access objects. It is tempting because it satisfies encryption at rest, yet SSE-KMS with bucket policies and IAM handles both authorisation and encryption natively.
C
Enable S3 server access logging.
Why it fails: Server access logging records requests made to the bucket for auditing purposes; it neither restricts access to authorised users nor encrypts stored objects. It is tempting because logging sounds security-related, but the requirement is authorisation and encryption at rest, which logging cannot deliver.
D
Use a bucket ACL to grant access to the data lake.
Why it fails: Bucket ACLs grant coarse read/write permissions to predefined grantee groups and cannot express the fine-grained, identity-based authorisation the scenario needs. They are tempting as a legacy S3 access mechanism, but IAM policies with bucket policies provide the required least-privilege control.
E
Configure an S3 bucket policy that allows access only from specific IAM roles.
An S3 bucket policy restricting access to specific IAM roles enforces least-privilege authorisation at the bucket level, ensuring only approved identities can read or write the Parquet data. This directly satisfies the requirement that only authorised users access the data lake.

Question 2easymultiple choice

A company uses AWS Organizations with multiple OUs. The DevOps team needs to allow developers to launch EC2 instances only of type t3.micro in the dev OU. Which action should the team take?

Trap 1: Create an IAM role with a policy that allows only t3.micro, and…

IAM policies attached to users cannot restrict instance type by OU, because instance-type conditions such as ec2:InstanceType are evaluated per principal, not per organisational unit, and users could assume other roles. IAM roles suit granting permissions to specific identities or workloads.

Trap 2: Use AWS CloudFormation templates that specify t3.micro.

CloudFormation templates constrain only resources created through those stacks; developers launching instances via the console, CLI or SDK bypass the template entirely, so t3.micro is not enforced. Templates are correct when standardising repeatable, version-controlled infrastructure deployments.

Trap 3: Use AWS Config rules to terminate non-compliant instances.

AWS Config rules detect and report non-compliant instances after launch, and remediation terminates them rather than preventing creation; the requirement is to allow only t3.micro. Config is the right choice for continuous compliance auditing and drift detection across accounts.

A
Create an IAM role with a policy that allows only t3.micro, and attach it to users in the dev OU.
Why it fails: IAM policies attached to users cannot restrict instance type by OU, because instance-type conditions such as ec2:InstanceType are evaluated per principal, not per organisational unit, and users could assume other roles. IAM roles suit granting permissions to specific identities or workloads.
B
Use AWS CloudFormation templates that specify t3.micro.
Why it fails: CloudFormation templates constrain only resources created through those stacks; developers launching instances via the console, CLI or SDK bypass the template entirely, so t3.micro is not enforced. Templates are correct when standardising repeatable, version-controlled infrastructure deployments.
C
Apply a Service Control Policy (SCP) to the dev OU that denies ec2:RunInstances with instance type not equal to t3.micro.
SCPs define the maximum available permissions for principals in member accounts and apply at the OU level, so attaching this policy to the dev OU blocks RunInstances for any instance type other than t3.micro across every account beneath it, satisfying the OU-wide restriction without per-account IAM edits.
D
Use AWS Config rules to terminate non-compliant instances.
Why it fails: AWS Config rules detect and report non-compliant instances after launch, and remediation terminates them rather than preventing creation; the requirement is to allow only t3.micro. Config is the right choice for continuous compliance auditing and drift detection across accounts.

Question 3easymultiple choice

A company wants to share a large dataset stored in Amazon S3 with a partner who has their own AWS account. The partner needs to access the data using their own account credentials. Which approach should the company use?

Trap 1: Use S3 cross-region replication.

Cross-region replication copies objects into another bucket you own; it cannot grant a partner's account principals access, since authorisation still requires a bucket policy or ACL naming that account. It tempts because replication genuinely serves durability, latency and compliance scenarios across Regions you control.

Trap 2: Create a pre-signed URL for the partner.

A pre-signed URL embeds the issuer's credentials, so the partner accesses objects as the signing identity rather than with their own account credentials, and it expires. It tempts because pre-signed URLs correctly grant temporary access to unauthenticated users or one-off downloads.

Trap 3: Provide the partner with an IAM user in the company's account.

Creating an IAM user inside the company's account gives the partner credentials belonging to that account, not their own, and breaches credential-sharing practice. It tempts because cross-account IAM roles are the standard mechanism, and IAM users are genuinely correct for identities within a single account.

A
Use S3 cross-region replication.
Why it fails: Cross-region replication copies objects into another bucket you own; it cannot grant a partner's account principals access, since authorisation still requires a bucket policy or ACL naming that account. It tempts because replication genuinely serves durability, latency and compliance scenarios across Regions you control.
B
Grant the partner's AWS account access via a bucket policy.
A bucket policy grants cross-account access directly to the partner's AWS account principal, letting them use their own credentials without sharing keys. This satisfies the requirement for account-to-account sharing of a large S3 dataset, unlike IAM users or presigned URLs, which are tied to the source account or expire.
C
Create a pre-signed URL for the partner.
Why it fails: A pre-signed URL embeds the issuer's credentials, so the partner accesses objects as the signing identity rather than with their own account credentials, and it expires. It tempts because pre-signed URLs correctly grant temporary access to unauthenticated users or one-off downloads.
D
Provide the partner with an IAM user in the company's account.
Why it fails: Creating an IAM user inside the company's account gives the partner credentials belonging to that account, not their own, and breaches credential-sharing practice. It tempts because cross-account IAM roles are the standard mechanism, and IAM users are genuinely correct for identities within a single account.

Question 4mediummultiple choice

A company has multiple AWS accounts and wants to use AWS CloudFormation StackSets to deploy a common set of resources across all accounts. The StackSet should be managed from the management account. What permissions are required?

Trap 1: Create IAM users in target accounts with AdministratorAccess.

StackSets do not use IAM users.

Trap 2: Use a CloudFormation service role in the management account.

Service role is for stack operations in one account.

Trap 3: Apply an SCP to allow CloudFormation actions across accounts.

SCPs only restrict, they don't grant permissions.

A
Create IAM users in target accounts with AdministratorAccess.
Why it fails: StackSets do not use IAM users.
B
Create an IAM role in each target account with a trust policy allowing the management account to assume it.
StackSets needs a trust relationship in every target account so the management account can assume a role and deploy stacks. Creating an IAM role in each target account, with a trust policy naming the management account, satisfies the cross-account assumption requirement.
C
Use a CloudFormation service role in the management account.
Why it fails: Service role is for stack operations in one account.
D
Apply an SCP to allow CloudFormation actions across accounts.
Why it fails: SCPs only restrict, they don't grant permissions.

Question 5mediummulti select

A company is implementing a multi-account strategy using AWS Organizations. They want to centralize CloudTrail logs from all accounts into a single S3 bucket in the management account. Which TWO steps are required to achieve this? (Choose two.)

Trap 1: Use S3 replication to copy logs from member account buckets to the…

S3 replication copies objects between buckets, but member accounts have no CloudTrail buckets to replicate from — the trail writes straight to the central bucket. Replication is correct for duplicating an existing regional bucket for compliance or latency, not for aggregating trails.

Trap 2: Create an IAM role in each member account that allows CloudTrail to…

CloudTrail writes to the central bucket directly via the bucket policy and the organisation trail; no per-account IAM role is needed because CloudTrail assumes the service-linked role, not a customer role. Cross-account roles suit delegated administration, not log delivery.

Trap 3: Enable AWS Config in each member account to forward logs to the…

AWS Config records resource configuration changes, not CloudTrail API activity, and cannot forward CloudTrail logs. It is tempting because Config also aggregates multi-account data, but that aggregation covers configuration items and conformance packs, not the CloudTrail event stream the scenario requires.

A
Use S3 replication to copy logs from member account buckets to the central bucket.
Why it fails: S3 replication copies objects between buckets, but member accounts have no CloudTrail buckets to replicate from — the trail writes straight to the central bucket. Replication is correct for duplicating an existing regional bucket for compliance or latency, not for aggregating trails.
B
Create an IAM role in each member account that allows CloudTrail to write to the central bucket.
Why it fails: CloudTrail writes to the central bucket directly via the bucket policy and the organisation trail; no per-account IAM role is needed because CloudTrail assumes the service-linked role, not a customer role. Cross-account roles suit delegated administration, not log delivery.
C
Enable AWS Config in each member account to forward logs to the central bucket.
Why it fails: AWS Config records resource configuration changes, not CloudTrail API activity, and cannot forward CloudTrail logs. It is tempting because Config also aggregates multi-account data, but that aggregation covers configuration items and conformance packs, not the CloudTrail event stream the scenario requires.
D
Create a CloudTrail trail in the management account with the 'Enable for all accounts in my organization' option.
Creating an organisation trail with 'Enable for all accounts in my organization' automatically applies the trail to every account, delivering their events to the central S3 bucket. This satisfies the centralisation requirement without configuring each account individually.
E
Configure the S3 bucket policy to grant the CloudTrail service principal write access from all accounts.
The S3 bucket policy must grant the CloudTrail service principal write access, including from all member accounts, otherwise log delivery fails. This satisfies the requirement that the single management-account bucket accepts logs from every account in the organisation.

Question 6hardmultiple choice

A solutions architect is reviewing the above IAM policy attached to an S3 bucket. A user from IP address 10.0.1.5 makes a request over HTTP (not HTTPS). Will the user be able to download an object?

Exhibit

Refer to the exhibit.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/8"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::example-bucket/*",
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

Trap 1: No, because the IP address is not in the allowed range.

10.0.1.5 does fall within the allowed range, so the IP condition passes; the request fails because it uses HTTP, triggering the SecureTransport Deny. Range-based rejection is tempting since CIDR matching is a common access control, but here the transport condition is decisive.

Trap 2: Yes, because the IP address is allowed.

The IP condition is satisfied, but the policy's Deny on aws:SecureTransport false blocks any request over HTTP, and explicit Deny overrides Allow. IP allowlisting is tempting because it governs network origin, and would grant access if the request arrived over HTTPS.

Trap 3: Yes, because the Allow statement is evaluated first.

IAM evaluates all statements together; an explicit Deny always overrides any Allow, regardless of order. Allow-first evaluation is tempting because it sounds like a precedence rule, but the actual mechanism is deny-wins, so the HTTP request is refused despite the matching Allow.

A
No, because the IP address is not in the allowed range.
Why it fails: 10.0.1.5 does fall within the allowed range, so the IP condition passes; the request fails because it uses HTTP, triggering the SecureTransport Deny. Range-based rejection is tempting since CIDR matching is a common access control, but here the transport condition is decisive.
B
Yes, because the IP address is allowed.
Why it fails: The IP condition is satisfied, but the policy's Deny on aws:SecureTransport false blocks any request over HTTP, and explicit Deny overrides Allow. IP allowlisting is tempting because it governs network origin, and would grant access if the request arrived over HTTPS.
C
No, because the request is not using HTTPS.
The policy's explicit Deny for `aws:SecureTransport: false` overrides any Allow, so the HTTP request from 10.0.1.5 is blocked regardless of source IP. AWS evaluates Deny first, making the insecure transport condition the decisive constraint that prevents the object download.
D
Yes, because the Allow statement is evaluated first.
Why it fails: IAM evaluates all statements together; an explicit Deny always overrides any Allow, regardless of order. Allow-first evaluation is tempting because it sounds like a precedence rule, but the actual mechanism is deny-wins, so the HTTP request is refused despite the matching Allow.

Question 7hardmultiple choice

A company has a bucket policy on an S3 bucket as shown in the exhibit. A cross-account role (CrossAccountRole) is used to access the bucket. The role has an IAM policy that allows s3:GetObject and s3:PutObject on the bucket. When users assume the role and try to upload objects without specifying encryption, the upload fails. What must the users do to successfully upload objects?

Exhibit

Refer to the exhibit.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/CrossAccountRole"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    }
  ]
}

Trap 1: Remove the condition from the bucket policy.

Deleting the condition removes the encryption requirement entirely, weakening the bucket's security posture rather than satisfying it. The condition is what blocks unencrypted uploads, so removing it lets data land unencrypted. Editing the policy is tempting as a quick fix, but the correct approach supplies the encryption the condition demands.

Trap 2: Add an IAM policy that allows s3:PutObject to the role.

The role already allows s3:PutObject, so adding another identical permission changes nothing; the failure comes from the bucket policy's encryption condition, not from IAM. Duplicating an existing allow is tempting because IAM denials commonly cause access failures. Here the request must carry the required encryption header to pass the policy.

Trap 3: Grant the role permission to use the KMS key.

The bucket policy's condition requires a specific encryption header, so granting KMS permissions does not satisfy it; the upload still fails the policy check. KMS permissions matter only when objects use SSE-KMS, which is the tempting association here. The scenario needs the request to meet the encryption condition, not key access.

A
Remove the condition from the bucket policy.
Why it fails: Deleting the condition removes the encryption requirement entirely, weakening the bucket's security posture rather than satisfying it. The condition is what blocks unencrypted uploads, so removing it lets data land unencrypted. Editing the policy is tempting as a quick fix, but the correct approach supplies the encryption the condition demands.
B
Add an IAM policy that allows s3:PutObject to the role.
Why it fails: The role already allows s3:PutObject, so adding another identical permission changes nothing; the failure comes from the bucket policy's encryption condition, not from IAM. Duplicating an existing allow is tempting because IAM denials commonly cause access failures. Here the request must carry the required encryption header to pass the policy.
C
Include the x-amz-server-side-encryption header with value aws:kms in the upload request.
The bucket policy likely denies PutObject unless the request specifies SSE-KMS encryption. Adding the x-amz-server-side-encryption header with aws:kms satisfies that condition, so the assumed role's s3:PutObject permission is no longer blocked by the explicit deny.
D
Grant the role permission to use the KMS key.
Why it fails: The bucket policy's condition requires a specific encryption header, so granting KMS permissions does not satisfy it; the upload still fails the policy check. KMS permissions matter only when objects use SSE-KMS, which is the tempting association here. The scenario needs the request to meet the encryption condition, not key access.

Question 8mediummulti select

A company is designing a multi-account strategy using AWS Organizations. The security team requires that all API calls to create or modify IAM roles are logged and alerted. Which TWO steps should be taken to meet this requirement?

Trap 1: Use AWS Config to record IAM role changes and stream to CloudWatch…

AWS Config records resource configuration changes, including IAM roles, and can stream them to CloudWatch Logs, but the requirement is logging and alerting on API calls, which CloudTrail captures. Config is tempting because it tracks IAM role state over time, the right choice for compliance auditing of configuration drift.

Trap 2: Create an SCP that denies IAM role creation and modification.

An SCP denying IAM role creation and modification blocks the API calls entirely, so nothing is logged or alerted — it prevents rather than detects. SCPs are tempting because they enforce guardrails across every account in the organisation, which is the right use when the goal is prevention, not monitoring.

Trap 3: Enable IAM Access Analyzer to monitor IAM role usage.

IAM Access Analyzer identifies resources shared with external entities and unused permissions; it does not record or alert on IAM role creation and modification API calls. It is tempting because it analyses IAM policy risk, which suits reviewing existing permissions rather than detecting configuration-change events.

A
Use AWS Config to record IAM role changes and stream to CloudWatch Logs.
Why it fails: AWS Config records resource configuration changes, including IAM roles, and can stream them to CloudWatch Logs, but the requirement is logging and alerting on API calls, which CloudTrail captures. Config is tempting because it tracks IAM role state over time, the right choice for compliance auditing of configuration drift.
B
Create a CloudWatch Logs metric filter and alarm to detect IAM role creation/modification events.
CloudTrail delivers IAM role creation and modification events to CloudWatch Logs, where a metric filter matches the specific API calls (CreateRole, UpdateAssumeRolePolicy, AttachRolePolicy). The alarm then alerts the security team, satisfying the requirement to both log and alert on these events across the organisation's accounts.
C
Create an SCP that denies IAM role creation and modification.
Why it fails: An SCP denying IAM role creation and modification blocks the API calls entirely, so nothing is logged or alerted — it prevents rather than detects. SCPs are tempting because they enforce guardrails across every account in the organisation, which is the right use when the goal is prevention, not monitoring.
D
Enable CloudTrail management events with CloudWatch Logs integration in all accounts.
CloudTrail management events capture IAM role creation and modification API calls, satisfying the logging requirement across every account. Streaming them to CloudWatch Logs enables metric filters and alarms, delivering the alerting half of the requirement. Without this integration, events remain in CloudTrail only, so no automated alert fires.
E
Enable IAM Access Analyzer to monitor IAM role usage.
Why it fails: IAM Access Analyzer identifies resources shared with external entities and unused permissions; it does not record or alert on IAM role creation and modification API calls. It is tempting because it analyses IAM policy risk, which suits reviewing existing permissions rather than detecting configuration-change events.

Question 9easymultiple choice

A company wants to ensure that no IAM user in any account can create access keys. The company uses AWS Organizations. Which approach should be used?

Trap 1: Enable AWS CloudTrail and set up a metric filter for CreateAccessKey

CloudTrail with a metric filter only detects and alerts after CreateAccessKey has already succeeded, leaving the keys usable. CloudTrail is an audit and monitoring service; prevention requires an Organizations-level SCP that denies iam:CreateAccessKey, which would be the answer if the question asked for detection instead.

Trap 2: Apply an IAM policy to all users in each account that denies…

Per-user IAM policies must be attached in every account and to every new user, so coverage is never guaranteed. An Organizations SCP applied at the root enforces the deny across all accounts centrally. IAM identity policies are the right tool for granting or denying permissions to specific users within a single account.

Trap 3: Use AWS Config to detect access key creation and trigger a Lambda…

AWS Config remediation is detective and reactive: the access key is created first, then deleted, so the deny requirement is never actually enforced. An Organizations SCP prevents the iam:CreateAccessKey call outright. Config rules suit compliance monitoring and auto-remediation of drift, not preventive access control.

A
Enable AWS CloudTrail and set up a metric filter for CreateAccessKey
Why it fails: CloudTrail with a metric filter only detects and alerts after CreateAccessKey has already succeeded, leaving the keys usable. CloudTrail is an audit and monitoring service; prevention requires an Organizations-level SCP that denies iam:CreateAccessKey, which would be the answer if the question asked for detection instead.
B
Apply an IAM policy to all users in each account that denies iam:CreateAccessKey
Why it fails: Per-user IAM policies must be attached in every account and to every new user, so coverage is never guaranteed. An Organizations SCP applied at the root enforces the deny across all accounts centrally. IAM identity policies are the right tool for granting or denying permissions to specific users within a single account.
C
Attach an SCP to the root OU that denies iam:CreateAccessKey
An SCP attached to the root OU applies to every member account in the organisation, denying `iam:CreateAccessKey` regardless of identity-based policies. This satisfies the requirement that no IAM user in any account can create access keys, since SCPs set the maximum permissions boundary across all accounts beneath the root.
D
Use AWS Config to detect access key creation and trigger a Lambda to delete the key
Why it fails: AWS Config remediation is detective and reactive: the access key is created first, then deleted, so the deny requirement is never actually enforced. An Organizations SCP prevents the iam:CreateAccessKey call outright. Config rules suit compliance monitoring and auto-remediation of drift, not preventive access control.

Question 10mediummulti select

A company is designing a multi-account AWS Organizations architecture. Which TWO considerations should be taken into account when designing the organizational structure?

Trap 1: Accounts cannot be moved between OUs once created.

Accounts can be moved between OUs.

Trap 2: Each organizational unit (OU) should contain only one account for…

OUs can contain multiple accounts; isolation is achieved via SCPs.

Trap 3: SCPs can only be applied to root accounts, not OUs.

SCPs can be applied to OUs and individual accounts.

A
Accounts cannot be moved between OUs once created.
Why it fails: Accounts can be moved between OUs.
B
Each organizational unit (OU) should contain only one account for security isolation.
Why it fails: OUs can contain multiple accounts; isolation is achieved via SCPs.
C
AWS CloudTrail can be configured to log management events across all accounts from the management account.
CloudTrail organisation trails let the management account aggregate management events from every member account into one destination bucket, satisfying the centralised auditing constraint of a multi-account structure. This removes per-account trail configuration and preserves a single immutable log archive, which is essential when accounts are created and removed dynamically.
D
Service control policies (SCPs) can be used to centrally restrict permissions across accounts.
SCPs attach to organizational units or accounts and define the maximum available permissions, so a single policy edit centrally caps what any principal in member accounts can do. This directly satisfies the multi-account governance constraint, restricting permissions across accounts without per-account IAM rework.
E
SCPs can only be applied to root accounts, not OUs.
Why it fails: SCPs can be applied to OUs and individual accounts.

Question 11mediummultiple choice

An IAM policy condition allows launching EC2 instances only if the instance type is t2.micro or t2.small. A developer tries to launch a t2.medium instance. What happens?

Exhibit

Refer to the exhibit.

Resource: "arn:aws:ec2:us-east-1:123456789012:instance/*"
Condition:
  StringEquals:
    ec2:InstanceType:
      - "t2.micro"
      - "t2.small"

Trap 1: The launch is denied only if the user does not have a separate…

IAM evaluates all applicable policies together; an explicit Allow for t2.medium in another policy overrides the condition-scoped Allow, so the launch succeeds, not fails. It is tempting because explicit denies do override allows, but a condition restricting one Allow statement is not an explicit Deny, so this misreads the evaluation logic.

Trap 2: The launch succeeds because the condition only allows, not denies.

The condition scopes the Allow to t2.micro and t2.small, so a t2.medium request matches no Allow statement and is implicitly denied by default. It is tempting because conditions do filter Allow statements rather than acting as Denies, yet the absence of any matching Allow still yields an implicit deny.

Trap 3: The launch succeeds if the user has an additional Allow for…

An additional Allow for t2.medium would indeed permit the launch, but the scenario states only the condition-scoped policy exists, so no such Allow is present and the request is implicitly denied. It is tempting because multiple Allow statements do combine, which would be correct had the stem included that second policy.

A
The launch is denied only if the user does not have a separate policy allowing t2.medium.
Why it fails: IAM evaluates all applicable policies together; an explicit Allow for t2.medium in another policy overrides the condition-scoped Allow, so the launch succeeds, not fails. It is tempting because explicit denies do override allows, but a condition restricting one Allow statement is not an explicit Deny, so this misreads the evaluation logic.
B
The launch succeeds because the condition only allows, not denies.
Why it fails: The condition scopes the Allow to t2.micro and t2.small, so a t2.medium request matches no Allow statement and is implicitly denied by default. It is tempting because conditions do filter Allow statements rather than acting as Denies, yet the absence of any matching Allow still yields an implicit deny.
C
The launch succeeds if the user has an additional Allow for t2.medium.
Why it fails: An additional Allow for t2.medium would indeed permit the launch, but the scenario states only the condition-scoped policy exists, so no such Allow is present and the request is implicitly denied. It is tempting because multiple Allow statements do combine, which would be correct had the stem included that second policy.
D
The launch is denied because t2.medium is not in the allowed list.
The condition key `ec2:InstanceType` evaluates the requested type against the allowed values, and t2.medium matches neither t2.micro nor t2.small. Because IAM denies any request failing a condition in an Allow statement, the RunInstances call is rejected outright. The developer receives an unauthorised operation error, satisfying the stem's allow-list constraint.

Question 12mediummulti select

A company is designing a new serverless application using AWS Lambda. The application needs to access an Amazon RDS for PostgreSQL database. The database credentials must be rotated automatically every 30 days. Which THREE steps should the company take to securely manage the credentials? (Choose three.)

Trap 1: Grant the Lambda function's IAM role permission to access the RDS…

Granting the Lambda role direct RDS access bypasses Secrets Manager, so credentials would be embedded or fetched manually and never rotated every 30 days. It is tempting because IAM database authentication removes passwords entirely, which would be correct for RDS engines that support it and where rotation is not mandated.

Trap 2: Write custom rotation logic in the Lambda function to change the…

Custom rotation logic inside the application Lambda duplicates what Secrets Manager's rotation Lambda already provides, and it cannot update the stored secret atomically. It is tempting because a Lambda can run SQL against PostgreSQL, which would be correct for bespoke credential stores outside Secrets Manager.

A
Store the database credentials in AWS Secrets Manager.
Secrets Manager is purpose-built for storing and retrieving database credentials securely, satisfying the 30-day rotation requirement natively. Unlike Lambda environment variables or Parameter Store, it integrates rotation scheduling and encryption, so credentials never reside in code or configuration files.
B
Configure automatic rotation for the secret in AWS Secrets Manager.
Configuring automatic rotation directly satisfies the mandatory 30-day rotation constraint. Secrets Manager invokes a Lambda rotation function that updates both the secret and the RDS PostgreSQL user password, eliminating manual intervention and ensuring credentials expire on schedule.
C
Grant the Lambda function's IAM role permission to access the RDS database directly.
Why it fails: Granting the Lambda role direct RDS access bypasses Secrets Manager, so credentials would be embedded or fetched manually and never rotated every 30 days. It is tempting because IAM database authentication removes passwords entirely, which would be correct for RDS engines that support it and where rotation is not mandated.
D
Write custom rotation logic in the Lambda function to change the database password.
Why it fails: Custom rotation logic inside the application Lambda duplicates what Secrets Manager's rotation Lambda already provides, and it cannot update the stored secret atomically. It is tempting because a Lambda can run SQL against PostgreSQL, which would be correct for bespoke credential stores outside Secrets Manager.
E
Grant the Lambda function's IAM role permission to retrieve the secret from Secrets Manager.
The Lambda execution role must hold secretsmanager:GetSecretValue permission, otherwise retrieval calls fail with AccessDenied. This grants least-privilege read access to the specific secret, enabling runtime credential fetching without embedding static credentials in code or environment variables.

Question 13mediummultiple choice

A company has a multi-account AWS environment and wants to centralize the management of IAM roles. The security team needs to ensure that all IAM roles across all accounts trust the same identity provider (IdP) for federated access. The company uses AWS IAM Identity Center (successor to AWS SSO) for user management. Which solution should be implemented?

Trap 1: Use an SCP to require that all IAM roles trust the corporate IdP.

An SCP is a permissions guardrail that filters which actions principals may perform; it cannot write or enforce a trust policy on an IAM role. It is tempting because SCPs govern all accounts from the organisation root, but they restrict permissions rather than configure role trust.

Trap 2: Create IAM roles in each account with a trust policy that allows…

Per-account roles trusting the corporate IdP directly fragment role management and ignore IAM Identity Center, which already brokers federation. It is tempting because direct IdP trust is the classic pattern for a single account without a centralised identity service.

Trap 3: Use AWS CloudFormation StackSets to deploy IAM roles with the IdP…

StackSets replicates a static trust policy into each account, so every role trusts the IdP directly rather than IAM Identity Center, bypassing centralised permission management. It is tempting because StackSets is the standard mechanism for deploying identical resources across many accounts.

A
Use AWS IAM Identity Center to create permission sets that grant access to accounts. IAM Identity Center automatically creates and manages the necessary IAM roles with the IdP trust.
IAM Identity Center permission sets are provisioned into each account as IAM roles whose trust policy references the Identity Center instance, so every account trusts the same IdP automatically. This centralises role management and satisfies the requirement for uniform federated trust across all accounts.
B
Use an SCP to require that all IAM roles trust the corporate IdP.
Why it fails: An SCP is a permissions guardrail that filters which actions principals may perform; it cannot write or enforce a trust policy on an IAM role. It is tempting because SCPs govern all accounts from the organisation root, but they restrict permissions rather than configure role trust.
C
Create IAM roles in each account with a trust policy that allows the corporate IdP.
Why it fails: Per-account roles trusting the corporate IdP directly fragment role management and ignore IAM Identity Center, which already brokers federation. It is tempting because direct IdP trust is the classic pattern for a single account without a centralised identity service.
D
Use AWS CloudFormation StackSets to deploy IAM roles with the IdP trust policy to all accounts.
Why it fails: StackSets replicates a static trust policy into each account, so every role trusts the IdP directly rather than IAM Identity Center, bypassing centralised permission management. It is tempting because StackSets is the standard mechanism for deploying identical resources across many accounts.

Question 14easymultiple choice

A company wants to allow developers to assume a role in a production account from their development account using AWS IAM. What is needed for this cross-account access?

Trap 1: A role in the dev account with permissions to access production…

The role must exist in the production account, since that account owns the resources and grants the trust; a dev-account role grants nothing there. It is tempting because the developers reside in the dev account, and it would be correct if production resources were instead accessed by a role within that same account.

Trap 2: An IAM user in the production account with permissions to switch…

Creating an IAM user in the production account grants long-term credentials, which contradicts cross-account role assumption, where the developer's existing development-account identity calls sts:AssumeRole. The production account instead needs a role whose trust policy names the development account. IAM users suit standalone identities requiring permanent credentials, not federated cross-account access.

Trap 3: An SCP that allows sts:AssumeRole from the dev account.

An SCP filters permissions already granted within an account and cannot create cross-account trust; the production role's trust policy must name the dev account. It is tempting because SCPs govern organisation-wide access boundaries, and it would be correct when restricting which services member accounts may use.

A
A role in the dev account with permissions to access production resources.
Why it fails: The role must exist in the production account, since that account owns the resources and grants the trust; a dev-account role grants nothing there. It is tempting because the developers reside in the dev account, and it would be correct if production resources were instead accessed by a role within that same account.
B
An IAM user in the production account with permissions to switch roles.
Why it fails: Creating an IAM user in the production account grants long-term credentials, which contradicts cross-account role assumption, where the developer's existing development-account identity calls sts:AssumeRole. The production account instead needs a role whose trust policy names the development account. IAM users suit standalone identities requiring permanent credentials, not federated cross-account access.
C
A role in the production account with a trust policy allowing the dev account, and an IAM policy in the dev account allowing sts:AssumeRole.
Cross-account role assumption needs two grants: the production role's trust policy must name the development account as principal, and the development identity needs an IAM policy permitting sts:AssumeRole on that role's ARN. Both halves are required for the call to succeed.
D
An SCP that allows sts:AssumeRole from the dev account.
Why it fails: An SCP filters permissions already granted within an account and cannot create cross-account trust; the production role's trust policy must name the dev account. It is tempting because SCPs govern organisation-wide access boundaries, and it would be correct when restricting which services member accounts may use.

Question 15easymultiple choice

A company uses AWS Organizations with a single OU for all accounts. The security team wants to prevent any account from leaving the organization without approval. What should they do?

Trap 1: Configure IAM policies on the root user of each account to deny…

IAM policies cannot restrict AWS Organizations actions such as LeaveOrganization; only service control policies applied at the root or OU can. It is tempting because IAM policies do govern most AWS API permissions, and would be correct for controlling ordinary resource access.

Trap 2: Create an AWS Config rule to detect leave attempts.

An AWS Config rule only evaluates and reports configuration compliance after the fact; it cannot block an account from leaving, and no AWS Config managed rule detects Organizations leave events. It is tempting because Config is the standard service for continuous compliance auditing, and would be correct for flagging non-compliant resource configurations.

Trap 3: Enable AWS CloudTrail to monitor leave events and send alerts.

CloudTrail records the LeaveOrganization API call only after the account has already departed, so it provides detection rather than prevention. It is tempting because CloudTrail is the default mechanism for auditing Organizations activity, and would be correct when the requirement is retrospective alerting on membership changes rather than blocking them.

A
Configure IAM policies on the root user of each account to deny leave actions.
Why it fails: IAM policies cannot restrict AWS Organizations actions such as LeaveOrganization; only service control policies applied at the root or OU can. It is tempting because IAM policies do govern most AWS API permissions, and would be correct for controlling ordinary resource access.
B
Create an AWS Config rule to detect leave attempts.
Why it fails: An AWS Config rule only evaluates and reports configuration compliance after the fact; it cannot block an account from leaving, and no AWS Config managed rule detects Organizations leave events. It is tempting because Config is the standard service for continuous compliance auditing, and would be correct for flagging non-compliant resource configurations.
C
Enable AWS CloudTrail to monitor leave events and send alerts.
Why it fails: CloudTrail records the LeaveOrganization API call only after the account has already departed, so it provides detection rather than prevention. It is tempting because CloudTrail is the default mechanism for auditing Organizations activity, and would be correct when the requirement is retrospective alerting on membership changes rather than blocking them.
D
Apply an SCP that denies the organizations:LeaveOrganization action.
Service control policies set the maximum available permissions for member accounts, and applying one that denies organizations:LeaveOrganization blocks the API call from every principal in the OU, including the account's own root user, satisfying the requirement that no account can depart without approval.

Question 16easymultiple choice

Refer to the exhibit. A company is using AWS Migration Hub to track migrations. The above IAM policy is attached to an IAM role used by the migration tool. The migration tool reports that it cannot register the migration task with Migration Hub. Which action should the company add to the policy to fix the issue?

Exhibit

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowMigrationHubAccess",
      "Effect": "Allow",
      "Action": [
        "mgh:CreateProgressUpdateStream",
        "mgh:PutResourceAttributes",
        "mgh:AssociateCreatedArtifact",
        "mgh:DisassociateCreatedArtifact",
        "mgh:NotifyMigrationTaskState",
        "mgh:DescribeMigrationTask",
        "mgh:ListMigrationTasks",
        "mgh:ListProgressUpdateStreams"
      ],
      "Resource": "*"
    }
  ]
}

Trap 1: mgh:AssociateDiscoveredResource

mgh:AssociateDiscoveredResource is for associating resource data, not registering tasks.

Trap 2: mgh:CreateHomeRegion

mgh:CreateHomeRegion is not needed.

Trap 3: mgh:GetHomeRegion

mgh:GetHomeRegion is read-only.

A
mgh:ImportMigrationTask
Registering a migration task with Migration Hub requires the mgh:ImportMigrationTask permission, which the existing policy omits. Adding this action to the IAM role lets the migration tool create the task record, resolving the reported registration failure.
B
mgh:AssociateDiscoveredResource
Why it fails: mgh:AssociateDiscoveredResource is for associating resource data, not registering tasks.
C
mgh:CreateHomeRegion
Why it fails: mgh:CreateHomeRegion is not needed.
D
mgh:GetHomeRegion
Why it fails: mgh:GetHomeRegion is read-only.

Question 17easymultiple choice

A company has a production AWS account and a development AWS account. The development team needs to assume an IAM role in the production account to deploy resources. What is the correct way to set up this cross-account access?

Trap 1: Apply a service control policy to allow cross-account access

Service control policies only set permission guardrails on accounts within an AWS Organization; they grant nothing themselves, so the development principal still lacks sts:AssumeRole rights. They are tempting because they do constrain cross-account boundaries, and would be correct to deny risky actions organisation-wide.

Trap 2: Create an IAM user in the production account and share the…

Long-lived IAM user credentials in the production account violate least privilege and cannot be audited per developer; the role's trust policy is what authorises the development account. IAM users suit workloads with no identity federation, not delegated human cross-account deployment.

Trap 3: Configure security group rules to allow access from the development…

Security groups filter network traffic to EC2 instances; they grant no IAM permissions and cannot enable sts:AssumeRole. They are tempting because they govern cross-account network reachability, which is the correct tool when instances in one account must reach endpoints in another.

A
Create an IAM role in the production account with a trust policy that specifies the development account as a trusted entity
A trust policy in the production account naming the development account as principal establishes the cross-account relationship, satisfying the requirement that the development team assume a role in production. The development team then attaches a policy allowing sts:AssumeRole for that role's ARN, completing the two-sided configuration.
B
Apply a service control policy to allow cross-account access
Why it fails: Service control policies only set permission guardrails on accounts within an AWS Organization; they grant nothing themselves, so the development principal still lacks sts:AssumeRole rights. They are tempting because they do constrain cross-account boundaries, and would be correct to deny risky actions organisation-wide.
C
Create an IAM user in the production account and share the credentials with the development team
Why it fails: Long-lived IAM user credentials in the production account violate least privilege and cannot be audited per developer; the role's trust policy is what authorises the development account. IAM users suit workloads with no identity federation, not delegated human cross-account deployment.
D
Configure security group rules to allow access from the development account
Why it fails: Security groups filter network traffic to EC2 instances; they grant no IAM permissions and cannot enable sts:AssumeRole. They are tempting because they govern cross-account network reachability, which is the correct tool when instances in one account must reach endpoints in another.

Question 18mediummultiple choice

A company has a production AWS account and a development AWS account under AWS Organizations. The development team wants to deploy a CloudFormation stack that creates an S3 bucket with a bucket policy that grants access to the production account's IAM roles. The development account has an SCP that denies all s3:PutBucketPolicy actions. The development team has full administrator access in their account. When they try to create the stack, it fails. What is the most likely reason and how should they proceed?

Trap 1: The development team does not have IAM permissions to create…

Administrator access already grants s3:PutBucketPolicy, so the IAM policy is not the blocker; the SCP denies that action regardless of identity permissions. It is tempting because an explicit deny looks like a missing allow, but SCPs cap what any principal in the account can do, so the stack cannot succeed until the SCP is amended.

Trap 2: CloudFormation service role is missing

A service role cannot bypass an SCP: SCPs cap the maximum permissions for every principal in the account, including CloudFormation's assumed role, so s3:PutBucketPolicy stays denied. Service roles exist to grant CloudFormation permissions beyond the deploying user's own, which is irrelevant when the caller already has administrator access.

Trap 3: The production account's IAM roles are not trusted

The stack fails at bucket-policy creation, before any cross-account assumption occurs, so the production roles' trust policy is never evaluated. Trust policies govern which principals may assume a role; they matter once the bucket policy exists and production roles attempt access, not during the denied PutBucketPolicy call.

A
The development team does not have IAM permissions to create buckets. They need to attach an IAM policy that allows s3:PutBucketPolicy.
Why it fails: Administrator access already grants s3:PutBucketPolicy, so the IAM policy is not the blocker; the SCP denies that action regardless of identity permissions. It is tempting because an explicit deny looks like a missing allow, but SCPs cap what any principal in the account can do, so the stack cannot succeed until the SCP is amended.
B
The SCP denies s3:PutBucketPolicy and overrides the administrator permissions. They need to request an exception to the SCP from the security team.
SCPs set the maximum available permissions for accounts in an organisation, so they override even administrator access. The deny on s3:PutBucketPolicy blocks the stack's bucket policy creation; only the security team can grant an SCP exception.
C
CloudFormation service role is missing. They need to create a service role with appropriate permissions.
Why it fails: A service role cannot bypass an SCP: SCPs cap the maximum permissions for every principal in the account, including CloudFormation's assumed role, so s3:PutBucketPolicy stays denied. Service roles exist to grant CloudFormation permissions beyond the deploying user's own, which is irrelevant when the caller already has administrator access.
D
The production account's IAM roles are not trusted. They need to update the trust policy.
Why it fails: The stack fails at bucket-policy creation, before any cross-account assumption occurs, so the production roles' trust policy is never evaluated. Trust policies govern which principals may assume a role; they matter once the bucket policy exists and production roles attempt access, not during the denied PutBucketPolicy call.

Question 19easymultiple choice

A company wants to provide its developers with access to a shared development environment in AWS. The developers are in different AWS accounts, and they need to assume an IAM role in the development account. What is the secure way to allow cross-account access?

Trap 1: Use a service control policy to allow access from other accounts

Service control policies only set the maximum permissions for principals already in an organisation's accounts; they cannot grant or establish cross-account role assumption. It is tempting because SCPs govern account permissions, but that scenario is restricting existing access within AWS Organizations, not enabling trust between separate accounts.

Trap 2: Create IAM users in the development account for each developer

Creating IAM users in the development account duplicates identities and issues separate long-term credentials, so developers never assume a role and access cannot be centrally governed. It is tempting because it grants account access directly, but that approach fits a small standalone account without an existing identity source.

Trap 3: Share the access keys of an IAM user in the development account

Sharing long-term IAM user access keys gives every developer standing credentials in the development account, with no per-user identity or revocation path, and contradicts assuming a role. It is tempting as a quick way to grant access, but it suits a single machine-to-machine integration, not cross-account human access.

A
Use a service control policy to allow access from other accounts
Why it fails: Service control policies only set the maximum permissions for principals already in an organisation's accounts; they cannot grant or establish cross-account role assumption. It is tempting because SCPs govern account permissions, but that scenario is restricting existing access within AWS Organizations, not enabling trust between separate accounts.
B
Create IAM users in the development account for each developer
Why it fails: Creating IAM users in the development account duplicates identities and issues separate long-term credentials, so developers never assume a role and access cannot be centrally governed. It is tempting because it grants account access directly, but that approach fits a small standalone account without an existing identity source.
C
Share the access keys of an IAM user in the development account
Why it fails: Sharing long-term IAM user access keys gives every developer standing credentials in the development account, with no per-user identity or revocation path, and contradicts assuming a role. It is tempting as a quick way to grant access, but it suits a single machine-to-machine integration, not cross-account human access.
D
Create an IAM role in the development account with a trust policy that allows the developers' accounts to assume it
A trust policy on the development account's role names each developer account as principal, so cross-account sts:AssumeRole succeeds without sharing long-term credentials. This satisfies the requirement that developers in separate AWS accounts assume a role in the development account, and it works alongside Microsoft Entra ID federation rather than replacing it.

Question 20hardmultiple choice

A company attaches the IAM policy shown in the exhibit to an IAM user. The user tries to upload an object to my-bucket using the AWS CLI without the --ssl flag (i.e., using HTTP). What will happen?

Exhibit

Refer to the exhibit.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "true"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

Trap 1: The upload fails with an implicit denial because the Allow…

The policy's Allow statement carries an aws:SecureTransport condition, so an HTTP request does not satisfy it; with no matching Allow, the request is implicitly denied. The option is tempting because conditions do gate Allow statements, but the failure is an implicit, not explicit, denial.

Trap 2: The upload succeeds because the Allow statement grants s3:PutObject.

The Allow statement grants s3:PutObject only when aws:SecureTransport is true; an HTTP upload fails that condition, so no Allow applies and the request is denied. It is tempting because the action and resource match, but the condition key must also evaluate true.

Trap 3: The upload succeeds because there is no explicit Deny for…

IAM is deny-by-default: absent any matching Allow, the request is implicitly denied regardless of explicit Deny statements. The option is tempting because explicit Denies are absolute, but the aws:SecureTransport condition on the Allow already prevents it from applying to HTTP.

A
The upload fails with an implicit denial because the Allow condition is not met.
Why it fails: The policy's Allow statement carries an aws:SecureTransport condition, so an HTTP request does not satisfy it; with no matching Allow, the request is implicitly denied. The option is tempting because conditions do gate Allow statements, but the failure is an implicit, not explicit, denial.
B
The upload succeeds because the Allow statement grants s3:PutObject.
Why it fails: The Allow statement grants s3:PutObject only when aws:SecureTransport is true; an HTTP upload fails that condition, so no Allow applies and the request is denied. It is tempting because the action and resource match, but the condition key must also evaluate true.
C
The upload fails with an explicit deny because of the Deny statement.
The policy's Deny statement matches requests where aws:SecureTransport is false, which HTTP satisfies. Because an explicit deny always overrides any Allow, the CLI upload is rejected outright rather than merely unauthenticated, so the user receives an access-denied error.
D
The upload succeeds because there is no explicit Deny for s3:PutObject.
Why it fails: IAM is deny-by-default: absent any matching Allow, the request is implicitly denied regardless of explicit Deny statements. The option is tempting because explicit Denies are absolute, but the aws:SecureTransport condition on the Allow already prevents it from applying to HTTP.