See the solution below in Explanation.
Explanation:
* Apply the subscription/application manifest:
* oc apply -f application-subscription.yaml
* Confirm resources were created:
* oc get applications.app.k8s.io -A
* oc get subscriptions.apps.open-cluster-management.io -A
* oc describe application.app.k8s.io my-app -n < namespace >
* Watch placement/propagation (varies by model used in the lab):
* oc get placement -A
* oc get placementrule -A
Why this matters:
* ACM "application" deployment commonly uses Subscription/Placement (legacy model) or newer Placement resources, enabling multi-cluster rollout from Git sources.

See the solution below in Explanation.
Explanation:
* Create a namespace for the team:
oc new-project team-dev
* Create ManagedClusterSetBinding to bind ClusterSet development into team-dev:
cat < < 'EOF' | oc apply -f -
apiVersion: cluster.open-cluster-management.io/v1beta2
kind: ManagedClusterSetBinding
metadata:
name: development
namespace: team-dev
spec:
clusterSet: development
EOF
* Verify:
oc get managedclustersetbinding -n team-dev
Why this matters:
ClusterSet binding is foundational for scoping access and enabling teams to work only with clusters in their set.

See the solution below in Explanation.
Explanation:
* Create a group (example) and add users:
oc adm groups new dev-team
oc adm groups add-users dev-team user1 user2
* Grant namespace access:
oc adm policy add-role-to-group edit dev-team -n team-dev
* Validate with a user token/login (or check rolebindings):
oc get rolebinding -n team-dev | grep dev-team
Why this matters:
ACM access patterns commonly combine namespace RBAC + ClusterSetBinding to scope what teams can manage.

See the solution below in Explanation.
Explanation:
* Open the RHACS (Central) console (typically via a route created by Central).
* Navigate to: Platform Configuration # System Policies .
* Click Create Policy .
* Set the policy criteria:
* Add a rule/condition such as Image OS = debian:10 (as required by the lab)
* Set enforcement to apply at Build & Deploy stages.
* Build prevents images from being admitted into pipeline/registries depending on integration.
* Deploy prevents or flags deployments that violate policy.
* Save the policy.
* (Optional validation) Trigger a test deployment/image that matches debian:10 to confirm alerts
/enforcement behavior.
Why this matters:
* Enforcing at build+deploy catches risky images earlier and prevents policy violations from reaching runtime.

See the solution below in Explanation.
Explanation:
* Create an empty kustomization file:
* touch overlays/production/kustomization.yaml
* Validate it exists:
* ls -l overlays/production
Why this matters:
* kustomization.yaml is the entrypoint file Kustomize uses to build overlays.