Data Security and Governance practice questions

Cross-account access in AWS is built on IAM roles and AWS STS: the resource-owning account defines a role and trust policy, and principals in the trusted account assume the role to receive temporary credentials.

An assumable role in account B satisfies every constraint. Account B controls the role's permissions and can revoke trust at any time; account A keeps managing its own people; and every session uses short-lived STS credentials that expire automatically. The alternatives either mint new long-term credentials (new IAM users, shared keys) or rely on ACLs, which are legacy, coarse, and not a credential-issuing mechanism at all.

1. In account B, create a role with permissions for Athena, the Glue Data Catalog, and the underlying S3 data.
2. Set the role's trust policy to allow the specific principals (or the account root with conditions) from account A to call sts:AssumeRole.
3. In account A, grant the analysts permission to assume the role; they then run Athena queries using the temporary credentials from the assumed-role session.

Exam tip: For cross-account access, assume a role with STS - never duplicate users or distribute long-term keys across accounts.

iam:PassRole is the permission that lets a principal hand a role to an AWS service (Glue, Lambda, EC2). It exists to stop users from attaching roles more powerful than their own permissions to services they control.

When you create a Glue job, you specify the service role the job will run as, and IAM checks that you are allowed to pass that role. The correct fix is a narrowly scoped iam:PassRole grant: resource-limited to the GlueETLRole ARN and condition-limited with iam:PassedToService set to glue.amazonaws.com so the role cannot be passed to other services. AssumeRole and trust-policy edits address role assumption, not role passing, and AdministratorAccess is a least-privilege violation.

1. Identify the exact role ARN the job needs to run as.
2. Add a policy statement to the engineer's identity granting iam:PassRole on that ARN only.
3. Add an iam:PassedToService condition limiting the pass target to glue.amazonaws.com, then retry the job creation.

Exam tip: Configuring a service to run as a role requires iam:PassRole on that role - scope it to the role ARN and the destination service.

Secrets Manager supports two rotation strategies: single-user, which changes the one user's password in place, and alternating-users, which flips between two database users so one set of credentials is always stable.

The failures happen because single-user rotation invalidates the old password the instant rotation completes, so any client holding a cached copy fails until it refetches. The alternating-users strategy rotates the password of the currently inactive user and then updates the secret to point at it; the previously active user's credentials continue to work through the transition. Clients with a slightly stale cache still authenticate, and they pick up the new user on their next fetch.

1. Create or designate a second database user cloned from the first with identical privileges.
2. Reconfigure the secret's rotation to the alternating-users strategy referencing both users.
3. Keep clients refreshing the secret periodically (or on authentication failure) so they converge on the newest credentials.

Exam tip: Use alternating-users rotation when clients cache credentials and cannot tolerate a hard password cutover.

Parameter Store is the low-cost home for configuration and modest secrets: standard parameters are free, and SecureString parameters add KMS encryption. Secrets Manager earns its cost only when you need automatic rotation and cross-account secret sharing features.

The requirements are centralized config, selective encryption, no rotation, minimal cost. Parameter Store checks every box: hierarchical parameter names organize configuration, SecureString encrypts the API key with KMS, and IAM policies control who reads what. Secrets Manager is the right tool when rotation is required, which is explicitly not the case here.

1. Create a parameter hierarchy (for example /pipeline/prod/...) with standard String parameters for the non-secret values.
2. Store the API key as a SecureString parameter encrypted with an AWS KMS key.
3. Grant the pipeline roles ssm:GetParameter (with kms:Decrypt for the SecureString) scoped to the parameter path.

Exam tip: No rotation requirement plus cost sensitivity points to Parameter Store; reserve Secrets Manager for credentials that must rotate.

Amazon S3 and DynamoDB support gateway VPC endpoints - free, route-table-based endpoints that keep traffic on the AWS network. Interface endpoints (PrivateLink) support far more services but bill hourly and per GB.

A gateway endpoint is purpose-built for this scenario: it adds a prefix-list route for S3 to the chosen route tables, so instances and Glue ENIs in those subnets reach S3 privately with no internet path and no endpoint charges. The interface endpoint is the classic tempting distractor - functionally fine, but it costs money where the gateway option is free, and exam questions that stress cost expect you to know the difference.

1. Create a gateway VPC endpoint for the com.amazonaws.<region>.s3 service in the VPC.
2. Associate the endpoint with the route tables used by the private subnets that host the Glue connections.
3. Optionally attach an endpoint policy restricting which buckets and actions are reachable through the endpoint.

Exam tip: For S3 and DynamoDB from a VPC, use free gateway endpoints; interface endpoints are for the services that have no gateway option.

Interface VPC endpoints, powered by AWS PrivateLink, create elastic network interfaces inside your subnets that front AWS service APIs, so calls resolve to private IPs and never traverse the internet.

Only two services offer gateway endpoints (S3 and DynamoDB); everything else, including Secrets Manager, STS, KMS, and Glue, is reached privately via interface endpoints. Creating the Secrets Manager interface endpoint with private DNS enabled means the standard SDK endpoint name resolves to the in-VPC ENI, so the Lambda function needs no code changes. NAT paths break the never-leave-AWS-network rule, and peering does not apply to service endpoints.

1. Create an interface VPC endpoint for com.amazonaws.<region>.secretsmanager in the subnets the function uses, with private DNS enabled.
2. Attach a security group to the endpoint that allows inbound HTTPS (443) from the Lambda function's security group.
3. Confirm the function's execution role has secretsmanager:GetSecretValue and, if the secret uses a customer managed key, kms:Decrypt.

Exam tip: Gateway endpoints are only for S3 and DynamoDB; every other AWS service needs an interface endpoint for private connectivity.