Task 4.2: Apply authorization mechanisms

• AGrant SELECT in Lake Formation with ssn and salary excluded

  Correct

  Lake Formation grants on a table can be limited to specific columns, so analysts see only the columns they are granted while HR keeps full access.

• BAdd an S3 bucket policy that denies the analysts access to the ssn and salary data

  Incorrect

  Bucket policies work on objects and prefixes. The columns sit inside the same Parquet files as the allowed columns.

• CCreate an Athena view without the two columns and ask analysts to query the view

  Incorrect

  A view is a stored query. If the analysts still have access to the table, they can query the columns directly.

• DEncrypt the ssn and salary data with SSE-KMS and withhold the key from analysts

  Incorrect

  SSE-KMS encrypts whole objects. It cannot hide two columns inside a file that analysts must otherwise read.

Column-level security in a lake is a catalog permission, not a storage setting: Lake Formation filters the columns before Athena returns results.

• AGRANT CREATE ON SCHEMA sales TO ROLE analyst_role

  Incorrect

  CREATE lets users create objects in the schema. It is not what reading existing tables requires, and it gives more than analysts need.

• BALTER DEFAULT PRIVILEGES IN SCHEMA sales GRANT SELECT ON TABLES TO ROLE analyst_role

  Incorrect

  Default privileges apply to objects created in the future. They do not fix access to the schema itself.

• CGRANT USAGE ON SCHEMA sales TO ROLE analyst_role

  Correct

  USAGE on a schema makes its objects accessible; actions on the objects, such as SELECT, are granted separately. Both are needed.

• DALTER USER for each analyst to give them the CREATEUSER option

  Incorrect

  CREATEUSER makes a user a superuser, who bypasses all permission checks. That breaks least privilege.

Redshift checks access in layers: USAGE on the schema, then the privilege on the table. A role needs both to read a table.

• AOne IAM policy per team that lists the ARNs of that team's jobs and secrets

  Incorrect

  Role-based policies that name resources must be updated every time a team adds a resource or a new team starts.

• BA resource-based policy on each secret that names the roles allowed to read it

  Incorrect

  Every new secret and every new role would need policy edits, which the security team wants to avoid.

• COne ABAC policy matching aws:ResourceTag/project to aws:PrincipalTag/project

  Correct

  Attribute-based access control compares tags on the caller and the resource. It needs fewer policies, and new resources are covered when they are tagged.

• DA permissions boundary on every role that allows all Glue and Secrets Manager actions

  Incorrect

  A boundary sets the maximum permissions of a role. It does not tie a team to its own resources.

When access follows an attribute such as project, ABAC scales: tag the principal and the resource, write one policy, and new projects need only tags.

• AA required permissions boundary on each role they create

  Correct

  A permissions boundary sets the maximum permissions that identity policies can grant, so a role can do only what both allow.

• BA session policy that the engineers pass when they assume the new roles

  Incorrect

  Session policies limit only the session that passes them, and the engineers would choose whether to pass one.

• CLake Formation LF-Tags on every database the Glue jobs read

  Incorrect

  LF-Tags govern permissions on Data Catalog resources. They do not cap the IAM permissions of a role.

• DA Lambda resource-based policy on each function that the jobs call

  Incorrect

  Resource-based policies grant access to the function. They do not limit the permissions of the roles that the engineers create.

Delegated role creation is safe when every new role must carry a boundary: whatever policies are attached, the boundary caps the result.

• ARegister the location in Lake Formation mode and revoke IAMAllowedPrincipals

  Incorrect

  Enforcing Lake Formation permissions for everyone would remove the IAM-based access that the existing jobs rely on.

• BKeep the default settings, where only IAM access control is used

  Incorrect

  The default settings control access solely through IAM, so the analysts' Lake Formation grants would not be the access path.

• CCreate a second Data Catalog database that holds copies of the tables

  Incorrect

  Hybrid access mode gives two permission pathways to the same Data Catalog objects, so no copies are needed.

• DRegister the S3 location in hybrid access mode and opt in the analysts

  Correct

  Hybrid access mode keeps two pathways: opted-in principals use Lake Formation permissions, and all other principals keep IAM-based access.

Hybrid access mode is the migration path: opt principals in to Lake Formation one group at a time while everyone else keeps IAM access.

• AGRANT SELECT ON TABLE customers to the analyst role

  Incorrect

  A table-level SELECT grant covers every column, including ssn and birth_date.

• BGRANT SELECT on only the allowed columns of customers

  Correct

  GRANT supports column-level permissions on tables, so SELECT can be granted on a list of columns that leaves out ssn and birth_date.

• CAttach a row-level security policy on customers to the analyst role

  Incorrect

  Row-level security controls which records users can access, not which columns.

• DGRANT USAGE ON SCHEMA for the customers schema

  Incorrect

  USAGE on a schema lets users access objects in it; it does not limit the columns of a table.

Redshift has both column-level grants and row-level security; hiding whole columns from a role is a column-level GRANT.

• AS3 read permissions added to the function's execution role policy

  Incorrect

  The execution role grants the function access to other services. It does not control who can invoke the function.

• BA bucket policy statement that allows lambda:InvokeFunction for the bucket

  Incorrect

  A bucket policy controls access to the bucket. Invoke permission is granted on the function.

• CA permissions boundary on the function's execution role with Lambda access

  Incorrect

  A permissions boundary only caps what identity policies grant. It does not grant S3 the right to invoke the function.

• DA resource-based policy statement that lets S3 invoke the function

  Correct

  A function's resource-based policy grants other accounts, users, and AWS services access to the function, such as permission to invoke it.

Who may call a function lives in its resource-based policy; what the function may call lives in its execution role.

• ASet Object Ownership to bucket owner enforced, which disables ACLs

  Correct

  With ACLs disabled, the bucket owner owns every object in the bucket and controls access with policies.

• BAdd s3:GetObject for the bucket to the analysts' IAM policies again

  Incorrect

  Under Object writer, the uploading account owns the object and controls access to it through ACLs, so more grants in the bucket owner's account do not help.

• CTurn on S3 Versioning on the bucket and ask the partner to upload again

  Incorrect

  Versioning keeps object versions. The partner would still own the new uploads under Object writer.

• DTurn on default encryption with an S3 Bucket Key for the bucket

  Incorrect

  Bucket Keys reduce the cost of SSE-KMS requests. They do not change object ownership.

For shared buckets, bucket owner enforced is the recommended setting: ACLs off, one owner, and access managed entirely with policies.