Question 60
CloudTrail is configured to deliver logs into an S3 bucket encrypted with a customer managed KMS key. The bucket policy grants the CloudTrail service access, but creating or updating the trail fails a KMS authorization check. Which missing authorization should be evaluated?
- Grant the CloudTrail logging bucket public Write permission and assume the KMS key policy is irrelevant to server-side encryption.
- Allow CloudTrail to use the S3 bucket without any key policy changes because bucket PutObject permission always implies KMS data-key generation.
- Increase IAM user password length for the administrator who configured the trail, because CloudTrail uses that password to encrypt every object.
- Permit the CloudTrail service principal the required KMS GenerateDataKey permissions (and relevant key-use conditions such as the expected source and encryption context) in the customer managed key policy.
Explanation
Correct Answer
D:CloudTrail SSE-KMS delivery requires the appropriate cloudtrail.amazonaws.com principal permission for generating data keys in the selected KMS key policy, with recommended source and encryption-context conditions as applicable.
Incorrect Answers
A:Public writes are unnecessary and dangerous. A customer-managed KMS key still requires an authorization path for the logging service to create encrypted data keys.
B:S3 bucket authorization and KMS key authorization are separate controls. A valid PutObject grant does not automatically grant CloudTrail required KMS operations.
C:KMS encrypts using cryptographic keys authorized by its key policy, not the console password of the human administrator. Password changes cannot supply a missing service principal grant.
Question 61
An organization has only one AWS account today but expects acquisitions to increase the total to 70. A proposal adds independent IAM users with manually duplicated policies; an alternative integrates corporate SSO with AWS IAM Identity Center. Which tradeoff favors the latter?
- The SSO portal gives every user direct root access and therefore needs no role assignments.
- An SCP alone replaces enterprise authentication and employee offboarding.
- Replicated IAM access keys have less operational overhead because their rotation is always automatic.
- Central group-to-account permission-set management and identity-provider lifecycle reduce account-by-account credential administration as the organization grows.
Explanation
Correct Answer
D:IAM Identity Center centralizes workforce role assignments while retaining account-level scopes, rather than reproducing employees and credentials across acquisitions.
Incorrect Answers
A:A centralized portal still requires explicit account and permission set authorization.
B:SCPs are guardrails, not identity or account-assignment lifecycle services.
C:Persistent per-account keys require additional secure management and do not automatically track IdP offboarding.
Question 62
A temporary external analytics team needs access to a partner-owned S3 dataset for three weeks. The architects compare copying every object to the analyst’s account with role delegation into the data account. Data locality and centralized revocation matter most. Which choice wins?
- Make a perpetual independent public S3 copy to minimize role policy work.
- Issue the data account root credentials to the temporary team, then rotate after three weeks.
- Grant the analysts a separate IAM user in the data-owner account and remove the account when the three-week engagement ends.
- Use a narrowly trusted cross-account role and leave the dataset with its owner, granting time-limited authorized reads.
Explanation
Correct Answer
D:Role assumption permits controlled temporary access without multiplying data copies, retention obligations and access-revocation surfaces.
Incorrect Answers
A:Public replication expands exposure and fails the specified centralized access-revocation requirement.
B:Root delegation is far broader than the required dataset permission and exposes the data owner’s account.
C:Creating identities in the resource owner account can satisfy access but adds separate user lifecycle and credential deprovisioning. A narrowly trusted external role gives central revocation without cloning data or local users.
Question 63
A platform architect distinguishes two requirements: a contractor must enter an audit role in another AWS account, and once in that role may read one S3 prefix. Which policy design keeps those separate?
- Place s3:GetObject in the trust policy and let S3 implicitly accept all assumed sessions.
- Put sts:AssumeRole solely in the contractor identity policy while the target-role trust policy does not authorize the contractor principal.
- Use the role trust policy for which external principal may assume it, and role/bucket permissions for the specific S3 data actions.
- Create only a CloudTrail trail because recording the call automatically grants its permissions.
Explanation
Correct Answer
C:A successful trust decision produces a role session; its subsequent data permissions remain a separate least-privilege decision.
Incorrect Answers
A:Trust policies authorize STS assumption; S3 actions belong to identity/resource permissions.
B:Cross-account role assumption requires a suitable resource-role trust relationship in addition to caller-side permissions. An identity Allow cannot override a missing trust Allow.
D:Audit evidence cannot establish a role trust or authorize S3 data access.
Question 64
A global engineering account needs AdministratorAccess in approved Regions but must never create resources in a restricted jurisdiction. An architect suggests relying on each project’s IAM administrator to remember the rule. What stronger boundary meets the requirement?
- Give every engineer root access because root sessions in member accounts always bypass SCPs.
- Use a CloudWatch dashboard showing Regions without any enforcement.
- Create a permissions boundary containing only approved Regions for a subset of current IAM roles and allow project admins to create new unrestricted roles.
- Apply tested Organizations SCP Region guardrails to the relevant member account or OU while retaining ordinary IAM grants for approved work.
Explanation
Correct Answer
D:An SCP provides an organization-wide maximum that delegated administrators cannot exceed through their account role policies.
Incorrect Answers
A:Root in a member account is subject to SCP guardrails, except documented exemptions unrelated to ordinary root use.
B:Observability may reveal policy violations after the fact, but cannot constrain API authorization by itself.
C:A boundary can constrain its attached role, but an optional per-role boundary is not a reliable organization-wide ceiling when administrators may create roles outside it. OU SCPs govern member-account principals centrally.
Question 65
A regulated OU uses SCP allowlists and must introduce a new AWS analytics service. A developer proposes attaching AdministratorAccess to every analyst; security proposes a reviewed update to the OU maximum plus narrow IAM grants. Which offers a valid authorization path?
- Give analysts AdministratorAccess and leave the service outside the SCP allowlist.
- Grant the new analytics action through an S3 bucket resource policy while the Organizations SCP allowlist still excludes that analytics API.
- Modify the applicable SCP allowlist only for approved service actions and grant the intended users those actions separately through least-privilege IAM.
- Convert every analytics principal into the account root user to avoid allowlist restrictions.
Explanation
Correct Answer
C:SCPs bound the set of possible API permissions, whereas IAM identities need their own explicit grants within that bound.
Incorrect Answers
A:An identity policy cannot exceed an SCP permission ceiling.
B:An S3 bucket policy can authorize supported S3 object operations but cannot overcome the account SCP permission ceiling for a different analytics service action.
D:Root is covered by member-account SCPs and creates unjustified account-wide authority.
Question 66
A small business needs an emergency path for root-only tasks, but 150 finance staff periodically inspect budgets. Which credential boundary is defensible?
- Create a single shared root API key for all finance dashboards.
- Give finance employees the account recovery email password instead of role access.
- Disable all finance reports and leave root as the only usable cost identity.
- Protect the root principal for root-only emergencies and delegate routine cost viewing to individually attributable scoped identities.
Explanation
Correct Answer
D:Operational finance access does not justify distributing root credentials; delegated roles preserve least privilege and auditable identity.
Incorrect Answers
A:Root API keys expose unrestricted persistent account credentials and destroy attribution.
B:Account recovery control is not a substitute for normal authorized billing tasks.
C:The reporting requirement can be met through delegated service permissions.
Question 67
An EC2 Auto Scaling fleet has hundreds of short-lived instances that need the same S3 permissions. An engineer wants static IAM keys in a central secrets file; the platform team favors an instance role. Which property makes the role better for this fleet?
- Create an IAM user for each replacement instance and bake the corresponding static access key into the launch template.
- The EC2 instance profile eliminates the need for S3 resource and KMS authorization checks.
- The instance profile delivers automatically refreshed temporary credentials without replicating long-lived IAM user keys into instances.
- An IAM user key remains valid only while the EC2 instance is running.
Explanation
Correct Answer
C:Ephemeral fleet members can obtain scoped API access through their workload identity rather than sharing a persistent secret that must be deployed and rotated manually.
Incorrect Answers
A:This produces long-lived keys in launch artifacts and repeats provisioning/rotation work as instances churn. Instance profiles are the mechanism for refreshable instance role credentials.
B:The role still needs effective data and key permissions for each requested action.
D:IAM user access keys are not automatically bound to the lifespan of an instance.
Question 68
An enterprise already authenticates employees to IAM Identity Center through its external SAML IdP, but newly joined departments require their users and group memberships to appear in Identity Center without manual re-entry. Which integration addresses this identity-directory synchronization need, independently of AWS account permission-set assignments?
- Create IAM users in every AWS account and expect their group memberships to synchronize back to the IdP automatically.
- Rely on SAML sign-in assertions alone to create and update the Identity Center users and groups without provisioning.
- Only assign permission sets to newly joined departments without first provisioning their users or groups into the Identity Center identity store.
- Configure supported SCIM user/group provisioning from the external IdP into IAM Identity Center, then maintain separate account and permission-set assignments.
Explanation
Correct Answer
D:SCIM synchronizes supported directory identities and memberships with IAM Identity Center; AWS account access still requires distinct permission-set assignments.
Incorrect Answers
A:Per-account IAM identities would recreate the duplication the IdP integration is meant to eliminate; they do not populate the centralized directory.
B:SAML provides sign-in assertions but does not itself provision directory users, groups, or group-membership changes into IAM Identity Center.
C:Permission-set assignments control AWS account access but do not themselves synchronize external directory users and group memberships. SCIM provisioning is the appropriate separate lifecycle integration.
Question 69
A cloud deployment pipeline runs in GitHub Actions. Security needs temporary AWS sessions usable only by one protected workflow branch, without any permanent AWS secret in GitHub. Which integration trades setup complexity for lower credential exposure?
- Encrypt root access keys in repository secrets and use them for all build branches.
- Put a branch name in a role tag only and allow all OIDC identities to assume it.
- Store one IAM user access key in a deployment repository secret and restrict usage with IAM policy tags rather than establishing OIDC token trust.
- Use GitHub OIDC identity federation to an STS role constrained by issuer, audience and repository/branch subject claims.
Explanation
Correct Answer
D:A trust policy can authenticate intended workflow tokens and issue temporary sessions without stored long-lived AWS access keys.
Incorrect Answers
A:Secret encryption at rest does not remove their permanence, privilege breadth or broad execution scope.
B:Descriptive tags alone do not enforce branch identity on an incoming token.
C:Tags can narrow some authorization contexts but do not eliminate long-lived access keys stored in the CI system. A branch-scoped OIDC trust issues short-lived credentials to approved workflows.
Question 70
A third-party compliance scanner has permission to assume a customer role, and the customer role trust policy still lists the correct vendor principal. After the vendor rotates the customer-specific ExternalId in its own configuration, STS AssumeRole starts returning AccessDenied. Why can this happen?
- The customer role ARN must change every time an ExternalId value changes, or STS cannot locate the role.
- Only the caller-side IAM identity policy matters when a role trusts the correct vendor, so trust conditions are never checked.
- The ExternalId sent in the STS request no longer matches the customer role trust-policy condition; the customer and vendor must securely coordinate the expected value.
- Adding sts:ExternalId as an IAM action in the vendor identity policy overrides the old ExternalId condition in the customer role trust policy.
Explanation
Correct Answer
C:STS evaluates the supplied ExternalId against the trust policy. A rotated caller value without the corresponding approved trust-policy update fails even if the principal matches.
Incorrect Answers
A:An IAM role ARN is independent of the STS ExternalId request argument and remains addressable without a rename.
B:AssumeRole permission needs both relevant caller authorization and the receiving role trust policy, including any required conditions.
D:sts:ExternalId is a request context condition key, not an IAM action to add to a permissions policy. The customer role still evaluates its trust policy condition against the ExternalId supplied on the AssumeRole request.
AWS Certified Solutions Architect - Associate SAA-C03 Practice Tests