Security practice questions

Answer: A) AWSCURRENT marks the version an application should currently retrieve and use; AWSPREVIOUS marks the prior version, kept briefly to support rollback or in-flight processes still using the old credential during rotation

• ADuring rotation, Secrets Manager creates a new secret version and moves the AWSCURRENT label to it once rotation completes successfully, while the previous version (still valid briefly, depending on the rotation strategy) keeps the AWSPREVIOUS label — giving a short grace period rather than an instantaneous hard cutover that could break in-flight operations.
• BThese labels have real functional meaning — applications retrieving "the current secret" specifically fetch the version labeled AWSCURRENT, and Secrets Manager's own rotation logic relies on them.
• CThis reverses their actual meaning — AWSCURRENT is the active, latest version; AWSPREVIOUS is the older one being phased out.
• DThese staging labels are specifically meaningful in the context of rotation — a secret that's never rotated typically only ever has the single AWSCURRENT version with no AWSPREVIOUS to speak of.

Answer: A) The replica is encrypted with a KMS key in eu-west-1: one the developer specifies, or that Region's aws/secretsmanager key if none is given.

Each replica secret is encrypted with a KMS key in the replica's own Region. You can specify a key there, and if you don't, Secrets Manager uses the aws/secretsmanager AWS managed key.

• ACorrect. The encryption key for a replica is optional and must be in the replica Region. If ReplicaRegionType omits KmsKeyId, Secrets Manager uses the AWS managed key aws/secretsmanager.
• BIncorrect. A replica is encrypted with a KMS key in its own Region. The docs say the selected key must be in the replica Region, not the primary Region.
• CIncorrect. Secrets Manager replicates secrets that are encrypted with customer managed keys. You can also choose a customer managed key in the replica Region to encrypt the replica.
• DIncorrect. A multi-Region key isn't required. Any suitable KMS key in the replica Region can be specified, and if none is given, aws/secretsmanager is used.

Answer: A) Configure the API as a Private API type, associated with specific VPC endpoints, and use a resource policy restricting access to those endpoint(s)

• AA Private API is only reachable through an interface VPC endpoint for API Gateway, and a resource policy can further restrict which specific VPC endpoint(s) are allowed to invoke it — together fully removing public internet reachability while scoping access to approved private network paths.
• BA default public REST API is reachable over the internet, the opposite of the private-only requirement described — the Private API type with VPC endpoint association is what's needed.
• CTransfer Acceleration is an S3 feature for speeding up transfers; it has no relationship to restricting an API Gateway API to private VPC-only access.
• DPrivate APIs are an explicitly supported API Gateway endpoint type for exactly this VPC-only access model — this option is factually incorrect.

Answer: A) The request is denied, because the key policy neither names the role nor allows the account principal, so the role's IAM policy has no effect on this key

A KMS key policy is the primary access control for the key. An IAM policy can grant use of the key only if the key policy delegates to IAM by allowing the account principal. Here the key policy neither names the role nor enables IAM, so the decrypt request is denied.

• ACorrect. Unlike most resource policies, a KMS key policy doesn't automatically give permission to the account or its identities. IAM policies can grant access to a key only when the key policy delegates to IAM through a statement that allows the account principal. Without that statement, an IAM Allow is ineffective. The fix is to add the role to the key policy or add the account-principal statement.
• BIncorrect. The same-account union rule doesn't override KMS's own requirement. KMS key policies must explicitly allow access, either directly or by delegating to IAM through the account principal, and this key policy does neither.
• CIncorrect. When S3 decrypts an SSE-KMS object, it calls KMS on behalf of the requester. The requesting principal still needs permission to use the key, and that permission is evaluated against the key policy.
• DIncorrect. Key policies can name IAM roles directly as key users with kms:Decrypt, as the console's default key users statement does. Grants are one option, not the only way to authorize cryptographic operations.

Answer: A) An interface VPC endpoint in the application subnets that connects to the vendor's endpoint service

To consume a provider's PrivateLink endpoint service, create an interface VPC endpoint in your VPC. Gateway endpoints only support S3 and DynamoDB, and neither VPC peering nor NAT is how you use a PrivateLink service.

• ACorrect. With PrivateLink, the service provider creates an endpoint service and grants consumers access. The consumer then creates an interface VPC endpoint, which places endpoint network interfaces in its subnets and connects them privately to the endpoint service.
• BIncorrect. Gateway endpoints are available only for Amazon S3 and DynamoDB, and they don't use AWS PrivateLink. They can't connect to a third-party endpoint service.
• CIncorrect. VPC peering connects two entire VPCs, requires non-overlapping CIDR ranges, and the vendor must accept it. It isn't how consumers reach a PrivateLink endpoint service, which is designed to expose only the service through an interface endpoint.
• DIncorrect. A NAT gateway sends traffic out through an internet gateway to the vendor's public endpoint. It doesn't use the vendor's PrivateLink service, so it doesn't meet the private-connectivity requirement.

Answer: C) Allow kms:Decrypt only when kms:EncryptionContext:tenant equals ${aws:PrincipalTag/tenant}

Combine encryption context condition keys with session tag policy variables for per-tenant KMS authorization on a shared key.

• AIncorrect. This needs a grant per tenant. Because every worker uses the same role, each grant applies to all workers, so it doesn't isolate tenants.
• BIncorrect. The context must match the one used at encryption, but any caller can supply the right tenant's context. It provides integrity, not access control.
• CCorrect. The condition compares the context in each Decrypt request with the session's tenant tag. One policy statement then limits every session to its own tenant's data.
• DIncorrect. kms:ViaService limits which AWS service can make the call on a principal's behalf. It doesn't separate tenants that share one role.

Answer: A) Users type credentials on pages served from the user pool domain, and the app receives an authorization code or tokens

With Cognito managed login (or the classic hosted UI), users enter credentials on Cognito-hosted pages and the app receives only a code or tokens, never the raw password. The app still has to verify tokens and build its own profile management, and Cognito's cookies are scoped to the user pool domain.

• ACorrect. Managed login pages on the user pool domain handle sign-in. After authentication, Cognito redirects to the app's callback URL with an authorization code or tokens, so the app's own code no longer collects or forwards raw passwords.
• BIncorrect. Cookies set by managed login (such as the cognito session cookie and the XSRF-TOKEN cookie) are scoped only to the user pool endpoints, not to the app's domain. They don't protect the application's pages from XSS.
• CIncorrect. User pool tokens are signed with RS256, and the application or API still needs to decode and verify them. Using managed login doesn't remove the need for token validation.
• DIncorrect. Managed login supports completing sign-in with MFA, but it doesn't support self-service profile management such as attribute changes or setting MFA preferences. The app still has to implement those features.

Answer: A) Enhanced calls GetId, then GetCredentialsForIdentity, and the identity pool picks the IAM role. Basic calls GetId, GetOpenIdToken and STS AssumeRoleWithWebIdentity, and the app picks the role.

Both flows start with GetId. The enhanced flow then calls GetCredentialsForIdentity and lets the identity pool choose the role. The basic flow adds GetOpenIdToken and STS AssumeRoleWithWebIdentity, and the client has to choose the role. AWS recommends not turning on the basic flow for new identity pools.

• ACorrect. Both flows start with GetId. In the enhanced flow, GetCredentialsForIdentity returns AWS credentials and the identity pool configuration (default role, RBAC or ABAC) chooses the role. In the basic flow, the app exchanges a Cognito OpenID token with AWS STS and has to contain its own role-selection logic.
• BIncorrect. The enhanced flow also calls GetId first. It then passes the returned identity ID and the same proof of authentication to GetCredentialsForIdentity.
• CIncorrect. This reverses the two flows. The basic flow isn't supported in identity pools that have role mappings, and it is the basic flow that calls AssumeRoleWithWebIdentity. The enhanced flow lets the identity pool choose the role.
• DIncorrect. Neither flow is tied to a particular provider type or to guest access. Both start with GetId, which supports unauthenticated identities and tokens from user pools, OIDC, SAML and social providers.

Answer: A) An endpoint policy on the interface endpoint that allows S3 actions only on the bucket's ARN and its objects

Use a VPC endpoint policy to restrict which S3 resources can be reached through an endpoint, for example by allowing only a single bucket's ARN. Security groups, network ACLs and DNS settings work at the network layer and can't filter requests by bucket.

• ACorrect. An endpoint policy is a resource-based policy attached to the VPC endpoint. It controls which principals, actions and resources can be used through that endpoint. AWS documents an example S3 endpoint policy that limits access to a single bucket's ARN. The endpoint policy works together with IAM and bucket policies rather than replacing them.
• BIncorrect. Security groups filter traffic by protocol, port and IP address or source. They can't tell which bucket an S3 request is for, so they can't limit the endpoint to one bucket.
• CIncorrect. Network ACLs are stateless filters based on IP address and port at the subnet level. Every bucket is reached through the same endpoint network interfaces, so a NACL can't tell one bucket from another.
• DIncorrect. Private DNS makes the Regional S3 DNS names resolve to the endpoint's private IP addresses so clients don't need endpoint-specific names. It controls how traffic is routed, not which buckets can be accessed, and it can't be limited to one bucket.

Answer: A) AWS Private Certificate Authority (AWS Private CA), used to create a managed private root and subordinate CA hierarchy

AWS Private CA (formerly ACM Private CA) provides a managed private CA hierarchy. It issues certificates that are trusted only internally, such as for mTLS, without on-premises CA infrastructure.

• ACorrect. AWS Private CA lets you create private CA hierarchies (root and subordinate CAs) without the cost of running an on-premises CA. Its certificates are trusted only where you distribute the private root, and it supports use cases such as TLS channels and authenticating API endpoints.
• BIncorrect. Public ACM certificates chain to a publicly trusted CA and require domain validation. They do not meet the requirement for certificates that are trusted only internally.
• CIncorrect. KMS can store signing keys, but the team would have to build and operate the CA logic themselves, including issuance, revocation, and the hierarchy. The requirements rule that out.
• DIncorrect. IAM can only store certificates that were obtained elsewhere. It does not issue certificates or act as a certificate authority.