IAM Conditions are one of those features that look small in the console but show up regularly on the Professional Cloud Architect exam. They let you attach constraints to IAM policy bindings so a role only grants access when the request matches the rules you set. I want to walk through what conditions actually do, the two categories you can choose from, and the canonical example I keep in mind when answering exam questions.
A normal IAM binding ties three things together: a principal, a role, and a resource. An IAM Condition adds a fourth element to that binding. The condition is evaluated at request time, and the binding only takes effect when the condition is true. If the condition evaluates to false, the principal does not get the role on that resource for that request.
The categories you see when you add a condition in the console are the same ones the API supports. They split into time-based conditions and resource-based conditions.
Time-based conditions let you express access that is only valid in a particular window. There are three useful patterns here.
The expiring-access pattern is the one that comes up most often in architecture questions, because it solves a real operational problem: temporary access that has to be revoked on a deadline.
Resource-based conditions let you scope a binding by attributes of the target resource rather than by time. The attributes you can match on are:
Resource-based conditions are how you build a single broad-looking binding that, in practice, only applies to a narrow subset of resources. They are useful when you want to say something like "viewer on storage buckets, but only the ones tagged for this project."
The scenario I anchor on for the Professional Cloud Architect exam is giving a third-party vendor access to a Storage bucket for a week-long project. This is a clean fit for IAM Conditions because the access has a hard deadline and you do not want to rely on someone remembering to revoke it.
The binding looks like this:
group:vendor-team@yourcompany.comgs://your-company-bucketThe principal is the vendor team's group, which is the cleanest way to grant access to an external party without provisioning individual users. Storage Object Viewer gives them read access to the bucket contents and nothing more. The resource is the specific bucket they need. The condition pins the access to a 7-day window measured from when the binding was created.
The important property here is that the access expires automatically when the condition stops being true. There is no manual revocation step. If the project runs over and the vendor needs more time, you update the binding. If it finishes early, you can remove the binding sooner, but worst case the access is gone in 7 days regardless of what anyone does.
PCA questions about IAM Conditions tend to fall into one of two shapes. Either the question describes a temporary-access scenario and asks for the right mechanism, in which case IAM Conditions with a time constraint is the answer. Or the question describes a binding that needs to be scoped to a subset of resources, in which case a resource-based condition on type, service, name, or tag is the right fit.
The trap to avoid is reaching for custom roles or for a separate project just to limit blast radius when an IAM Condition on the existing role is enough. Custom roles change what the principal can do. IAM Conditions change when and where the binding applies. Those are different levers, and the exam expects you to pick the smaller one when the smaller one solves the problem.
My Professional Cloud Architect course covers IAM Conditions alongside the rest of the advanced architecture material so you can recognize these patterns the moment they show up in a scenario question.
