Security practice questions

External workloads that can present an OIDC token can obtain temporary AWS credentials through web identity federation.

The requirement is no long-term credentials in CI. GitHub Actions can request an OIDC token for each job. With an IAM OIDC identity provider for token.actions.githubusercontent.com and a role that trusts it, the workflow calls AssumeRoleWithWebIdentity (for example through the aws-actions/configure-aws-credentials action) and receives short-lived credentials. Moving or rotating the access key keeps a long-term credential, and GitHub does not issue SAML assertions to workflows.

1. Identify that the requirement is to eliminate long-term keys, not to protect them better.
2. Recall that GitHub Actions can issue an OIDC token to each job.
3. Trust that token with an IAM OIDC identity provider and a role.
4. Use AssumeRoleWithWebIdentity to get temporary credentials.

Exam tip: CI systems that issue OIDC tokens should assume a role with web identity federation instead of storing access keys.

In web identity federation, the trust policy must check the token's subject claim, not just its audience.

With only the aud condition, any GitHub Actions workflow anywhere can obtain a token whose audience is sts.amazonaws.com, so the role is open to every GitHub repository. The sub claim carries repo:<owner>/<repo>:ref:<ref>, issued by GitHub and signed. Adding an exact StringEquals match on sub restricts the role to the main branch of example-org/app. A sub value for pull_request matches the wrong workflows, a wildcard does not work with StringEquals and would be too broad anyway, and the session name is caller-controlled.

1. See that the existing condition only checks the token audience.
2. Identify the claim that names the repository and branch: sub.
3. Use an exact match because only one branch of one repository is allowed.
4. Reject conditions on values the caller controls or that wildcards make too broad.

Exam tip: For OIDC roles, aud says the token is for AWS; sub says who it is. Always pin sub.

API Gateway REST APIs have a built-in authorizer type for Amazon Cognito user pools.

The users already hold Cognito user pool tokens, and the constraint is no authorization code. A COGNITO_USER_POOLS authorizer lets API Gateway check the token against the user pool directly. A Lambda authorizer would also work but is custom code to maintain. IAM authorization expects AWS-signed requests, and API keys are for usage plans rather than authentication.

1. Note where the tokens come from: a Cognito user pool.
2. Note the constraint: no custom authorization code.
3. Pick the built-in authorizer for that token source.
4. Reject API keys, which are not authentication.

Exam tip: Cognito user pool tokens on a REST API: use the Cognito authorizer; reach for a Lambda authorizer only when you need custom logic.

A Lambda authorizer is the API Gateway option for custom token types and authorization decisions that need extra data.

Two requirements decide this: the tokens come from a non-Cognito provider, and authorization depends on data in DynamoDB. Only a Lambda authorizer runs arbitrary code before the integration, returning an IAM policy and principal ID. A JWT authorizer covers the token validation but not the lookup. The Cognito authorizer only trusts Cognito user pools, and IAM authorization needs AWS-signed requests.

1. Identify the token issuer: a third-party OAuth provider.
2. Identify the extra decision: a DynamoDB lookup per partner.
3. Choose the authorizer type that runs custom code.
4. Check that each rejected option fails one of those two needs.

Exam tip: Custom token sources or data-driven authorization on API Gateway mean a Lambda authorizer.

API Gateway caches a Lambda authorizer's policy by the token and applies it to every method the token calls during the TTL.

With a TOKEN authorizer, the cache key is the token. The first call caches a policy that allows only GET /profile, and API Gateway evaluates that cached policy for GET /orders, which it does not cover, so the request is denied until the entry expires. Returning a policy covering all of the caller's permitted resources (for example the API ARN with wildcards for the allowed methods) fixes it while keeping one authorizer call per token per TTL. A TTL of 0 and a per-path cache key both work but increase invocations, which breaks the constraint.

1. Recall that the TOKEN authorizer cache key is the token alone.
2. See that the cached policy names only the first method's ARN.
3. Make the policy valid for every method the user is allowed to call.
4. Compare the workable fixes by authorizer invocations, the stated constraint.

Exam tip: With authorizer caching, return a policy that fits every method the token can reach, not just the methodArn.

Cognito ID tokens prove identity; access tokens carry OAuth scopes for authorizing API calls.

A Cognito authorizer accepts either token type, but once authorization scopes are set on the method, API Gateway requires a token whose scope claim includes one of them. Only the access token has scopes. The fix is to send the access token. Allowing the scope on the app client is needed for it to appear in the access token, but it does not change the ID token. Refresh tokens and identity IDs are not accepted.

1. Note that the method has OAuth scopes configured.
2. Recall which Cognito token carries the scope claim: the access token.
3. Send that token to the method.
4. Reject changes that leave the ID token in place.

Exam tip: Scopes on a Cognito-authorized method mean the client must send the access token.