An Availability Group replicates a set of databases across several SQL Server replicas -- one Primary (live, taking real traffic) and one or more Secondary (standby copies) -- with SQL Server able to fail over between them at any time, planned or not. A job hardwired to one fixed server breaks the moment that happens: it either fails outright, or worse, runs writes against whatever's now sitting there as a read-only Secondary. AG Settings is what lets a job or step stay correct through a failover without anyone having to notice it happened or go update anything.
Two independent things, both set per job and overridable per step: a skip-gate ("only run if this database is currently Primary/Secondary -- otherwise skip, fail loud, or reroute to Primary") and target resolution ("don't use a fixed Target Server at all -- connect to whichever approved server currently holds the role I want"). Neither ever has a group name typed in or tagged anywhere: you name one database, and its Availability Group membership plus every replica's current role is discovered live off that database, every time the gate or resolution runs. A failover is picked up automatically -- nothing to keep in sync, nothing that can go stale.
Skip-gate
A safety check, not a router: it looks at the database you name and asks what role it's playing right now. If the answer doesn't match what you picked (Primary or Secondary), the run is skipped entirely, failed loud, or -- if you'd rather it just work -- rerouted to whichever server currently holds Primary.
Target resolution
A router, not a check: decides which server this actually connects to. Instead of a fixed Target Server, it asks the named database which Availability Group it's in, then connects to whichever approved server currently holds the role you want.
Job-level default, step-level override
A job's own setting is a convenience default for the common case -- most jobs are built around one primary database. A step can leave either section at "(inherit from Job)", or override just the one it needs, independently of the other. See Target Servers for how servers themselves get added and approved.
A Database-cursor step is all-or-nothing
A step whose cursor resolves to a list of databases (rather than one named database) checks every resolved database against the required role at once -- if even one doesn't currently match, the whole step is skipped or failed rather than partially running against whichever ones did match.