ReadMeFeed / Community knowledge
Real questions. Useful conversations. Find the people who know your stack.
An example deployment changes its CPU request from a small value to one that cannot fit on any currently eligible node. The pod stays Pending and has no application logs. The team considers increasing its startup-probe timeout. Which evidence should guide the next change?
A service’s storage request is denied. In this illustrative case, Policy Troubleshooter reports that the named principal has the permission on the resource. The team has not checked whether the actual call crosses a VPC Service Controls boundary. Does the allowed result settle the whole access question?
An example container was changed to run as a non-root user. It starts, but reading a mounted Secret Manager file fails. The team verified that the runtime service account has secret access. What should be checked next, and why is this different from an environment-secret startup failure?
A fictional service exposes a secret through an environment variable using latest. After rotation, older instances keep working with the previous credential while newly started instances use the new one. The application team expected an immediate, simultaneous update. What deployment approach gives a more predictable result?
A worked Cloud Run example references an enabled Secret Manager version as an environment variable. The deployer’s account can access the secret. The service uses a dedicated runtime service account, and new instances fail around startup. Which identity and permission should be checked?
In this example, a team attaches the intended instance profile to EC2. A diagnostic command in a clean shell shows the expected role, but the application still identifies itself as an older IAM user. The system service definition contains legacy AWS environment variables. What should change?
The same intended role can read an object from an approved diagnostic session, while a service running through an S3 VPC endpoint receives 403. The team has checked the role and bucket policy but has not reviewed the endpoint policy. How should the differing request paths be compared?
A fictional application reads most objects under an allowed prefix. A newer object returns AccessDenied. The newer object uses a different customer-managed KMS key. The bucket policy appears unchanged. Which evidence would distinguish S3 access from encryption-key access?
An example service can retrieve a known object key but cannot enumerate the same bucket. The role policy was written specifically for object reads, and the application recently added a directory-style browser. Does successful GetObject access imply that the list request should also work?